Strategia, system, zarządzanie zmianą - trzy wymiary CRM

1.Trzy wymiary CRM.
- strategia,
- system,
- zarządzanie zmianą.
2.Bariery zewnętrzne wdrażania CRM.
3.Bariery wewnętrzne wdrażania CRM.
4.Planowanie wdrożenia CRM:
- zakres wdrożenia,
- strategia biznesowa,
- kultura organizacyjna,
- strategia wobec klientów,
- łańcuch kreowania wartości.

Procesy CRM i ich modelowanie

 1. Podstawowe procesy CRM:

- elementy i jakość oferty,

- lead management,

- cross-/up-selling,

- loyalty management,

- anti-churn management.

2. CRM w mediach społecznościowych (SCRM):

- cele możliwe do realizacji poprzez media społecznościowe,

- wykorzystanie mediów społecznościowych w procesach CRM.

3. Modelowanie procesów.

- podstawowe wymogi projektowe,

- wybór procesów do modelowania,

- modelowanie procesów.


Projekt biznesowy i techniczny CRM

1. Określanie korzyści związanych z wdrożeniem CRM.

- korzyści ogólnie utożsamiane z CRM,

- korzyści kwantyfikowalne i ich odnoszenie do korzyści finansowych.

2. Możliwości systemów klasy CRM.

- zadania operacyjne,

- zadania analityczne.

3. Wymagania wobec systemu klasy CRM.

- podstawowe wyzwania w tworzeniu wymagań technicznych,

- szczegółowe tworzenie wymagań technicznych.

4. Wdrażanie projektu CRM.

- techniczny projekt wdrożeniowy,

- projekt wdrożeniowy wśród użytkowników końcowych.


Case study wdrożeń systemów CRM i ERP

1.Implementacja systemu PeopleSoft Enterprise w sieci sprzedaży i serwisowej firmy motoryzacyjnej.

2.Zakres wdrożenia:

- wieloetapowe przygotowania organizacyjne - ,

- integracja z innymi systemami i pozostałe wyzwania natury technicznej,

- utrzymanie i rozwój systemu,

- programy wdrożeń i wielomarkowy re-launch wdrożenia w sieci sprzedaży.


Wybór partnera wdrożenia, umowa wdrożeniowa i ochrona danych osobowych

1. Wybór partnera wdrożenia i umowa wdrożeniowa

- kryteria wyboru dostawcy,

- szczególne klauzule umowy licencyjnej i wdrożeniowej,

- analiza wzorów umów pod kątem luk bezpieczeństwa,

- szczegółowe definiowanie potrzeb.

2. Ochrona danych osobowych

- podstawowe pojęcia,

- obowiązki Administratora Bezpieczeństwa Informacji,

- procedury i dokumentacja,

- wniosek rejestracyjny,

- określanie wymogów dt. bezpieczeństwa danych w nowym systemie.


Warsztaty wdrożeniowe programów biznesowych wspieranych systemami CRM

1. Zapoznanie się z case study wdrożenia CRM.

2. Praca nad rozwiązaniem zadania projektowego w ramach własnej grupy.

3. Przegląd rozwiązań wypracowanych przez różne grupy.

4. Podsumowanie case study i całych studiów.


Kolejność zajęć w aktualnej edycji studiów podyplomowych podawana jest przyjętym słuchaczom drogą mailową


Do poczytania - publikacje naszych wykładowców:


Współpraca z dostawcą oprogramowania, dr Bartosz Deszczyński, fragment książki CRM. Strategia, system, zarządzanie zmianą.


Każda firma informatyczna, odpowiadając na ogólne zapytanie o możliwość „zbudowania systemu CRM”, będzie z konieczności musiała wybrać jedną z dwóch podstawowych strategii negocjacyjnych. Im bardziej ogólne zapytanie ofertowe, tym większe ryzyko dla dostawcy, iż jego założenia rozminą się z oczekiwaniami zleceniodawcy. Zatem albo przedstawi kwotację z uczciwie określonym marginesem bezpieczeństwa, albo „konkurencyjną” ofertę, jednak przy założeniu, że gotowe komponenty jego bazowego produktu nie ulegną dużym modyfikacjom. Drugi, dość prawdopodobny przypadek oznacza prawie pewne podniesienie kosztów projektu wdrożeniowego przy ostatecznym negocjowaniu zapisów umowy lub też przekroczenie budżetu związanego z koniecznością dokonywania zmian założeń w trakcie wdrożenia.

Interpretacja oczekiwań zamawiającego przez firmę prowadzącą wdrożenie, ma w przypadku systemu CRM szczególne znaczenie. Jak przy każdym niemal przetargu kończącym się podpisaniem umowy na wykonanie czegoś, co jeszcze nie istnieje, również i w tym przypadku kwestia możliwie dokładnego określenia spodziewanego efektu owych prac leży w dobrze pojętym interesie zamawiającego. Podejmujące się wzniesienia budynku czy mostu firmy startujące w przetargu poznają i akceptują setki stron dokumentacji opisującej najdrobniejsze detale mającego powstać obiektu – podobnie dokładny opis systemu powinien stanowić wyznacznik tego, czy firma informatyczna zlecenie zrealizowała w pełni, czy też nie. Należy założyć, że każdy niezbyt precyzyjny zapis specyfikacji będzie interpretowany w sposób najprostszy z możliwych lub też dostosowywany do wyjściowej konfiguracji systemu bazowego. Nie wynika to bynajmniej z braku motywacji do należytego realizowania umowy, tym bardziej że prostsze rozwiązania (o ile dają ekwiwalentny efekt funkcjonalny) oznaczają krótszy czas oczekiwania na wykonanie systemu i mniejsze problemy eksploatacyjne. Trzeba jednak przyjąć, że programiści nie znając dokładnie realiów biznesowych, będą dokonywali założeń upraszczających, które mogą okazać się niekorzystne z punktu widzenia ergonomii pracy jego użytkowników bądź logiki biznesowej. Najsłynniejszym bodaj założeniem tego typu było skracanie formatu daty zapisywanej przez pierwsze systemy informatyczne tylko do dwóch ostatnich cyfr roku. Jego efektem stał się tzw. problem roku 2000, który ostatecznie nie doprowadził do masowego cofania zegarów do roku 1900, jednak tylko dlatego, że odpowiednio wcześnie firmy posiadające programy wrażliwe na nadejście nowego millenium poniosły koszty dokonania odpowiednich zmian. Zatem im mniej szczegółowo określone wymagania wobec systemu, tym gorzej dla zleceniodawcy. Po podpisaniu umowy wdrożeniowej wszystko, co niedokładnie opisane, staje się względne i podlega kosztownej interpretacji liczonej w słono opłacanych osobodniach pracy. We własnej praktyce zawodowej autor napotkał wiele anegdotycznych wręcz sytuacji, które dobrze oddają specyfikę „świata informatyków”. Jedna z nich dotyczy zgłoszenia błędu systemu, który to błąd polegał na bardzo długim czasie generowania dokumentu dossier reklamacyjnego klienta (ok. minuty), przy zakładanym pierwotnie czasie ok. 10 sekund. Pierwsza odpowiedź na to zgłoszenie ze strony członka zespołu projektowego brzmiała: „Nie wiem, jak u Pana, ale u mnie dossier generuje się w czasie od 4 do 10 sekund. Natomiast przygotowanie procesu generowania trwa kilkadziesiąt sekund”. Dopiero monit ze wskazaniem, że z punktu widzenia użytkownika systemu taki podział nie ma znaczenia i liczy się tylko czas, jaki musi upłynąć, zanim będzie on mógł korzystać z dokumentu, skłoniło informatyka do wykonania czynności optymalizacyjnych.

Źródło: Deszczyński B., 2011, CRM. Strategia. System. Zarządzanie zmianą, Wolters Kluwer, Warszawa, s. 154-165