Rozdział 11 Architektura sterowana zgłoszeniami i zdarzeniami w systemach klasy CRM Streszczenie. Systemy klasy CRM zyskują coraz większe znaczenie dla przedsiębiorstw chcących zwiększyć swoją konkurencyjność. Tradycyjna metoda pozyskiwania klientów dzieli się na trzy fazy: wymiany informacji, umowy oraz sprzedaży. Nowsze podejścia proponują ciągły proces, który łączy kilka oddalonych od siebie w czasie transakcji w jedną. Z punktu widzenia marketingu, pierwszy model jest odzwierciedleniem zasady marketing-mix. Drugie podejście jest określanie mianem utrzymywania relacji z klientem. W większości przypadków, systemy informacyjne pozwalają na analizę pozyskanych klientów opartą na koncepcji marketing-mix. Utrzymanie relacji z klientem jest raczej traktowane jako procedury świadczenia usług. Przedstawiona architektura systemu klasy CRM sterowanego zgłoszeniami i zdarzeniami pozwala na segmentację grup docelowych klientów przy jednoczesnym wsparciu indywidualnej analizy cech i zachowań klienta oraz spersonalizowanego podejmowania decyzji opartego na koncepcji żądań i zdarzeń biznesowych. Krótko opisano również sposób generowania spersonalizowanych informacji dla klienta z wykorzystaniem prostej aplikacji XML. 1 Wstęp Uniwersytety na świecie i w Polsce przykładają coraz większą uwagę na sposób komunikacji i zarządzania swoimi klientami: studentami i pracownikami. Fox i Kotler [1] stwierdzili, że najlepsza organizacja na świecie nie będzie efektywna, jeżeli straci kontakt z klientem. W ciągu kilku ostatnich lat, wiele uniwersytetów w Polsce przechodzi rekonstrukcje swoich procesów biznesowych. Główną przyczyną jest konieczność redukcji kosztów i zwiększenie efektywności pracy. Możliwości oferowane przez nowe technologie i zintegrowane systemy zarządzania powodują, że zastosowanie ich jest coraz częściej rozważane. Obecnie, systemy te wspierają pracę księgowości, gospodarki magazynowej i stanów środków trwałych, pracę dziekanatów, itp. Poza systemami wspomagającymi zarządzanie uczelnią, które można zaliczyć do klasy Enterprise Resource Planning (ERP), wydaje się konieczne wdrożenie rozwiązań o innych przeznaczeniu zarządzania relacjami z klientem (CRM). Grzegorz Futa Uniwersytet Marii Curie Skłodowskiej, Instytut Informatyki, ul. M. Curie Skłodowskiej 5, 20-031 Lublin, Polska email:grzegorz.futa@umcs.lublin.pl
G. Futa Fickel [2] podaje prostą definicję systemu CRM jako rozwiązania umożliwiającego połączenie systemu sprzedaży lub obsługi klienta z innymi systemami działającymi w firmie (np. finansowo-księgowy), gdzie punktem styku jest klient. Punkt ten może być związany z różnym kanałem dostępowym: Internet, poczta elektroniczna, call center, itd. Głównym zadaniem CRM jest integracja tych kanałów i umożliwienie przedstawienia ogólnej, zbiorczej informacji o kliencie [3]. W niektórych organizacjach CRM jest prostym oprogramowaniem, które zbiera informacje z różnych baz danych. Rozszerza funkcjonalności niezależnych programów działów sprzedaży i marketingu, umożliwiając lepsze wyznaczanie docelowych grup klientów. Funkcja ta jest wsparciem dla tradycyjnego modelu marketingu: marketing-mix. Połączenie danych różnych systemów, umożliwia łatwiejszą analizę potencjalnych grup docelowych. Inne rozwiązania pozwalają na indywidualne podejście do klienta [4]. Dodatkowo Goldenberg [5] stwierdza, że CRM to nie tylko aplikacja wspomagająca sprzedaż, pracę marketingu czy obsługę klienta. Powinien być traktowany jako wielofunkcyjna, zorientowana na klienta strategia zarządzania wspierana przez odpowiednie oprogramowanie. Z punktu widzenia klienta, powinno ono oferować łatwe wykorzystanie bez względu na kanał komunikacyjny z jakiego się korzysta [6]. Bazując na literaturze (np.: [7-10]) można stwierdzić, że systemy klasy CRM to rozwiązania (organizacyjne i technologiczne), które można rozważać na płaszczyznach: skupienia uwagi na kluczowych klientach, organizacji struktury CRM, mechanizmach zarządzania wiedzą i aspektów technologicznych. Romano i Fjermestad [11] zaproponowali pięć obszarów badawczych: aspekty technologiczne, zarządzanie wiedzą, czynnik ludzki, rynki i modele biznesowe. Pokazali również, że aspekty technologiczne są jednym ważniejszych obszarów badawczych [12]. W dalszej części opisane zostaną technologiczne rozwiązania, jakie zostały zaimplementowane w systemie zarządzania klientami dla uczelni nauczającej z wykorzystaniem Internetu. W następnej sekcji zarysowana jest problematyka, którą szerzej przedstawiono w [13]. Podrozdział 3 wprowadza pojęcia zgłoszenia i zdarzenia biznesowego oraz przedstawia celowość wprowadzenia proponowanego modelu zarządzania klientami. Podrozdział 4 pokazuje w jaki sposób można wykorzystać zaprojektowany i zaimplementowany system do realizacji koncepcji marketingu relacji. Ostatecznie podsumowano efekty powdrożeniowe i jak one wpłynęły na jakość świadczonych usług, co według Parasuraman a i Grewal a [14] jest istotnym czynnikiem sukcesu wdrożenia. 2 Zarys problematyki Ogólne założenia systemu przedstawione zostały w [13]. System, który był początkowo rozwijany jako system do obsługi rekrutacji studentów, został zmodyfikowany i przeprojektowany. Docelowo integruje kilka baz danych różnych systemów (rys. 1) wykorzystywanych na uczelni, oferując funkcje specyficzne na CRM. Zaimplementowany system steruje przepływem pomiędzy danymi dwóch platform zdalnego nauczania oraz systemem dziekanatowym. Z danych przechowywanych w głównej bazie danych korzystają systemy rejestracji na studia i inne produkty oferowane przez uczelnię, system wsparcia technicznego, system dystrybucji informacji marketingowej, i inne. 116
Architektura sterowana zgłoszeniami i zdarzeniami dla systemu klasy CRM R5Generation System dziekanatowy CRM NetG {vendor: MySQL} Rys. 1. Bazy danych i przepływ informacji pomiędzy nimi. 3 Koncepcja systemu klasy CRM Dostępne na rynku produkty Commercial Of The Shelf klasy CRM są często dodatkowymi modułami do istniejącego oprogramowania. Systemy takie są z reguły odpowiedzialne za zarządzanie kontaktami z klientami. Sprzężenie z systemem sprzedaży jest bardzo rzadko spotykana. W większości przypadków, integracja polega na opracowaniu mechanizmów umożliwiających wymianę danych pomiędzy bazami wykorzystywanymi przez różne moduły systemów wspomagających procesy biznesowe przedsiębiorstwa. Przedstawiany tutaj system nie ma wspomnianej wady. System zamówień i wszystkich rodzajów zgłoszeń jest integralną częścią rozwiązania. 3.1 Zgłoszenia biznesowe Zaproponowany model obsługi klienta zakłada, że zgłoszeniem (żądaniem) biznesowym jest każde żądanie klienta przesłane do właściwego pracownika. Zgłoszeniem biznesowym jest zarówno chęć zakupu towaru lub usługi, jak i przesłanie informacji o problemie, reklamacji, a nawet prośba o udzielenie informacji. Z punktu widzenia zaimplementowanego systemu, kandydat rejestrujący się na studia lub kurs ma do wyboru jeden z typów zgłoszenia: Zgłoszenie na studia; Zgłoszenie na kurs otwarty; Zgłoszenie na kurs studyjny; Zgłoszenie na studia podyplomowe. Konieczność podziału zgłoszeń rekrutacyjnych wynika z procesów biznesowych ograniczanych wymogami prawnymi i wewnętrznymi procedurami obsługi klientów. Proces obsługi zgłoszenia na studia przebiega w diametralnie inny sposób od zgłoszeń na kursy otwarte. Osobom rejestrującym się na poszczególne produkty stawia się inne wymagania prawne. Osoba zgłaszająca się na studia musi posiadać wykształcenie średnie. Wymóg ten nie dotyczy osób zgłaszających się na kursy otwarte. Uczestnikiem może być dowolna oso- 117
G. Futa ba wyrażająca chęć uczestniczenia w nim. Również procedury obsługi klienta zapisującego się na kurs otwarty różnią się od procedur obowiązujących przy rekrutacji na studia. Podział zgłoszeń rekrutacyjnych umożliwił w elastyczny sposób wprowadzenie dwóch nowych produktów szkoleniowych: studiów podyplomowych oraz kursów studyjnych. Podobnie jak w poprzednich rodzajach zgłoszeń, znacznie różnią się one procedurami obsługi klienta oraz wymogami prawnymi. W przypadku studiów podyplomowych, uczestnikiem mogą być osoby, które ukończyły już studia wyższe. Z kolei kursy studyjne są specyficznym rodzajem kursów otwartych. Przedmioty realizowane w formie kursów studyjnych, są przedmiotami wchodzącymi w skład programu studiów. Jednakże uczestnicy kursów studyjnych mogą mieć dodatkowe korzyści w przypadku kontynuacji nauki na studiach wyższych prowadzonych przez uczelnię. Przedstawione powyżej różnice pomiędzy poszczególnymi typami produktów szkoleniowych nie są wszystkimi różnicami wymuszającymi podział zgłoszeń rekrutacyjnych. Obsługa każdego z typów zgłoszeń przebiegał w odmienny sposób. W trakcie rocznej pracy nad systemami, stwierdzono również konieczność rekrutacji osób prowadzących poszczególne grupy zajęciowe. Duża liczba zgłoszeń na trenerów oraz konieczność indywidualnego podejścia i analizy każdego zgłoszenia spowodowało konieczność opracowania oprogramowania zarządzającego tymi zgłoszeniami. Z drugiej strony, nauczyciel i kandydat na to stanowisko jest klientem, o którym informacje muszą być przekazywane do innych systemów informatycznych uczelni: platformy zdalnego nauczania oraz systemu dziekanatowego. Prowadzący jest również osobą silnie powiązaną z wcześniej opisaną grupą klientów, jakimi są studenci. Z powyższych powodów, trener jest kolejnym istotnym elementem, który musi być uwzględniony w systemie CRM. Podobnie jak student posiada on własny, unikalny identyfikator, umożliwiający autoryzację jego osoby w udostępnianych systemach informatycznych. Osoba chcąca podjąć pracę jako trener wypełnia formularz zgłoszeniowy umieszczony na stronach WWW, co przypisuje do niej nowy typ zgłoszenia zgłoszenie na prowadzącego. Analiza procesów biznesowych związanych z obsługą klienta uwidacznia potrzebę wprowadzenia kolejnego rodzaju zgłoszeń. Są to zgłoszenia problemów technicznych. Systemy informatyczne, są narzędziami wymagającymi pewnego rodzaju oprogramowania zainstalowanego na komputerze użytkownika końcowego. Platforma zdalnego nauczania wymaga zainstalowanej odpowiedniej wersji środowiska uruchomieniowego Java. Materiały multimedialne i filmy, w celu zmniejszenia ich rozmiaru, kompresowane są za pomocą najnowszych kodeków. Często występującymi problemami są te związane z obsługą oprogramowania oraz problemy z logowaniem do systemów. Dla większości studentów zadania związane z konfiguracją oprogramowania są czynnościami skomplikowanymi, dlatego też oddelegowano osobę, której zadaniem jest obsługa problemów technicznych i funkcjonalnych systemów udostępnianych klientom. Zgłoszenie problemu technicznego traktowane jest w systemie CRM jako kolejny rodzaj zgłoszenia. Dzięki systemowi CRM pracownik obsługi technicznej ma możliwość śledzenia zmian w rozwiązywanym problemie oraz ma pełny przekrój profilu wybranej osoby. Często do rozwiązania konkretnego problemu niezbędna jest pełna informacja o wybranym użytkowniku, np. na jakim kierunku się uczy, czy podobne problemy występowały już wcześniej na jego komputerze, do jakiej grupy zajęciowej student powinien mieć dostęp. Centralna baza informacji o użytkownikach, zarówno o studentach jak i prowadzących znacznie przyspiesza czas rozwiązywania problemów, redukując jednocześnie ilość kontaktów, jakie musi wykonać pracownik obsługi technicznej w celu zebrania pełnej informacji o kliencie. 118
Architektura sterowana zgłoszeniami i zdarzeniami dla systemu klasy CRM Reasumując, zgłoszenie biznesowe jest uogólnieniem faktu rozpoczęcia tradycyjnej transakcji. Dodatkowo, model zakłada, że żądanie takie nie musi być związane z faktem sprzedaży usługi lub towaru. 3.2 Status żądania biznesowego Z każdym rodzajem zgłoszenia powiązany jest odpowiedni model biznesowy obsługi. Jak już wcześniej wspomniano, inne wymagania stawiane są osobom kandydującym na studia inne wymagania stawiane są osobom kandydującym na kursy otwarte. Zupełnie inny jest też model obsługi klienta w przypadku zgłoszenia problemu technicznego. Niezależnie od modelu biznesowego obsługi zgłoszenia, każde z nich może znajdować się w stanach specyficznych dla danego procesu biznesowego (np. Nowe zgłoszenie, Zaakceptowane przez komisję rekrutacyjną, Odrzucone przez komisję rekrutacyjną, Przesunięte na koleją edycję dla zgłoszeń rekrutacyjnych, Nowe zgłoszenie, Problem rozwiązany, Problem nie rozwiązany w przypadku zgłoszeń problemów technicznych). Każdemu z typów zgłoszenia, można przypisać listę stanów, w jakim może znajdować się zgłoszenie. Stany te są związane bezpośrednio z etapami obsługi przewidzianymi przez procesy biznesowe. Umożliwia to między innymi szybką kategoryzację i przeszukiwanie zgłoszeń. 3.3 Zdarzenia biznesowe Klasyfikacja zgłoszeń ze względu na stan, w jakim się ono znajduje, nie wyczerpuje wszystkich możliwych sytuacji, jakie mogą się wydarzyć podczas obsługi klienta. Przypisanie poszczególnym typom zgłoszeń poszczególnych statusów niejako zarysowuje pewien model biznesowy obsługi. Opierając się tylko i wyłącznie o zmiany statusów, nie jest możliwe rozwiązanie wszystkich problemów związanych z obsługą klienta. W trakcie obsługi mogą zajść pewne istotne zdarzenia. Z punktu widzenia obsługi nauczycieli, zdarzeniem takim jest konieczność uczestnictwa w szkoleniu z obsługi platformy zdalnego nauczania. Tylko osoby, które przejdą tego typu szkolenie mogą być dopuszczone do prowadzenia grup zajęciowych. Przypisywanie zdarzeń zachodzących w procesie obsługi zgłoszenia, uzupełnia opis transakcji o dodatkowe informacje. Jednocześnie każdemu zdarzeniu przypisywana jest data jego wystąpienia, co umożliwia śledzenie historii obsługi klienta. Zdarzenia, w przeciwności do statusów, są przypisywane do osób. Opcjonalnie mogą być przypisane również do zgłoszenia (np. Przesłano materiały szkoleniowe ). Na rysunku 2 przedstawiono przykładową listę zdarzeń, jakie wystąpiły podczas procesów obsługi klienta oraz predefiniowane drzewko zdarzeń (rys. 3). 119
G. Futa Rys. 2. Zdarzenia, jakie wystąpiły podczas obsługi użytkownika Rys. 3. Predefiniowana lista zdarzeń biznesowych dostępnych we wdrożonym systemie Na rysunku 4 przedstawiono uproszczony schemat powiązań pomiędzy obiektami omawianymi w podrozdziale 3.3. 120
Architektura sterowana zgłoszeniami i zdarzeniami dla systemu klasy CRM product getrequirements() : void 0..1 user 0..* request 1 gettype() : void getstatus() : void getmetrequirements() : void 0..* event 0..* 1..* event_catalog 1 Rys. 4. Uproszczony schemat powiązań pomiędzy głównymi obiektami architektury 4 Realizacja koncepcji marketingu relacji za pomocą aplikacji XML Przechowywanie danych o transakcjach użytkownika w systemie jest funkcjonalnością dostępna w większości zintegrowanych systemów informacyjnych. Dają one również możliwość podglądu stanu transakcji. Architektura przedstawianego tu systemu rozszerza dodatkowo opis klienta za pomocą zdarzeń biznesowych. Jak zasygnalizowano wyżej, każdy z operatorów systemu ma możliwość podglądu historii zgłoszeń i zdarzeń biznesowych. Manualna analiza i podejmowanie na jej podstawie decyzji lub czynności jest czasochłonna, a co za tym idzie kosztowna. System został wzbogacany o mechanizm reguł, opisanych za pomocą języka XML, umożliwiający podejmowanie zindywidualizowanych czynności wobec klienta. Działanie tego mechanizmu jest opisane na podstawie modułu systemu przygotowującego pocztę elektroniczną. Treści przygotowanych listów oraz ich adresaci są generowane na podstawie mechanizmu reguł opisanych w pliku aplikacji XML. Na rysunku 5 przedstawiono graficznie strukturę XSchema pliku reguł. Na podstawie informacji zapisanych w bazie danych CRM oraz pliku reguł, aplikacja wybiera indywidualne rekordy klientów oraz inne niezbędne informacje potrzebne w podjęciu decyzji (informacje o zgłoszeniach lub zdarzeniach biznesowych) lub potrzebane do 121
G. Futa uzupełnienia szablonu z treścią wysyłanego listu. Aplikacja uruchamiana jest cyklicznie, bez konieczności aktywności operatora. Rys. 5. Struktura graficzna schematu XSchema plików reguł Plik reguł wykorzystywany przez aplikację zawiera klika sekcji messagerule. Każda z sekcji zawiera treść listu (message) oraz sekcję reguł (rules) określających adresata wiadomości. Każda reguła (rule) może być łączona operatorem logicznym AND lub OR. W przypadku konstrukcji bardziej skomplikowanych reguł możliwe jest również grupowanie reguł w większe, które można łączyć za pomocą operatorów logicznych. Pojedyncza reguła określa adresatów wiadomości na podstawie zarejestrowanych w systemie żądań biznesowych (requests) oraz opcjonalnie zdarzeń (events), jakie wystąpiły przy obsłudze zgłoszenia. Dodatkowo, regułę można określać za pomocą zdarzeń, bez uwzględniania zgłoszeń, z którymi są powiązane. Mechanizm daje również możliwość określania częstości wysyłania poczty (atrybuty lastoccurance i lastoccuranceperiod). Wykorzystanie tych atrybutów umożliwia ograniczenie ilości poczty kierowanej do użytkownika w wybranym okresie czasu. W celu spersonalizowania treści listu, szablon treści listu umieszczany w sekcji message można wzbogacać informacjami zawartymi w bazie danych (np. dane osobowe, nazwa kierunku studiów, itp.). Dokonywane jest to za pomocą elementu database- Field z odpowiednio opisanymi atrybutami. 122
Architektura sterowana zgłoszeniami i zdarzeniami dla systemu klasy CRM Ponieważ aplikacja uruchamiana jest cyklicznie w stosunkowo krótkich odstępach czasu, opracowanie listu do wysłania za pomocą tego mechanizmu musi być oznaczone jako wystąpienie zdarzenia biznesowego (element markevent). Na podstawie takiej informacji, następne zastosowanie mechanizmu reguł nie wygeneruje identycznego listu skierowanego do tej osoby (jeżeli reguła jest opisana w odpowiedni sposób). Poprawne skonfigurowanie mechanizmu reguł jest wykorzystywane do wysyłania standardowej korespondencji seryjnej drogą elektroniczną. Ogromnym atutem tego modułu jest bardzo precyzyjne definiowanie odbiorców wiadomości, co jest głównym założeniem koncepcji marketingu relacji. Sam mechanizm reguł selekcji klientów jest niezależny od czynności realizowanych przez system. W omawianym tutaj przykładzie, reguły zostały zastosowane do przygotowywania treści korespondencji elektronicznej. Łatwo można sobie wyobrazić, że element message może być jednak zastąpiony innym elementem, powodującym np. uruchomienie aplikacji z pewnymi parametrami. Aplikacja taka może automatycznie przypisywać osoby do grup na platformach zdalnego nauczania lub włączać/wyłączać dostęp do określonych materiałów edukacyjnych. 5 Wnioski Zaproponowana architektura przyniosła wiele korzyści po zaimplementowaniu i wdrożeniu systemu. Korzyści, w głównej mierze, miały bezpośredni związek z ułatwieniem obsługi klienta (studenta i trenera). Zgeneralizowanie obsługi żądań biznesowych pozwoliło również na szybszą implementację nowych typów zgłoszeń i funkcjonalności związanych ze wspomaganiem nowych usług. Niestety, w dalszym ciągu wymaga to opracowania graficznego interfejsu użytkownika. Rozwiązanie w chwili obecnej umożliwia tylko określanie reguł biznesowych i procesów z nimi związanych. Wprowadzenie systemu CRM, integrującego kilka innych niezależnych baz danych, spowodowało odciążenie tych systemów. Nie przechowywały już one informacji zbędnych, tymczasowych w granicach wybranych systemów (np. informacje o kandydatach nie zakwalifikowanych na studia były usuwane z systemu dziekanatowego). Jednakże posiadanie takich danych jest cenną informacją, która może być poddawana dalszej analizie. Również ilość błędnie wprowadzanych danych została znacznie zredukowana. Dotychczasowa wymiana danych wymuszała ręczne wprowadzanie danych na podstawie informacji posiadanych innym systemie. CRM przejął rolę pośrednika synchronizującego informacje przechowywane w wielu systemach. Dane są regularnie aktualizowane, a sama aktualizacja nie wymaga dodatkowego nakładu pracy. Informacje, które są zbędne w innych systemach pozostają w bazie danych CRM. Generalizacja procesów obsługi klienta za pomocą wprowadzonej koncepcji żądania biznesowego pozwoliła na zbudowanie systemu otwartego. System taki może być łatwo rozbudowywany o nowe funkcjonalności związane z obsługa klienta, o nowe rodzaje świadczonych usług i sprzedawanych towarów. W przypadku prezentowanego tutaj systemu, były to nowe usługi szkoleniowe oraz sposoby wsparcia i obsługi studentów oraz nauczycieli. Ponieważ z każdym rodzajem zgłoszenia biznesowego związane są inne procedury, zaimplementowano prosty mechanizm opisu stanu obsługi zgłoszenia. Mechanizm ten jest wspomagany przez koncepcję zdarzeń biznesowych, które mogą dodatkowo być powiązane z serwisem konkretnego zgłoszenia biznesowego. Wystąpienie zdarzenia bardzo silnie wspomaga procedury obsługi. Istotnym faktem jest możliwość indywidualnej analizy zachowań osoby oraz podejmowania decyzji dotyczących wybranej jednostki, na podstawie 123
G. Futa faktów, które miały miejsce podczas obsługi. Funkcję to realizuje się za pomocą mechanizmu zdarzeń biznesowych. Kolejna zaletą wykorzystania zdarzeń biznesowych jest możliwość zautomatyzowania procesów podejmowania tych decyzji oraz podejmowania zadań uwzględniających indywidualne cechy oraz historię zamówień i obsługi klienta. Automatyzacja została przedstawiona na przykładzie modułu pozwalającego na rozsyłanie poczty elektronicznej. W porównaniu do powszechnie używanych metod segmentacji (np. [15]), pozwala precyzyjnie określać odbiorcę listu w oparciu o ściśle określone w pliku XML parametry. Na podstawie przedstawionego zbioru reguł można opracować mechanizm, który umożliwi zautomatyzowanie innych czasochłonnych czynności wymagających dokonania wielu operacji na danych klienta. Przedstawiona tutaj architektura systemu CRM została zaimplementowana na potrzeby szkolnictwa wyższego. Uogólnienie przedstawionych założeń systemu pozwala jednak na wykorzystanie jej w innych środowiskach biznesowych, zwłaszcza tam, gdzie obsługa klienta i transakcji jest procesem długoterminowym. Dodatkowo przewiduje ona występowanie żądań biznesowych, które nie generują przychodu (np. zgłoszenie problemu technicznego). Daje to możliwość wstępnego oszacowana wartości klienta oraz kosztów jego posiadania informacji istotnych z punktu widzenia osób zarządzających. Literatura 1. Kotler P., Fox K.: Strategic Marketing for Educational Institutions. Prentice Hall, New York, 1995. 2. Fickel L.: Know your customer. CIO Magazine, (12) pp. 62 72, 1999. 3. Eckerson W., Watson H.: Harnessing Customer Information for Strategic Advantage: Technical Challenges and Business Solutions. The DataWarehousing Institute, Chatsworth, 2000. 4. Peppers D., Rogers M.: The One to One Manager:Real-World Lessons in Customer Relationship Management. Doubleday, New York, 1999. 5. Goldenberg B.: What is CRM? What is an ecustomer? Why you need them now? In Proceedings of DCI Customer Relationship Management Conference, pp. 27 29, Boston, 2000. 6. Gulati R., Garino J.: Get the right mix of bricks and clicks. Harvard Business Review, (78) pp. 107 14, 2000. 7. Crosby L., Johnson S.: High performance marketing in the CRM era. Marketing management, pp. 68 81, 2001. 8. O Halloran J., Wagner T.: The next frontier. Journal of Business Strategy, (22) 28 33, 2001. 9. Paracha B., Bulusu A.: Effectively integrating the components of CRM. Customer Interaction Solutions, pp. 34 6, 2002. 10. Ryals L., Knox S.: Cross-functional issues in the implementation of relationship marketing through customer relationship management. European Management Journal, (10) pp.534 542, 2001. 11. Romano N., Fjermestad J.: Electronic Commerce Relationship Management: A research Agenda. Information Technology and Management, (4) pp.233 258, 2003. 12. Romano N., Fjermestad J.: Customer relationship management research: An assessment of research. International Journal of Electronic Commerce, (6) 61 114, 2002. 13. Futa G.: Customer Relationship Management system models application in higher education. Annales UMCS, sectio: Acta Informatica, (2) pp. 445 452, 2004. 14. Parasuraman A., Grewal D.: The impact of technology on the quality-value-loyalty chain: A research agenda. Journal of the Academy of Marketing Science, (28) 168 174, 2000. 15. Shina H., Sohn S.: Segmentation of stock trading customers according to potential value, Expert Systems with Applications, (27) 27 33, 2004. 124