Tworzenie szczegółowej wizji procesów i wymagań funkcjonalnych

Tworzenie szczegółowych wymagań w stosunku do systemu CRM, wymaga dobrej orientacji w rzeczywistym funkcjonowaniu procesów, których obsługę ma on zapewnić, umiejętności sprawnej analizy obszernych dokumentów opisujących docelowy ich przebieg oraz przynajmniej podstawowej wiedzy i sprawności w posługiwaniu się systemami

390

Out-of-the-box implementation wdrożenie systemu z „pudełka”, a więc w takiej postaci, w jakiej przygotował go jego producent. Wiąże się z koniecznością dostosowania własnych procesów do modelu, jaki przewidział dostawca oprogramowania.

167

informatycznymi o pokrewnym zastosowaniu. Z powodu tych wymagań, w ramach Grupy Wdrożeniowej CRM powinny istnieć zespoły, w których skład wchodziłby co najmniej jeden: właściciel procesu, pracownik operacyjny przyszły użytkownik systemu (super-user) oraz przedstawiciel działu IT. Rolą właściciela procesu jest dopilnowanie, aby realizacja podstawowych jego celów poprzez pracę w systemie była zapewniona, np. dzięki generowaniu określonego zasobu informacji. Pracownik operacyjny, powinien zweryfikować opis procesu pod kątem możliwości realizacji wymaganych czynności w zaplanowanym czasie, spodziewanej ergonomii obsługi systemu oraz prawdopodobieństwa możliwości pozyskania określonego zasobu danych od klientów. Z kolei pracownik działu IT, ma za zadanie pomóc w transpozycji oczekiwań pozostałych członków zespołu na język informatyki, z użyciem ogólnie obowiązującej terminologii oraz wstępną weryfikację wykonalności postawionych przez systemem zadań. Kwestią absolutnie kluczową w pracach zespołu, jest koordynacja wysiłków wszystkich jego członków, a szczególnie pożądaną cechą, umiejętność abstrakcyjnego myślenia – wyobrażania sobie pracy za pomocą jeszcze nieistniejącego narzędzia.

Posiłkując się przykładowym procesem sprzedaży przedstawiono poniżej, jak mógłby wyglądać towarzyszący mu opis wymagań wobec systemu. Rys. 4.2. zawiera uproszczony schematu opisujący przebieg procesu sprzedaży, realizowanego przez sprzedawcę samochodów, dalej zaś umieszczono uszczegółowiony opis procesu.

Rys. 4.2. Uproszczony model procesu sprzedaży w branży motoryzacyjnej.

Źródło: Opracowanie własne.

Proces (P1) – sprzedaż samochodów.

Proces ma na celu pomoc w kreowaniu i prowadzeniu nieanonimowych kontaktów handlowych z nowymi klientami oraz poprzez wykorzystywanie mechanizmów opieki posprzedażnej, zwiększenie skuteczności w pozyskiwaniu zamówień od klientów, którzy dokonali już pierwszego zakupu. Dodatkowym celem jest dostarczenie kierownikom sprzedaży informacji o aktywności sprzedawców, jednak przy założeniu łączenia czynności sprawozdawczych/czysto biurokratycznych z produktywnymi działaniami związanymi z kolejnymi etapami kontaktów z klientami.

1. Rejestrowanie kontaktów.

1.2. Sprzedawca stara się uzyskać dane osoby, z którą rozmawia w możliwie najszerszym zakresie. Minimalny zakres danych jaki należy zebrać powinien umożliwiać Pierwszy kontakt Analiza potrzeb Jazda próbna Oferta Auto zamówione wykonanie: eksport AutoNet Wydane auto wykonanie: eksport AutoNet Zamówienie auta Wydanie auta

168

identyfikację i powtórny kontakt z klientem. Z tego powodu system CRM tworzy nowy rekord klienta, jeśli sprzedawca zna co najmniej:

- imię i nazwisko,

- telefon (lub e-mail lub pełny adres),

- model samochodu, którym osoba ta jest zainteresowana ( MENU AUTA NASZE), określenie czy jest to samochód nowy czy używany (radiobutton), (lub model samochodu, który osoba ta aktualnie posiada –  MENU AUTA OBCE),

- nazwę firmy (radiobutton klient indywidualny / klient instytucjonalny). 1.3. Po uzyskaniu niezbędnych danych sprzedawca zapisuje je w systemie CRM.

1.3.1. System nie pozwala na zapis, gdy sprzedawca dysponuje mniejszą ilością danych niż określone w pkt. 1.2. Rekord nie jest tworzony, a sprzedawca ma możliwość albo uzupełnienia danych albo opuszczenia okna wprowadzania danych ( OKNO KLIENT 1).

1.4.Wraz z tworzeniem rekordu system CRM:

1.4.1. Sprawdza, czy w systemie nie zapisano już danych tego samego klienta. Jeśli nie – pozwala na zapis. Jeśli zapisano już identycznego klienta lub klienta o zbliżonych danych, rozpoczyna procedurę weryfikacji danych klienta.

1.4.2. Automatycznie określa stan kontaktów z klientem w ( OKNO KLIENT 1) jako kontakt: „Pierwszy kontakt”.

1.4.3. Automatycznie zakłada w ( OKNO KLIENT 1) zadanie do realizacji „Przeprowadź analizę potrzeb”, ze statusem pilności wykonania „Średni”. Domyślny termin wykonania 14 dni. Data wykonania edytowalna dla tego i

innych kontaktów wprzód i wstecz, przy założeniu, że nie można zapisać daty przeszłej. To oraz inne zadania widoczne również w (OKNO START).

1.4.2.1.W razie nie wykonania zadania „Przeprowadź analizę potrzeb” oraz innych zadań:

1.4.2.1.1. Generowany jest alert „Opóźnienia” widoczny również dla przełożonego użytkownika (tak jakby to on założył to zadanie). 1.4.3. W miarę pozyskiwania kolejnych danych, sprzedawca zapisuje je w systemie

CRM odnajdując rekord konkretnego klienta. Mogą one być również uzupełnione przez innych członków organizacji lub od nich pośrednio pochodzić (patrz P6. Lead Management). Sprzedawca odnajduje dane korzystając z poniższych możliwości:

1.4.3.1.1. Listy otwartych zadań ( OKNO START), 1.4.3.1.2. Listy aktualnych kontaktów ( OKNO START), 1.4.3.1.3. Wyszukiwarkę klientów ( FUNKCJA SZUKAJ).

1.4.4. Dalsze kontakty przedsprzedażowe w systemie może rejestrować samodzielnie (manualnie) sprzedawca, ale w zależności od zakresu pozyskanych danych i upływającego czasu system CRM sam wymusza rejestrację niektórych danych i wykonywanie pewnych czynności poprzez określanie zadań.

1.4.4.1. Obowiązuje zasada, iż manualna rejestracja danych lub kontaktu przez użytkownika przerywa i aktualizuje automatyczną ścieżkę biegnącego zadania. Zatem wykonanie zadania bliższego sprzedaży w stosunku do

aktualnie zaplanowanego przez system zgodnie z modelową ścieżką sprzedaży, prowadzi do jego anulowania i założenia przez system zadania najbliższego wg modelu sprzedaży ostatnio wykonanego kontaktu.

169

1.4.4.2.Po ustaleniu potrzeb klienta (wykonanie zadania „Przeprowadź analizę potrzeb”), a więc zapisaniu danych:

- model samochodu, którym osoba ta jest zainteresowana, określenie czy jest to samochód nowy lub używany (ORAZ model samochodu, który osoba ta aktualnie posiada X),

- rocznik samochodu posiadanego,

- termin wymiany samochodu posiadanego,

- spodziewany budżet przeznaczony na zakup samochodu poszukiwanego, - preferowana forma finansowania zakupu,

- szacowane prawdopodobieństwo zakupu,

- przynajmniej jedna z 10 kategorii preferencji zakupu (MENU PREFERENCJI)

system CRM:

1.4.4.2.1. Automatycznie określa stan kontaktów z klientem w ( OKNO KLIENT 1) jako „Analiza potrzeb wykonana”.

1.4.4.2.2. Automatycznie zakłada zadanie realizacji Kontaktu „Przeprowadź jazdę próbną”, ze statusem pilności wykonania „Średni”. Termin wykonania 21 dni.

1.4.4.3. Wykonanie zadania „Przeprowadź jazdę próbną” może przebiec wg dwóch ścieżek:

1.4.4.3.1. Sprzedawca może początkowo dokonać rezerwacji samochodu. Wymaga to określenia:

- samochodu przeznaczonego do jazd próbnych, - osoby biorącej udział w jeździe (OKNO KLIENT 2), - terminu, godziny rozpoczęcia i zakończenia jazdy.

1.4.4.3.1.1.System przy zapisie weryfikuje, czy dany samochód w podanym terminie nie został już zarezerwowany. Jeśli nie zapisuje kontakt i dokonuje wpisu w ( KALENDARZ JAZD). Jeśli nie, zwraca odpowiedni komunikat.

1.4.4.3.1.2. Zarezerwowanie terminu jazdy próbnej powoduje odpowiednie przesunięcie zadania „Przeprowadź jazdę próbną”.

1.4.4.3.2. Sprzedawca może od razu przeprowadzić jazdę próbną. Wymaga to zapisania dodatkowych w stosunku do rezerwacji danych:

- adresu osoby biorącej udział w jeździe ( OKNO KLIENT 1),

- serii i numeru prawa jazdy osoby biorącej udział w jeździe ( OKNO KLIENT 2).

1.4.4.4.W momencie zapisania tych danych, system:

1.4.4.4.1. Generuje i udostępnia w postaci pop-upa formularz jazdy testowej, który można wydrukować ( FORMULARZ JAZD)

1.4.4.4.2. Automatycznie określa stan kontaktów z klientem w ( OKNO KLIENTA 1), jako „Przeprowadzono jazdę próbną”.

1.4.4.4.3. Automatycznie zakłada zadanie „Sporządź ofertę”, ze statusem pilności wykonania „Średni” zgodnie z F4.6. Termin wykonania 7 dni.

1.4.4.5. Sporządzenie oferty przebiega w zewnętrznym konfiguratorze. Jednak dostęp do niego uzyskiwany jest poprzez przycisk „Oferta”, dla każdego samochodu poszukiwanego z osobna ( INTEGRACJA Konfigurator). 1.4.4.6. Po sporządzeniu oferty, sprzedawca pobiera wygenerowany w

Konfiguratorze plik. Czynność ta oznacza dla systemu przekazanie klientowi oferty, w związku z czym system:

170

1.4.4.6.1. Automatycznie określa stan kontaktów z klientem w ( OKNO KLIENT 1) jako „Przekazano ofertę”.

1.4.4.6.2. Automatycznie zakłada zadanie „Potwierdź chęć zakupu” ze statusem pilności wykonania „Średni” zgodnie z F4.6. Termin wykonania 14 dni.

1.4.4.7. Sprzedawca potwierdza chęć zakupu samochodu poprzez zamówienie dla tego klienta samochodu lub też rezerwację istniejącego na stanie placu dealerskiego samochodu w systemie DMS (INTEGRACJA DMS). Po zarejestrowaniu tego faktu system CRM:

1.4.4.7.1. Automatycznie określa stan kontaktów z klientem w ( OKNO KLIENT 1) jako „Samochód zamówiony”.

1.4.4.7.2. Automatycznie zakłada zadanie realizacji Kontaktu „Ustal termin wydania samochodu”, ze statusem pilności wykonania „Średni”. Termin wykonania 7 dni od czasu uzyskania informacji o dostępności zamówionego samochodu (w przypadku samochodu z placu dealerskiego czas liczony od razu).

1.4.4.8. Sprzedawca potwierdza termin wydania samochodu poprzez manualne zaznaczenie kontaktu „Potwierdzony termin wydania”. Termin ten wyświetlany jest w ( OKNO START).

1.4.4.9. Jeśli DMS ( INTEGRACJA DMS) nie przekaże informacji o sprzedaży do czasu określonego przez sprzedawcę jako termin wydania samochodu, kontakt „Potwierdzony term wydania” jest kasowany i po potwierdzeniu przez sprzedawcę (pop-up) zastępuje go kontakt „Rezygnacja”.

1.4.4.10. Jeśli DMS ( INTEGRACJA DMS) przekaże informacje o sprzedaży, system:

- automatycznie zapisuje dane tego samochodu w ( OKNO KLIENT 3), - automatycznie zapisuje kontakt „Wydane auto” w ( OKNO KLIENT 2), - rozpoczyna się proces (P2) – Opieka posprzedażna.

Zamieszczony powyżej opis, odpowiada w dużej mierze autentycznemu dokumentowi

przygotowanemu w ramach wdrożenia systemu klasy CRM dla marek Volkswagen i Audi w Polsce. Mimo, że początkowo nie czyta się go łatwo (chociażby z powodu zagnieżdżenia

podpunktów), istnieje kilka bardzo poważnych argumentów, przemawiających za uszczegółowieniem w podobny sposób wszystkich procesów obsługiwanych przez system. Należy do nich zaliczyć m.in.:

- wczesną weryfikację oczekiwań wobec systemu,

- ułatwienie i przyspieszenie prowadzenia późniejszych prac (tworzenie projektu technicznego),

- uzyskanie zbliżonych do docelowych wartości ofert,

- uzyskanie jednoznacznego określonego opisu działania systemu, na wypadek sporu interpretacyjnego z dostawcą oprogramowania.

Zwykle łatwiej jest uzyskać zgodę wszystkich stron w stosunku do ogólnych założeń niż wówczas, gdy trzeba akceptować rozwiązania szczegółowe. Podobnie w toku prac Grupy

171

Wdrożeniowej CRM, jej członkowie przygotowując wspólny projekt założeń do systemu, mogą mieć odmienną wizję jego funkcjonowania w praktyce, niż nieświadomie akceptują. Problem innej natury dotyczy tych członków Grupy Wdrożeniowej, których zakres obowiązków jest tylko luźno związany z jej pracami (np. pełnią rolę „wypożyczonych” ekspertów w konkretnej dziedzinie). Współtworząc jedynie ogólne wymagania wobec systemu, nie muszą dzielić się w pełni swoją szczegółową wiedzą, ani poświęcać wiele czasu na rzetelną analizę funkcjonowania jego przyszłych komponentów. W ten sposób nie ponoszą odpowiedzialności za występujące później problemy, gdyż „nigdy nie odpowiedzieli błędnie na zadane pytanie”391. Oczywiście niejako z założenia, w modelowo zarządzanym projekcie zmian powinno się zadbać o odpowiednią motywację i promowanie zaangażowania członków Grupy Wdrożeniowej. Wprowadzenie zasady szczegółowego planowania procesów obsługiwanych przez system, może w tym jednak tylko pomóc.

Czas zainwestowany w tworzenie szczegółowego opisu oczekiwań wobec systemu,

skraca proces wyboru dostawcy oprogramowania, a po podpisaniu umowy, jeden z ważniejszych etapów wdrożenia – wykonanie projektu technicznego. 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 zleceniodawcy392

. 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. W drugim, dość prawdopodobnym przypadku, oznacza to 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.

Wymiar finansowy skrócenia tworzenia projektu technicznego systemu, również jest potencjalnie znaczący. Zwykle na tym etapie, po stronie dostawcy oprogramowania zaangażowani są najwyżej opłacani specjaliści. Każdy dodatkowy dzień ich pracy, związany

391

Np. na pytanie menadżera projektu o dostępność informacji o specyfikacjach sprzedawanych przez firmę samochodów w jej systemie księgowym (który należy zintegrować z systemem CRM), opiekun tego systemu może odpowiedzieć, że te specyfikacje się w nim znajdują. Jednak pominięcie faktu, że przed trzema laty dokonano zmiany systemu księgowego na nowy oznacza, iż nawet po przeprowadzonej integracji, sprzedawcy oraz dział marketingu, nie będą mieli do dyspozycji rozkodowanych specyfikacji starszych pojazdów. A właśnie to ich posiadacze, z racji cyklu wymiany produktu w najbliższym czasie staliby się najlepszymi odbiorcami działań nakierowanych na ponowną sprzedaż. Formalnie jednak, odpowiedź na zadane pytanie była prawdziwa.

392

W swojej praktyce biznesowej, autor spotkał się nawet z rozmowami prowadzonymi w następujący sposób: „Ile kosztuje u was CRM i kiedy możecie być gotowi?”.

172

z mozolnym ustalaniem wraz ze zleceniodawcą niezbędnych do rozpoczęcia prac programistycznych szczegółów, negatywnie odbija się na budżecie. Jeśli mogą oni pracować na bazie profesjonalnie przygotowanej dokumentacji, wspólny wysiłek koncepcyjny polega głównie na pomocy w zrozumieniu biznesowego sensu poszczególnych procesów i kwestii interpretacyjnych.

Właśnie interpretacja oczekiwań zamawiającego przez firmę prowadzącą wdrożenie, ma w przypadku systemu CRM szczególne znaczenie. Jak każdy niemal przetarg kończący 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 tych prac leży w dobrze pojętym interesie zamawiającego. Skoro podejmując się budowy budynku czy

mostu, firmy startujące w przetargu zapoznają się 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 jest to bynajmniej dążenie wynikające z braku motywacji do należytego wykonania 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. Należy jednak założyć, że programiści nie znając dokładnie realiów biznesowych wykorzystania systemu, będą dokonywali założeń upraszczających, niekorzystnych z punktu widzenia ergonomii pracy jego użytkowników, bądź logiki biznesowej. Bodaj najsłynniejszym założeniem tego typu, było skracanie formatu daty zapisywanej przez pierwsze systemy informatyczne tylko do dwóch ostatnich cyfr roku. Jego efektem był tzw. „problem roku 2000”, który ostatecznie nie doprowadził do masowego cofania zegarów do roku 1900, jednak tylko dlatego, że odpowiednio wcześniej firmy posiadające programy wrażliwe na nadejście nowego millenium, poniosły koszty dokonania odpowiednich zmian. Zatem (wypada to podkreślić raz jeszcze) 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 informatyków393

.

393

Z własnej praktyki zawodowej, autora spotkało wiele anegdotycznych wręcz sytuacji, które dobrze oddają specyfikę „świata informatyków”. Jedna z nich odnosi się do zgłoszenia błędu systemu, wskazującego na bardzo długi czas 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:

173

Zamieszczony w niniejszym rozdziale schemat procesu biznesowego (P1) – mimo, że dość szczegółowy, nie wyczerpuje jednak wymagań w stosunku do profesjonalnie przygotowanej dokumentacji oczekiwań wobec systemu. Aby możliwie najlepiej przygotować się do przeprowadzenia technicznego projektu implementacyjnego CRM, Grupa Wdrożeniowa powinna opisać następujące elementy występujące w zapisie (również naszego przykładowego) procesu:

- podstawowy opis systemów integrowanych z systemem CRM oraz zasady tej integracji,

- spodziewane działanie niektórych kluczowych funkcji systemu,

- postulowany layout kluczowych formatek (okien) systemu (w tym formularzy i ważniejszych menu).

CRM nigdy nie jest pierwszym systemem informatycznym funkcjonującym w organizacji. Zwykle firma posiada już systemy wspomagające księgowość, gospodarkę

magazynową, zawierające specyfikację produktów lub nawet kompleksowe systemy klasy ERP. Wdrożenie CRM nie wymaga w prawdzie integracji z wszystkimi innymi systemami funkcjonującymi w przedsiębiorstwie, jednak tam gdzie przemawiają za tym względy ergonomii pracy i szybkości lub jakości wykonywanych procesów, tego rodzaju wysiłek należy podjąć.

Integrację rozumiemy jako przekazywanie gromadzonych i przekazywanych informacji pomiędzy co najmniej dwoma systemami informatycznymi, w celu ich dalszego wykorzystania. Zatem kluczową kwestią jest określenie, jakie mają to być informacje i w jaki sposób będą przekazywane. Raczej nie zdarza się by system CRM wykorzystywał w całości dane dostępne w innej aplikacji394. Podobnie różne mogą być wymagania dotyczące szybkości przekazywania informacji. Proces P1 zawiera odnośnik ( INTEGRACJA DMS). Związany z nim autentyczny opis założeń integracji zamieszczono poniżej. Nie jest to jeszcze dokument odpowiadający na wszystkie niewiadome, jednak z punktu widzenia firmy ubiegającej się o zlecenie stanowią cenne uzupełnienie powiązanych dokumentów opisujących procesy oraz jednocześnie odpowiedź na istotne pytania umożliwiające określenie warunków brzegowych integracji.

procesu generowania trwa kilkadziesiąt sekund”. Dopiero monit ze wskazaniem, że z punktu widzenia

użytkownika systemu nie ma to znaczenia i liczy się tylko czas, jaki musi upłynąć zanim będzie mógł on korzystać z dokumentu, skłoniło informatyka do wykonania czynności optymalizacyjnych.

394

Z wyłączeniem wdrożeń, w których funkcjonalność CRM „nadbudowywana” jest w istniejącym systemie, nie pełniącym dotychczas takiej roli.

174 Integracja z DMS

1. Informacje podstawowe.

System DMS (Dealer Management System) to system księgowo-magazynowy Dealerów. Działa on w architekturze rozproszonej (brak centralnej instalacji), dopuszczalne są lokalne konfiguracje. Jednak na potrzeby tworzenia zbiorczych statystyk, istnieje centralny moduł DMS raz dziennie pobierający dane z całej sieci. Dane pozyskiwane w ten sposób gwarantują zachowanie porównywalności i stałego formatu. Dostępna metoda importu: generowanie raz dziennie pliku w formacie XML. Gotowość wygenerowanego pliku: godzina 0:05. Spodziewana wielkość pliku: 3 – 5 MB.

2. Zakres danych.

Dane pobierane z DMS na potrzeby systemu CRM, będą zawierać nie mniej niż nastepujące obiekty:

2.1. Kartoteka kontrahentów (imię i nazwisko / nazwa firmy, adres, telefony, adresy e-mail, NIP, REGON, wewnętrzny numer porządkowy).

2.2. Kartoteki osób kontaktowych kontrahentów (dane osób powiązanych z kontrahentami: imię i nazwisko, telefony, adresy e-mail).

2.3. Użytkownicy systemu (dane sprzedawców i innych osób korzystających z DMS: imię i nazwisko, login, wewnętrzny numer porządkowy).

2.4. Kartoteki pojazdów (numer nadwozia samochodu, wewnętrzny numer porządkowy, numer rejestracyjny, data pierwszej rejestracji, oznaczenie magazynu, przebieg). 2.5. Dokumenty sprzedaży samochodów nowych (numer dokumentu, numer powiązanego

dokumentu zamówienia, numer klienta, numer samochodu, oznaczenie statusu: dokument nowy/korekta, koszt zakupu, przychód ze sprzedaży).

2.6. Dokumenty sprzedaży rozliczające zlecenia serwisowe (numer dokumentu, znacznik: przegląd/naprawa, numer samochodu, koszt wykonania usługi, przychód z wykonania usługi).

2.7. Dokumenty sprzedaży ze sklepu części zamiennych (numer dokumentu, numer klienta, koszt zakupu, przychód ze sprzedaży).

2.8. Dokumenty zamówień klienta na samochód (numer dokumentu, numer klienta, numer samochodu, termin dostępności samochodu).

2.9. Magazyn – samochody nowe (numer samochodu).

2.10. Magazyn – samochody komisowe (numer samochodu). 2.11. Magazyn – samochody używane (numer samochodu). 2.12. Magazyn – samochody testowe (numer samochodu). 3. Podstawowe zasady wprowadzania danych.

3.1. Wszystkie dane w wyjątkiem danych opisujących stany magazynowe poszczególnych dealerów oraz użytkowników systemu będą miały charakter przyrostowy. Nie będą na tych danych przeprowadzane aktualizacje i wprowadzenie ich do systemu CRM będzie równoznaczne z tym, że jest to ostateczna wersja danych. Dane sprzedażowe mogą być korygowane tylko za pomocą korekty do faktury sprzedażowej. Wówczas w systemie będą widniały dwa dokumenty sprzedażowe związane z jedną sprzedażą.

175

3.2. Kontakt „Rezygnacja” zostanie zarejestrowany, jeśli zostanie wystawiona faktura korygująca do dokumentu sprzedaży.

3.3. Stany magazynowe każdorazowo będą przesyłane w całości, natomiast dane użytkowników systemu mogą być modyfikowane jednak dotyczy to tylko informacji o aktywności konta użytkownika.

Realizacja zadań integracji z DMS będzie ściśle powiązana z zadaniami generowanymi podczas przebiegu procesu (P1) – sprzedaż samochodów.

Nie tylko dobry opis procesu biznesowego stanowi o ergonomii pracy i stopniu zabezpieczenia uzyskania korzyści z pracy z systemem klasy CRM. O jego przydatności decyduje również możliwość wykonywania zidentyfikowanych jako kluczowe funkcji (czynności, procedur), a także przyjazny użytkownikowi interfejs. Określenie czy konkretna aplikacja bazowa będzie w stanie spełnić tego typu wymagania, jest znacznie łatwiejsze niż w przypadku właściwych tylko danej firmie procesów. Mimo to, najlepszym rozwiązaniem jest dokonanie systematyzacji również i tych wymagań, tak aby zapewnienia przedstawicieli działów handlowych konkurujących ze sobą dostawców oprogramowania o „elastyczności” ich produktu, po podpisaniu umowy wdrożeniowej nie przestały być aktualne. Przykładowy opis takich wymagań zamieszczono poniżej.

Funkcja „Szukaj klienta”

1. Podstawowe zastosowanie.

Umożliwia szybkie odszukanie klientów już zapisanych w bazie firmy, przy zastosowaniu podstawowych kryteriów. Istnieje możliwość zastosowania kryteriów logicznych zawężających bądź rozszerzających zapytanie (użytkownik nie musi znać dokładnej wartości

W dokumencie Customer Relationship Management w procesie zarządzania strategicznego przedsiębiorstwem (Stron 165-176)