Informatyczny węzeł gordyjski?
(1 votes, average: 5 out of 5)
Loading ...Tags: CRM
Jeżeli kiedykolwiek spotkacie się z opinią, że wdrożenie CRM w firmie jest rzeczą prostą, nie dajcie się zwieść jej autorowi. CRM to nie tylko instalacja mnóstwa dziwnie nazwanych modułów na serwerze. To przede wszystkim zmiana sposobu pracy, a często i myślenia. To mix biznesu i technologii.
Dane z rynku nie są optymistyczne. Prawie połowa dużych firm inwestujących w CRM nie osiąga założonych przed wdrożeniem celów. Wina zrzucana jest nader często na dział IT i jego kierownictwo, co dowodzi całkowitego niezrozumienia miejsca CRM w organizacji. Z badań agencji McKinsey® przeprowadzonej wśród 60 firm na rynku amerykańskim, które wdrożyły CRM wynika, iż na sukces wdrożenia największy wpływ ma nie tylko wykorzystywany software ale również wiele innych elementów. Menadżerowie zapytani o najważniejsze czynniki podawali, że równie ważne jest:
Tab. 1. Wpływ poszczególnych działań na sukces wdrożenia systemu CRM, odpowiedzi respondentów podane w %. Kolorem ciemniejszym oznaczono wdrożenia postrzegane w firmie jako sukces, kolorem jaśniejszym - porażki. Według raportu agencji McKinsey®.
Sukces wdrożenia nie zależy jedynie od zapewnienia stosownych funduszy ze strony zarządu firmy (co czasami jest sukcesem samym w sobie). Gros naszej pracy poprzedzającej wdrożenie musi zostać wykonane w sferach wykraczających poza serwerownie i dział IT. Jak zatem przygotować firmę do wdrożenia oraz skutecznie pracować z zespołem realizującym projekt? Co zrobić, żeby nie znaleźć się w gronie 50% firm zapisujących przedsięwzięcie po stronie strat?
1. Czy opłaca się wdrażać CRM?
Zanim zaczniemy wybierać rozwiązanie i dostawcę, zacznijmy od zbudowania zespołu analitycznego. Jego członkami powinni być specjaliści oraz pracownicy wszystkich działów zaangażowanych we wdrożenie. W późniejszym czasie będą oni uczestniczyć w rozmowach z dostawcami systemu oraz czynnie nadzorować wdrożenie CRM. Pierwszym zadaniem postawionym analitykom powinno być sformułowanie pytania - Czy to się w ogóle opłaca?. Aby udzielić odpowiedzi , zespół musi wykonać (czasem tytaniczną pracę) polegającą na:
- analizie obecnego modelu i procesów biznesowych przedsiębiorstwa. Często zdarza się, iż nawet w dużych korporacjach nie ma takiego modelu, a połowa procesów nie doczekała się udokumentowania;
- analizie wpływu wdrożenia CRM na sposób prowadzenia biznesu oraz ocenie skutków wywołanych ewentualną porażką;
- analizie gotowości organizacji do radzenia sobie z problemami pojawiającymi się w trakcie i po wdrożeniu. Oprócz tych związanych z infrastrukturą techniczno-informatyczną (architektura sprzętowa, łączność, integracja z istniejącymi systemami) oraz bezpieczeństwem danych (nie zapominajmy tu również o rozwiązaniach prawnych) większość problemów wywołuje tzw. „czynnik ludzki”. Opór przed zmianą, problemy komunikacyjne, trudności w zdefiniowaniu potrzeb powodują, że ewolucja sposobu myślenia związana z wdrożeniem CRM może okazać się bardziej kosztowna niż same licencje.
Wnioski z powyższej analizy mogą być naprawdę bardzo zaskakujące.
2. Po co nam ten CRM?
Zdefiniowanie oczekiwań wobec systemu CRM jest nie lada wyzwaniem. Pamiętajmy, że system nie jest magiczną skrzynką rozwiązującą wszystkie problemy użytkowników. W definiowaniu potrzeb muszą (powtarzam - muszą) brać udział przedstawiciele wszystkich działów przedsiębiorstwa, zaangażowanych we wdrożenie. Wiadomo jednak, iż lista powstałych życzeń może być bardzo długa. Należy zatem zdefiniować wymagania, które mają najwyższy priorytet i mają kluczowy wpływ na procesy biznesowe realizowane w firmie. Nie zakładajmy, że od razu spełnimy wszystkie wymagania biznesowe. Ile wówczas trwałoby wdrożenie? Jak szybko zobaczylibyśmy pierwsze efekty?
Tworząc listę warto zastanowić się nad sposobem i zakresem integracji systemu CRM z posiadanymi już przez przedsiębiorstwo aplikacjami back-office. Wymagania przez nas zebrane nie mogą ograniczać się tylko do tych stricte informatycznych. Konieczne mogą okazać się zmiany w samej metodyce realizacji poszczególnych działań, ich obsłudze prawnej, logistycznej itp. Nie lekceważmy tych wymagań - to też wpływa na CRM!
3. Co wybrać?
W momencie, kiedy zdefiniujemy procesy biznesowe oraz stworzymy wstępną listę wymagań wraz z określonymi ich priorytetami możemy przystąpić do wyboru rozwiązania. Oprócz kryterium ceny, przy wyborze rozwiązania warto zastanowić się czy system:
- pokrywa wszystkie wymagania, które zdefiniowaliśmy jako priorytetowe, a jeżeli nie, to czy w łatwy sposób można je osiągnąć - ma budowę modułową, pozwalającą na wdrażanie poszczególnych pakietów funkcjonalności i jak moduły są ze sobą powiązane;
- ma możliwość rozbudowy i dostosowania do unikalnych potrzeb przedsiębiorstwa;
- ma referencje - nikt nie powie nam lepiej jak działa system niż jego użytkownicy.
Jeśli nie decydujemy się na samodzielne wdrożenie CRM, bądźmy bardzo ostrożni w wybieraniu firmy wdrażającej. Sama wielkość firmy nie decyduje jeszcze o jej kompetencjach, a niskie stawki mogą się odbić rykoszetem przy testowaniu dwudziestej łaty do dziesiątej poprawki. Najlepiej sprawdźmy referencje firm u źródła. Trochę wysiłku „przed” może zaoszczędzić nam kilkunastu pasemek siwych włosów „po”.
4. CRM to gra zespołowa.
Nawet jeśli zdecydowaliśmy się na wynajęcie firmy wdrożeniowej, pamiętajmy: to jest nasze wdrożenie i nikt za nas go nie zrobi. Zbudujmy zatem zespół, który zrealizuje po naszej stronie wszystkie funkcje związane z wdrożeniem systemu. Ustalmy sposób komunikacji pomiędzy poszczególnymi członkami zespołu przed, a nie w trakcie trwania projektu. Pamiętajmy, że wdrożenie mocno aangażuje poszczególne osoby. Założenie , iż będą one pracować w projekcie w tzw. „magicznym międzyczasie” jest bardzo ryzykowne.
Budując zespół pamiętajmy o:
- zaangażowaniu kierownictwa średniego i wysokiego szczebla. CRM często wymaga podejmowania decyzji zmieniających funkcjonowanie kluczowych procesów w firmie. Zabezpieczmy sobie czas osób decyzyjnych w projekcie.
- określeniu jasno i wyraźnie osób odpowiedzialnych po naszej stronie za poszczególne produkty (z imienia i nazwiska, telefonu i adresu, jeśli trzeba). Zasada „rozmytej odpowiedzialności” tu akurat na pewno się nie sprawdzi.
- wyznaczeniu osób odpowiedzialnych za komunikację w poszczególnych podzespołach. „Awarie na łączach”, czyli brak przepływu informacji pomiędzy zespołami powoduje szkody porównywalne do wysadzenia w powietrze pokoju developerów w środku implementacji.
- informujmy pracowników nie biorących bezpośrednio udziału we wdrożeniu o czekających ich zmianach. Dajmy się im przyzwyczaić do tej myśli. Umiejętnie i odpowiednio wcześniej podana informacja pozwoli zmniejszyć naturalny u ludzi lęk przed zmianą, a co za tym idzie - niechęć do projektu. Z drugiej strony stonuje, często nadmierne, oczekiwania wobec wdrażanego systemu.
5. Co jeśli się nie uda?
Wiadomo, że optymizm w projekcie jest potrzebny, ale zastanówmy się, co będzie, jeśli wdrożenie się nie uda. Jakie będą tego efekty? Miejmy zatem przygotowany plan „B”.
Drukuj
Poleć znajomemu
Czerwiec 18th, 2008 at 5:23 pm
Cytat:
> Aby udzielić odpowiedzi , zespół musi wykonać (czasem tytaniczną pracę)
> polegającą na:
> analizie obecnego modelu i procesów biznesowych przedsiębiorstwa.
> Często zdarza się, iż nawet w dużych korporacjach nie ma takiego modelu,
> a połowa procesów nie doczekała się udokumentowania
Pytanie czy analiza obecnego modelu i procesów biznesowych przedsiębiorstwa nie jest zadaniem “zbyt tytanicznym”. Czy jeśli model taki zostanie w końcu zbudowany, to jeszcze będą jacyś klienci. Takie “wodospadowe” podejście pt. dokonajmy całościowej analizy i zbudujmy procesy a potem myślmy o CRM może być chyba mało realne. Poza tym jeśli mamy zrobić analizę obecnego modelu i procesów w przypadku dużej firmy to zanim ją skończymy te procesy mogą się zmienić.
Czerwiec 18th, 2008 at 8:16 pm
Czy z tego wykresu nie wynika, że pod uwagę wzięto 30 nieudanych wdrożeń po prostu. Jakoś nie za bardzo wyobrażam sobie dlaczego porównywane są udane i nieudane wdrożenia i jaki to ma cel (może w źródłowym raporcie jest więcej informacji - gdzie go można znaleźć?)
Czerwiec 19th, 2008 at 7:42 am
Kolego Sceptyku
Tytaniczna praca (no może nie aż tak) nad modelem procesów to nie produkcja setek diagramów (choć znam takie projekty ale one są rozliczane czas i materiał ;)) a odkrycie, zrozumienie i udokumentowanie procesów tworzących wartość w organizacji. To abstrakcyjny model firmy a mieści sie nie raz na kilkudziesięciu diagramach nawet dla dużej firmy.
Wodospadowe podejście. W inżynierii oprogramowania często krytykowane ale dlaczego? Bo wiele metodyk to metodyki tak zwane prototypowe czyli tak długo produkujemy “jakiś program” aż klient uzna, ze trafiliśmy w jego potrzeby. To czasochłonne, kosztowne i faktycznie nie ma mowy o wodospadowej metodyce.
Jednak projekt CRM (nie tylko, każdy programistyczny dla biznesu) polega na tym, że do poznanej i udokumentowanej strategii rynkowej firmy (jej modelu biznesowego) tworzymy narzędzie, które będzie ją wspierało. Mamy więc kluczową pierwszą kaskadę: udokumentowanie organizacji i jej modelu docelowego. Druga kaskada: opracowanie wymagań na oprogramowanie i wdrożenie.
Osobiście nie wyobrażam sobie iteracji na zasadzie: oprogramowanie nam nie wyszło więc zmieniamy model biznesowy firmy to może za kolejnym razem trafimy……
Czerwiec 19th, 2008 at 9:32 am
Jednak się nie zgadzam. Po pierwsze upraszczasz przeciwstawiając “porządne” podejście wodospadowe względem “nieporządnego” prototypowego. IMHO alternatywą jest podejście agile a nie prototypowe (mimo iż w agile prototypy są wykonywane). Proponowana przez Ciebie ścieżka działań w praktyce wygląda zazwyczaj tak:
1. Budowa CRM odbywa się z punktu widzenia organizacji a nie klienta (a CRM ma tworzyć wartość na styku firma klient, więc powinien uwzględniać punkt widzenia klienta)
2. Pierwszą kaskadę wykonują “analitycy biznesowi”, którzy “dokumentują organizację”. To znaczy opisują procesy, procedury oraz różnego rodzaju struktury korporacyjne. Ci analitycy często mają mało wspólnego z CRM, jego celami itp.
3. Drugą kaskadę projektują “wdrażający” (po stronie organizacji i poza nią). I znowu książkę z wymaganiami piszą ludzie oderwani od problematyki CRM, możliwości oprogramowania czy (BARDZO CZĘSTO) ludzi rzeczywiście kontaktujących się z klientem.
4. Efekt: Wdrożony system CRM, który realizuje … no właśnie (prześledź te kroki i zastanów się co dzieje się z wartością dla klienta i dla organizacji - po kolejnych “obcięciach”
Alternatywa według “złych” metod prototypowania:
1. Zastanawiamy się DLACZEGO? potrzebujemy CRM. Jakie problemy ma CRM rozwiązywać w organizacji (śledzić co się dzieje ze zgłoszeniami klientów, realizować strategiczną analizę wartości klienta). Powstają “use-cases” (aby uzyskać wartość, potrzebuję)
2. Priorytetyzujemy cele z listy 1
3. Zastanawiamy się CO? musi być wdrożone, żeby zrealizować listę 1
4. Dzielimy to na iteracje i opisujemy JAK? musi być wdrożone
5. Iteracje są podzielone tak, żeby każda dostarczała jedną funkcjonalność od “A do Z” (możesz to nazwać prototypem ;-))
W efekcie “małymi” obrotami dostarczamy wartość organizacji. Co więcej, możemy zacząć na przykład od jednej z linii produktowych i następnie przenosić się na inne. Efekt - małymi krokami mamy wartościowy CRM, do którego wprowadzamy ludzi, organizacje, systemy itp. Z drugiej strony mamy wdrożenie pt. NIC (analiza) NIC (analiza) NIC (wdrażanie) BACH (jest niesamowity CRM).
Przepraszam za uproszczenia i stosowanie skrótów sieciowych, ale to w końcu blog.
Pozdrawiam
Sceptyk
Czerwiec 19th, 2008 at 2:25 pm
Aby nie rozciągać tego tekstu odpiszę bez cytowania a powołując się na punkty.
Nie powiedziałem nigdzie, że „nieporządne” są metody prototypowania i że „porządne” są wodospadowe. Prototypy są stosowanie tak gdzie użytkownik nie określił wymagań (bo sam je odkrywa lub po prostu nie umiał), uważam, że prototypowanie jest nadużywane jako metoda radzenia sobie z brakiem wymagań lub złą ich jakością.
Agile owszem, także stosuję na etapie analizy i modelowania ale nie powinno Agile kojarzyć się z ubogą lub wręcz brakiem dokumentacji i pomijaniem etapów analizy i projektowania. Agile to nie rozpoznanie bojem.
1. Nigdzie nie stwierdziłem, że „Budowa CRM odbywa się z punktu widzenia organizacji a nie klienta”.
2. Skąd teza „Ci analitycy często mają mało wspólnego z CRM, jego celami itp.”, pewnie są tacy analitycy ale to kwestia tego kto ich zatrudnia i stawia im zadania a nie analityk to robi.
3. Drugą kaskadę projektuje projektant, gdzie on jest w projekcie to kwestia projektu.
4. Opis wzięty z poza mojej wypowiedzi.
Nie polemizuję z oczywistymi ogólnikami w rodzaju rozwiązania problemu „po co nam CRM” bo to oczywiście należy zrobić. Kolejne funkcjonalności to nie iteracje. Iteracje to kolejne podejście do „tego samego”. Iteracyjnie tworzy się model wymagań lub projekt ale wdraża się je raczej etapami, funkcjonalnościami itp.
Nie rozumiem na końcu tego NIC (analiza) ….. Każdy projekt w którym powstaje oprogramowanie można podzielić na dwa etapy (za Yourdonem): wykonanie analizy i opisanie tego co program ma robić (analiza wymagań i ich specyfikacja) oraz określenia tego jak program ma to robić (projektowanie i implementacja). To dwie kluczowe kaskady. Każdy z tych etapów wewnątrz jest realizowany iteracyjnie ale między nimi jest wyraźna granica, którą widać choćby pod postacią SIWZ w przetargach na wykonanie lub wdrożenie oprogramowania (SIWZ zawiera opis przedmiotu zamówienia czyli wymagania). Moim zdaniem w przypadku systemów CRM określenie wymagań jest po prostu znacznie trudniejsze i to chciałem tylko napisać by zwrócić na to uwagę.
Czerwiec 21st, 2008 at 1:13 pm
Przede wszystkim Pokój.
1. Cykl kaskadowy wiąże się dla mnie z określonym (moim zdaniem złym) podejściem do projektowania czegokolwiek (nie stosuje się go także w innych dziedzinach inżynierii, nie tylko w IT - oprócz postępowań administracyjnych i związanych z nimi SIWZ’ów)
2. Nie zgadzam się ze stwierdzeniem, że “Prototypy są stosowanie tak gdzie użytkownik nie określił wymagań (bo sam je odkrywa lub po prostu nie umiał), uważam, że prototypowanie jest nadużywane jako metoda radzenia sobie z brakiem wymagań lub złą ich jakością.”:
- Prototyp ma realizować określony cel i jeśli prototypujący nie zna tego celu, to samo prototypowanie jest do kitu. W wielu metodykach stosuje się prototypy do różnych celów (np. w GUIDE do prototypowania użyteczności/ergonomii, w metodykach do planowania architektury jako tzw. technologiczny proof-of-concept). Prototyp - powinien być zaplanowany i zrealizowany z żelazną konsekwencją.
- Prototyp jest dobrą metodą na pokazanie użytkownikowi jak wyglądają jego wymagania w praktyce. Zwłaszcza, gdy chodzi o użyteczność - tzn. pokaz tego, jak będzie wyglądał interfejs użytkownika czy look&feel systemu.
- Prototyp nie jest poszukiwaniem właściwego projektu. Jest “demem” teo co ma być. W szczególności - ja jestem fanem wyrzucania prototypów do śmieci (nawet jeśli się udały). Takie założenie nie pozwoli na przenosić prowizorki do końcowego systemu.
3. Prototyp - TAK. Prowizorka - NIE
4. Według mnie oddzielenie analityków od projektantów i programistów zawsze prowadzi do problemów (tak samo jak oddzielenie klienta od wykonu). Jeśli masz na myśli, że tak nie powinno być (w ksiązkowym podejściu wodospadowym tak jest) to zgadzam się z całą resztą Twojej wypowiedzi.
Czerwiec 23rd, 2008 at 11:25 am
Myślę, że z dwóch stron zmierzamy do tej samej tezy: projekty mają etapy, etapy te mogą być powtarzane, prowizorka jest zawsze zła :).
W kwestii podziałów na etapy: oddzielenie etapu analizy potrzeb i projektu od implementacji jest najstarszą praktyką wypracowaną przez tysiące lat inżynierii budowlanej, którą w kwestii złożoności i oczekiwanej jakości porównuje się z inżynierią oprogramowania. Yourdon już pisał, że budę dla psa można zbudować zaczynając pracę od razu, z pominięciem analizy i projektowania jednak niektórzy probują tak budować nie tylko swoje domy ale wielkie budynki. Prowizorka, którą ja często obserwuję to prowizoryczna analiza, niestety często nawet w dużych firmach IT. Nie wyobrażam sobie także budowy wysokościowca w centrum miasta metodą prototypowania.
Jest kwestią semantyczną co nazywamy prototypem jednak budowa domu, podobnie jak oprogramowania, nie powinna być prowadzona metodą kolejnych prób zbudowania go. Dla mnie prototypem dla zamawiającego może być GIU czy model zachowania się systemu ale nie kolejne implementacje, te raczej to raczej wersje.
Uważam, że ma sens oddzielenie etapu analizy i projektowania od kodowania (a nie analizy od projektowania i kodowania). Często programista jest także projektantem architektury co nie jest dobrą praktyką (i to jest także zdanie np. E.Yourgona nie moje).
Wydaje mi się, że dobrą praktyką jest stosowania wzorca MVC, wtedy rolą analityka jest doprowadzenie do powstania modelu dziedziny systemu i opisu reguł biznesowych a także ograniczeń zaś rolą zespołu implementacji reszta projektu. Jest to klarowny podział. Brak podziału projektu na takie lub podobne kaskady powoduje, że nie da się wydzielić etapu wyceny i zatwierdzenia wymagań przez zamawiającego bo jak inaczej określić budżet i termin projektu? Niestety czasy projektów rozliczanych czas-i-materiał się kończą i tu jest poważne wyzwanie dla inżynierii oprogramowania.
Myślę, że kolejne szczegóły tej wymiany myśli mogą już znudzić czytelników tego forum, zapraszam więc na priv. i przy okazji przedstawienie bo nie tylko ja nie wiem z kim rozmawiam a wiarygodność anonimowej osoby jest jednak znikoma.