Do budżetu Zamawiającego można podchodzić na wiele sposobów, ale … tylko menedżer (Zamawiający) wie (powinien) jaki ma cel w swoim projekcie, „frazes” w rodzaju „cel powinien być znany i mierzalny” coś w sobie ma.

Niestety bardzo często budżet na wdrożenie IT jest ustalany jest metodą:

1. przekonajmy decydentów, że nasz produkt jest super (nie będę się rozpisywał o metodach przekonywania),
2. jak ich przekonamy to naszą wstępnie proponowana wartość (koszt projektu) systemu zaplanują w przyszłym roku,
3. skoro zaplanowali to i wydadzą (zrobimy wszystko by u wydali nas).

Ten proces to koszmar. Dlaczego? Bo nie ma nic wspólnego z planowaniem, to po prostu zupełne pogwałcenie zasad rachunku ekonomicznego, a co ciekawe, dają się na to namówić (że tego rachunku ekonomicznego się dla IT nie liczy) nawet osoby odpowiedzialne za finanse. No i czym jest sytuacja, gdy dostawca nam projektuje budżet na swoje produkty?

Nasz system jest najlepszy

Proces ten wygląda tak:

Dostawca „lobbuje”. Zapada decyzja, o tym jaki produkt zostanie wdrożony, potem ma miejsce zbieranie wymagań (robi to często dostawca, i analizą tego nie nazwę), kolejny etap to „walka” czyli dostosowywanie systemu ERP do potrzeb użytkownika (potocznie zwana kastomizacją). Jest to kosztowny, mało przewidywalny proces, który najczęściej dodatkowo odcina użytkownika od przyszłych uaktualnień ([[upgrade oprogramowania]]), gdyż te zniszczyły by te kastomizacje (tu upgrade równa się powtórzeniu całego wdrożenia). Jeżeli więc od razu cały ten proces wykona dostawca konkretnego produktu to w zasadzie nie mamy żadnej wiedzy na temat tego czy ów dostawca (nawet składający ofertę w dobrej wierze) ma optymalne dla nas rozwiązanie, bo może jest to coś najgorszego i co gorsza nigdy się tego nie dowiemy, bo nie mamy żadnego porównania.

Jaką mamy alternatywę?

Przede wszystkim, zakup produktu (oprogramowania ERP, CRM itp.) NA KOŃCU! Bo to minimalizuje ryzyko złego wyboru.  Zaczynamy od planowania.

Dobrą praktyką wprowadzania zmian w firmie i analizy czy to ma sens, jest opisanie swojego celu (wizja projektu) jako sytuacji idealnej, a potem dopiero tego, co można i jakim kosztem osiągnąć (na ile jesteśmy w stanie zbliżyć się do tego celu) – wykonać analizę wykonywalności własnego planu. Wtedy w ogóle wiemy czy mamy szansę na 90% realizacji planu (wizji) czy tylko na 20% … jeżeli „próg sensu” to np. 75% to wiemy że realizacja 78% jest dość ryzykowna (plan na styk) a 86% daje duże szanse na to, że projekt się uda.

Tak więc budżet projektu IT to progowy, sensowny koszt wprowadzenia zmiany w firmie na lepsze (zakładam, że nie jest celem sam fakt kupienia nowych zabawek). I ten koszt (maksymalny sensowny) powinien być firmie (jej zarządowi) znany, bo powinien zostać wyliczony (określony) jako [[RIO]] lub [[NPV]]. Oferty muszą się w nim zmieścić.

Zlecamy analizę, której produktem będzie specyfikacja wymagań biznesowych zawierająca wymagania funkcjonalne, poza-funkcjonalne oraz [[model dziedziny systemu]]. Mamy teraz kluczowe informacje o tym do czego gotowy system ma pasować. Takie zapytanie wysyłamy „w rynek”, wybieramy ofertę najlepiej pasującą do naszych wymagań.

Jeżeli zostały jakieś nie obsłużone wymagania to NIE ZGADZAMY SIĘ NA DOPASOWANIE. A co robimy? Pytamy ile kosztuje (drugie zapytanie, albo od razu taki warunek umieszczamy w pierwszym) wytworzenie brakujących funkcjonalności. Należy je zaprojektować, wykonać i zintegrować. Co ciekawe taką właśnie ścieżkę postępowania znajdziemy w dokumentach o wdzięcznej nazwie „metodyka wdrożenia polecana przez producenta systemu ERP” (komu z Państwa pokazano ten dokument???) .

Powinny do nas dotrzeć propozycje mówiące: „mamy produkt, który w X% pasuje do zapytania, brakujące rzeczy wykonamy za X zł w X czasie”. Mając te oferty podejmuje się decyzję.

Brakujące funkcjonalności

Dobre systemy, to systemy mające tak zwane niezależne środowisko uruchomieniowe (zwane zależnie od postaci serwerem aplikacyjnym lub frameworkiem). Nowe funkcjonalności należy zaprojektować i wytworzyć:

Jest to wygodne, bo wynik wykonanej już analizy, należy tylko uzupełnić o projekt brakującej w wybranym produkcie logiki biznesowej, przekazać dostawcy systemu lub wybrać firmę specjalizującą się w tworzeniu oprogramowania (niestety praktyka pokazuje bardzo często, że dobrzy konsultanci od kastomizacji ERP są bardzo złymi programistami). Tak powstały produkt integrujemy z zakupionym wcześniej systemem. Jest bardzo dobrze, jeśli nowe funkcje zostaną zaimplementowane w naturalnym dla naszego ERP środowisku (więcej pisałem o tym tu).

I po tym przydługim i oczywistym wstępie

– z perspektywy (uczciwego) dostawcy nie ma sensu składanie oferty cenowej, nie wiedząc w ogóle do czego i czy w ogóle jest nasz produkt potrzebny,

– z perspektywy nabywcy nie ma sensu „szukanie czegoś fajnego” z nadzieją, że coś w ogóle z tego wyjdzie, nawet jeśli „to coś fajnego” mają inni.

Moim zdaniem budżet zamawiającego to wiedza zamawiającego, której nie musi ujawniać. Skoro już jej nie ujawnia to powinien mieć kompetencje (własne lub wynajęte) pozwalające po pierwsze opisać projekt, po drugie zdefiniować (opisać) „to coś informatycznego” co pomoże mu ten projekt zrealizować.

Wyjawienie przez Zamawiającego planów i budżetu dostawcy, to postawienie się pod ścianę w negocjacjach z nim, to jak wejść do sklepu z AGD i powiedzieć głośno: mam 5 tys. na telewizor, co proponujecie? Dlatego nie ma sensu dopuszczenie do sytuacji gdy dostawca pyta Zamawiającego o jego budżet. I nie ma tu znaczenia uczciwość tego dostawcy bo z perspektywy klienta sprzedawca na prowizji stanowi duże ryzyko dla rzetelności takiej oferty.

I na koniec:

napisanie tylko „system ma wystawiać faktury VAT” jako opis tego co chcemy kupić, nie ma żadnego sensu bo to stanowczo za mało by cokolwiek wycenić i ocenić…. ale też napisanie, że „kontrahenta można dodać do faktury z rozwijanej listy uruchamianej prawym klawiszem myszy”, jest jeszcze większym błędem, bo po pierwsze nie raz narzuca wspomnianą kastomizację (a to podnosi koszt), a po drugie bywają lepsze sposoby rozwiązania tego problemu. Dla gotowego systemu nie ma sensu pisanie aż takich szczegółów, a dla dedykowanego robi się to zupełnie inaczej.