Wersja 2.0

Istnieje jednak inna metoda. Tą metodą jest alternatywne podejście do architektury CRM. Podejście bez zintegrowanego pakietu CRM typu "wszystko w jednym", a spełniające wymagania biznesowe, elastyczniejsze, tańsze w rozwoju i prostsze w utrzymaniu. To inne podejście polega na rozdzieleniu tradycyjnego monolitu CRM na dwie, dobrze zdefiniowane części. Część front-endową i część corową. Posługując się klasycznym podziałem systemów IT na trzy warstwy: prezentacyjną, logiki biznesowej i danych, musimy zaprojektować "cienką" warstwę prezentacyjną z ograniczeniem logiki biznesowej do absolutnego minimum oraz moduł zawierający wszystkie dane o klientach i ich produktach czy usługach, a także funkcje manipulowania tymi danymi.

Najdogodniejszy moduł "corowy" musi zawierać dwie cechy. Po pierwsze, musi w prosty sposób udostępniać wszystkie realizowane funkcje, najlepiej jako usługi. Nie ma bowiem wątpliwości, że ta nowa architektura, to będzie SOA - zorientowana na usługi. Po drugie, musi implementować odpowiedni model danych. Najlepiej, jeśli ten model danych, to będzie wprost model kanoniczny dla naszej architektury (uszczegółowienie kwestii modelu kanonicznego to znowu temat na osobny tekst). Jeśli zdecydujemy się na implementację niekanoniczną, wtedy konieczne będzie udostępnianie usług modułu za pośrednictwem warstwy pośredniej (ESB - Enterprise Service Bus), która dokona konwersji modelu z kanonicznego do właściwego dla tego modułu.

Są na rynku dostępne gotowe moduły danych klienta i usług. Można wykorzystać taki gotowy moduł, ale można też zbudować taki moduł pod klucz jako bazę danych z warstwą logiki zaimplementowanej jako aplikacja J2EE dostępna przez Web Service. Innym sposobem jest implementacja funkcji/usług bezpośrednio w warstwie pośredniej. Jeśli gdzieś wdrożono już pakiet CRM i przyszłość tego pakietu nie jest jasna, można w pierwszym kroku transformacji architektury użyć do budowy nowego modelu istniejącego systemu.

Może pojawić się pytanie, czy nie należy w charakterze modułu informacji o klientach użyć hurtowni danych. Rzeczywiście, hurtownia powinna zawierać komplet danych o klientach, jednak hurtownia nie może pełnić roli opisanego systemu. Głównym powodem jest specyfika działania hurtowni. Opisywany moduł musi posiadać kilka cech: musi zapewniać bardzo szybkie czasy reakcji, musi być dostępny w trybie pracy ciągłej 24/7/365 i musi być systemem transakcyjnym, przetwarzającym dane w czasie rzeczywistym. Hurtownia jest bazą danych zoptymalizowaną na tworzenie przekrojowych raportów i analiz, i właśnie dlatego (oprócz potrzeby gromadzenia danych z wielu systemów) tworzy się hurtownie danych zamiast używać do raportowania baz systemów transakcyjnych. Dane w hurtowni są zazwyczaj aktualizowane w trybie dobowym, a w bazie danych o klientach dane muszą być aktualizowane na bieżąco (np. klient wykonał jakąś operację przez Internet, a po chwili dzwoni do call center i tam nowe dane muszą być dostępne).

Co do modułów front-endowych, to i tu istnieją bardzo ciekawe rozwiązania "z półki". Osobiście polecam tutaj J2EE z nowoczesnym, dynamicznym interfejsem użytkownika w technologii AJAX, z warstwą aplikacyjną gotową do integracji poprzez Web Service. Tu kluczową cechą jest możliwość dynamicznego rozwoju. To jest warstwa, przez którą nawiązujemy bezpośredni lub pośredni kontakt z klientami i tu musimy posiadać rozwiązanie o największej elastyczności. Czy do wszystkich kanałów użyć jednego rozwiązania, czy pozwolić na hybrydę, w dużym stopniu zależy od stanu wyjściowego, z którego startujemy do budowy architektury zarządzania relacjami z klientami.

Dla każdego, kto już wdrożył CRM, powyższe rozważania powinny brzmieć aż nadto znajomo. Każdemu, kto dopiero wyrusza w tę CRM-ową podróż, polecam zacząć od szerokiego spojrzenia na biznes i zweryfikowania dzisiejszego i jutrzejszego modelu biznesowego i rozważnego zaprojektowania wspierającej go architektury IT. Aby uznać obraz architektury zarządzania relacjami z klientami za kompletny, konieczne jest rozwinięcie, zasygnalizowanych jedynie w powyższym tekście, kwestii automatyzacji procesów i architektury usługowej z kanonicznym modelem danych, czyli aspekty SOA.

Maciej Ostaszewski jest niezależnym konsultantem; wcześniej w Grupie TP odpowiadał m.in. za wdrożenie zintegrowanego systemu CRM oraz za funkcjonalną integrację rozwoju IT.