Sprzedaż i negocjacje AD 2005

Gdzie pracuje ten Gartner?

Nadal obowiązuje reguła, że nie należy podawać ceny nie wiedząc, do czego klient będzie ją porównywał. Bo jeżeli nie ma jakiegoś kontrolowanego przez sprzedawcę punktu odniesienia, zawsze będzie to cena za wysoka. Punktem odniesienia może być droższa oferta konkurencji wsparta stwierdzeniem: "Ale nasz system znacznie lepiej odpowiada potrzebom Państwa przedsiębiorstwa i został już wdrożony w sześciu działających w Polsce firmach o podobnym lub takim samym profilu". Niezła odpowiedź, ale trzeba faktycznie wiedzieć coś o tych sześciu wdrożeniach. Znacznie lepszym argumentem jest korzyść odnoszona przez klienta z zastosowania właśnie naszego systemu, np. wysokie koszty utrzymania obecnego systemu. Oczywiście wypadałoby je znać przed rzuceniem jakiejkolwiek ceny. Doświadczenie uczy, że mechaniczne użycie argumentu - np. o oszczędnościach płynących ze zmniejszenia zapasów - już nie działa. Na klientów działa tylko przykład bardzo mocno związany z ich biznesem, świadczący o tym, że konsultant faktycznie zadał sobie trud zrozumienia, czym jego klient się zajmuje, skąd biorą się jego koszty i co jest dla niego źródłem zysków. Podanie nietrafionego przykładu działa na klientów jak płachta na byka. Jeśli zaczniemy mówić o oszczędnościach na zapasach, a okaże się, że klient za swoje zapasy nie płaci i są one utrzymywane de facto na koszt jego dostawców, to klient niestety uzna nas za półgłówków. Przykłady typu "analitycy na podstawie badań w USA dowodzą, że..." też nie są najlepsze. Do historii przeszła anegdota o kliencie, który na zapewnienia konsultantów o tym, że "według Gartnera wdrożenie systemu o 30% poprawia to i tamto", odparł zirytowany "A gdzie właściwie pracuje ten Gartner?". Zdobycie i zrozumienie sensownego przykładu opłacalności wdrożenia wymaga czasu, stąd - póki naprawdę nie trzeba, nikt ceny nie podaje.

Byle do jutra

Oczywiście, nadal wiele firm sprzedających i wdrażających systemy ERP posługuje się regułą "nie należy mylić sprzedaży z dostawą". Oferują więc bardzo niskie lub wręcz dumpingowe ceny, a później różnymi sposobami windują budżet projektu. Naprawdę nie należą do rzadkości projekty, które miały kosztować 600 tys. euro, a doszły już do 1,6 mln euro i końca nie widać. Z takiego rozpoczętego i puchnącego projektu klientowi nie jest łatwo się wycofać, bo przecież utopił w nim już niebagatelną sumę. Każdy klient ma jakiegoś zwierzchnika, któremu tylko w największej desperacji przyzna się, że wybrał złego dostawcę i na pierwszego stycznia z pewnością nie będzie działającego systemu, a najwyżej kary umowne (jeżeli kontrakt był dostatecznie precyzyjny). Druga strategia niezbyt czysto grających dostawców to godzenie się na stosunkowo niską cenę projektu pod presją konieczności zrealizowania jakiejkolwiek sprzedaży. "Idący pod wodę" dostawca zgodzi się na wszystko, byle tylko utrzymać się na rynku jeszcze kilka miesięcy. W takiej sytuacji klient jest tylko kołem ratunkowym i na niego przerzucone jest całe ryzyko projektu. A przed takim ryzykiem żadna umowa nie jest w stanie klienta zabezpieczyć.

Szczególnie w przypadku mniejszych wdrożeń czyha na klienta jeszcze jedna pułapka. Producent oprogramowania, który nie jest zainteresowany udziałem we wdrożeniu, lecz jedynie sprzedażą licencji i pobieraniem corocznych opłat za utrzymanie systemu, może próbować wepchnąć klienta zdecydowanego już na dany system w ramiona "najlepszego partnera". Wartość "najlepszego partnera" może polegać jedynie na tym, że to partner oferujący swoje usługi niedrogo, spolegliwy w negocjacjach i tym samym szybko doprowadzający do zawarcia kontraktu. Dostawca oprogramowania dostanie swoje opłaty licencyjne i maintenance, a reszta - cóż, to problem klienta i partnera. Producent teoretycznie partnera zarekomendował, w praktyce za jego działania nie bierze i nie ponosi żadnej odpowiedzialności.

Polisa ubezpieczeniowa klienta - jak nabyć, wdrożyć i utrzymać system klasy ERP i jeszcze na tym nie

Sukces wdrożenia nie zależy wyłącznie od jakości wybranego systemu i kompetencji firmy go wdrażającej. Oto rzeczy, które można zrobić, by jeszcze bardziej zwiększyć prawdopodobieństwo sukcesu.

  • Podzielić projekt wdrożeniowy na mniejsze, dobrze określone fragmenty, które zaczynają się kolejno po zakończeniu poprzedniego etapu i po spełnieniu określonych warunków. Koszty (upusty) poszczególnych projektów wynikają ze skali całości przedsięwzięcia, czyli są niższe niż przy realizacji wszystkich części jako zupełnie niezależnych projektów. Dostawca zgodzi się na to, po warunkiem że klient da gwarancję, że jeśli (w ocenie klienta!) wszystko będzie toczyć się dobrze, to projekt będzie rzeczywiście kontynuowany.

    - Od początku uświadomić firmę wdrożeniową, że projekt zastanie przerwany, jeśli usługodawca przestanie dostarczać oprogramowanie i usługi na określonym poziomie. Taki scenariusz musi zostać odpowiednio zabezpieczony w umowie. Po to jednak, żeby nie był to tylko blef, klient musi się odrobinę wysilić i przygotować "Plan B", czyli realizowalny scenariusz działań, który wejdzie w życie, gdy firma wdrożeniowa zawiedzie. De facto musi więc być w stanie wezwać alternatywnego usługodawcę. W praktyce im dalej w projekt, tym trudniej zerwać współpracę z dostawcą, ale jeśli projekt od początku zostanie podzielony na mniejsze części, a do tego klient zatroszczy się o tworzenie odpowiedniej dokumentacji, to przekazanie wdrożenia innej firmie (w przypadku skrajnej niekompetencji i złej woli pierwszej) nie będzie koszmarem. Dokumentacja zawsze jest słabą stroną wszystkich wdrożeń i nacisk na jej sukcesywne tworzenie i przekazywanie klientowi będzie trochę irytował dostawcę, ale bez dokumentacji przekazanie prac wdrożeniowych w inne ręce w trakcie ich trwania jest bardzo bolesne. Albo wręcz trzeba zaczynać od zera.

  • Kontrolować ilość modyfikacji wprowadzanych w czasie wdrożenia. Każda modyfikacja to uzależnienie od jej wykonawcy i dodatkowy koszt przy okazji upgrade'u i rozwoju systemu. Zawsze bowiem trzeba sprawdzać, jak w nowej sytuacji zachowa się dopisany kawałek kodu (ten, kto go pisał, nie mógł przewidzieć wszystkich interakcji), a to kosztuje. Wielkie, sprawne firmy używają systemów, w których 95% funkcji jest standardowych - czy Twoja firma jest aż tak wyjątkowa, czy raczej tylko pokręcona?

  • Na to nie ma siły - trzeba zapewnić po swojej stronie profesjonalne zarządzanie projektem. Znaleźć w swojej organizacji dobrego kandydata na kierownika projektu (jeżeli trzeba
  • dodatkowo przeszkolić i wesprzeć zewnętrznym doradcą), wynająć kogoś do tego projektu, ewentualnie zatrudnić kogoś nowego na stałe. To właśnie w fazie realizacji, a nie wyboru czy negocjacji wykładają się projekty, własnych interesów trzeba umieć dobrze pilnować.

  • SLA, czyli Service Level Agreement. Jest to umowa określająca poziom usług świadczonych klientowi. Ma zastosowanie szczególnie w przypadku usług utrzymania oprogramowania i infrastruktury. Określa czas reakcji usługodawcy na awarie, czas naprawy/wymiany uszkodzonego sprzętu, procedury usunięcia/obejścia problemów o różnym priorytecie, czas dostępności łącza internetowego o określonej przepustowości itp. SLA to bardzo sensowna konstrukcja umowy na utrzymanie oprogramowania, zwłaszcza z tym samym dostawcą, który realizował wdrożenie - czy można sobie wyobrazić bardziej łagodne przejście z fazy implementacji do fazy eksploatacji ? Absolutnie jasne jest, kto odpowiada za prawidłowe działanie systemu (czy będzie to niewłaściwie dobrany serwer, błąd w oprogramowaniu, wadliwa parametryzacja w trakcie wdrożenia, czy też modyfikacja zapętlająca system) - adresat zgłoszenia i serwisant jest zawsze jeden (i nie może twierdzić, że to "tamci sknocili"). Oczywiście, warunki określone w tego rodzaju umowie muszą być możliwe do spełnienia dla obu stron! Wielu klientów do umów na utrzymanie oprogramowania podchodzi na zasadzie "chciałbym być zawsze młody, piękny i bogaty". Dostawcy odpowiadają na to uprzejmie "Klient nasz Pan", licząc, że w razie czego zapisy drobnym drukiem w liczącej 200 stron umowie uchronią ich przed jakimikolwiek konsekwencjami. I tak powstają umowy, w których dostawca zobowiązuje się usunąć, przez całą dobę, dowolny błąd w oprogramowaniu ERP w ciągu dwóch godzin od momentu zgłoszenia, pod groźbą słonych kar umownych. Takie umowy są jak gra w ruletkę - nieprzewidywalne dla obu stron, choć wiadomo, że ktoś wygra, a ktoś przegra. Jeśli ktoś proponuje takie zapisy, to jest po prostu niepoważny i należy - poważnie - zastanowić się, czy jest to dobry partner na długie lata wdrożenia i utrzymania systemu. Bo jeżeli dostawca miałby rzeczywiście "gwarantować" coś tak nieprzewidywalnego jak naprawę błędów w oprogramowaniu wielkości typowego systemu ERP, to koszt takiej usługi byłby horrendalny! W końcu za coś trzeba utrzymać tę armię konsultantów i programistów trzymanych w pogotowiu, infrastrukturę dla nich, no i z czegoś trzeba zapłacić te kary umowne! Rozsądek wymaga, by klient
  • zamiast grać w ruletkę - określił kilka krytycznych procesów i funkcjonalności, które muszą być obsługiwane prawie nieprzerwanie, a w stosunku do reszty przyjął założenie, że nakład sił i środków na ich utrzymanie nie może przekraczać korzyści z tego funkcjonowania. Oczywiście, wszyscy szefowie działów i kluczowi użytkownicy będą twierdzić, że pracujące dla nich oprogramowanie ma absolutnie kluczowe znaczenie dla całej firmy i nie da się wytrzymać bez niego ani minuty. Ktoś ważny po stronie klienta musi sobie (i im) uświadomić, że wszystko kosztuje, i ograniczyć te zapędy.

  • Pracownicy klienta dopiero po przeszkoleniu, a najlepiej w trakcie pracy na konkretnym systemie, dowiadują się, co system tak naprawdę może im zaoferować. Potrzeby i świadomość rosną w miarę wdrożenia (często już w fazie projektu wdrożeniowego) i w miarę korzystania z systemu. Dlatego najlepiej zrobić najpierw proste, skuteczne i szybkie wdrożenie. Poużywać, zmądrzeć, ograniczyć wodotryski i wtedy poprawić funkcjonowanie systemu - tam gdzie rzeczywiście warto. Na tym m.in. zasadza się sens dzielenia wdrożenia na części. W każdej kolejnej można skorzystać z zebranych wcześniej doświadczeń, dopracowując zakres i modyfikując nieco zasady współpracy z poznanym już dostawcą.

  • A co na to wszystko głodni bonusów sprzedawcy systemów ERP? Ci, z którymi warto współpracować, wolą zrobić trzy - mniejsze, dobrze zdefiniowane, zakończone sukcesem i akceptowalną marżą - projekty niż jeden wielki, rozlazły, potencjalnie szalenie lukratywny, ale w końcu deficytowy "deal roku". Przecież trudno liczyć, że kiedyś jakiś sprawny system informatyczny naliczy nam rzetelne emerytury - trzeba na nie odkładać już dziś gdzie indziej...

  • Jan Sianny jest dyrektorem sprzedaży w jednej ze znanych firm wdrażających systemy ERP.


    TOP 200