Administracja publiczna - niepowodzenia cz. II

Kontynuując wątek ...

Zmiana podejścia Zamawiającego do informatyzacji powinna dotyczyć również sposobu gromadzenia informacji o produktach i rozwiązaniach. Tutaj pojawia się druga główna przyczyna niepowodzeń – różna interpretacja zapisów SIWZ przez obie strony i zrozumiała niechęć Wykonawcy do realizacji zadań wykraczających poza zaplanowany przez niego budżet. Dzisiaj przygotowując SIWZ Zamawiający w mniejszym lub większym stopniu opiera się na znalezionych przez siebie w Internecie lub podsuniętych mu informacjach o funkcjonalnościach poszczególnych produktów informatycznych. I najczęściej do SIWZ trafia mieszanka wszystkiego po trochu, bo jednemu czy drugiemu urzędnikowi spodobała się dana funkcjonalność – co wcale nie oznacza, że kiedykolwiek ktokolwiek będzie z niej korzystał. Często również zdarza się, że specyfikacje faworyzują jedno rozwiązanie, bo Zamawiającemu nie chciało się poszukać innych lub po prostu zabrał się za to zbyt późno i Unia zagroziła mu odebraniem pieniędzy. Więc nie może już czekać, musi ogłaszać przetarg. Rezultaty widać gołym okiem. Praktycznie większość przetargów jest oprotestowana, bo specyfikacje są albo niedokładne, albo zbyt dokładne. Protesty przeciągają postępowanie, a w przypadku funduszy unijnych termin ostateczny się nie przesuwa. Czyli czasu na realizację zadania jest coraz mniej. Poza tym na podstawie SIWZ, który zwykle niewiele mówi o rzeczywistych zamiarach Zamawiającego, oczekuje się od Wykonawcy oceny kosztów jakie poniesie, by wykonać zamówienie. Tyle, że często jednym z zadań wynikających z zamówienia jest „wykonanie analizy biznesowej”. Czyli wykonanie tej pracy, o której pisałem w poprzednim akapicie. Pracy, która może nas doprowadzić do wniosku, że nie warto nic wdrażać. Pracy, która może nas doprowadzić do wniosku, że konieczne jest stworzenie lub zakup rozwiązań za wielomilionowe kwoty. Pracy, którą powinien wykonać sam Zamawiający (możliwe, że przy wykorzystaniu kompetentnej firmy). A przecież wcześniej wymuszono na Wykonawcy podanie ceny ofertowej … Po wybraniu Wykonawcy do realizacji zadania okazuje się, że wyobrażenia Zamawiającego są zupełnie inne niż Wykonawcy, który na tej podstawie budował wycenę. Nie zapominajmy, że są to zamówienia publiczne, gdzie nie można rozmawiać z Zamawiającym przed złożeniem oferty, a odpowiedzi na zadawane pytanie do SIWZ zwykle niczego nie wnoszą.
Na tym etapie pojawiają się więc liczne opóźnienia, które prasa szczególnie chętnie prezentuje jako niesolidne działanie Wykonawcy. A przyczyna tkwi głównie w Zamawiającym, który nie jest przygotowany do wdrożenia, nie do końca sam wie czego chce, wielokrotnie zmienia swoje oczekiwania, przy czym jedyne czego nie zmienia to czas wykonania zamówienia.

A gdyby tak Zamawiający zamiast oczekiwać, że Wykonawca zawsze i chętnie dostosuje swoje rozwiązania do ciągle zmieniających się oczekiwań biznesowych, poprosił Wykonawców o zaprezentowanie mu swoich gotowych rozwiązań (pomysłów) wspierających założoną przez niego wizję biznesową – tak jak to się dzieje w przypadku korporacji prywatnych. Można to rozumieć jako chęć zakupu samochodu, którego parametry będą najbardziej pasować do stylu jazdy i warunków w jakich zamierzamy go użytkować. Pooglądamy, popytamy, zorientujemy się, następnie wybierzemy jeden model, który możemy potem poddać tuningowi. Tym niemniej co i w jaki sposób tuningować określimy samodzielnie, a dostawca tylko to wykona. Tymczasem w Administracji Publicznej dzisiaj wygląda to w taki sposób, że kupujący chciałby mieć Toyota Camry w cenie Dacia Logan, ale w elementami wyposażenia dostępnymi tylko w BMW. Tak się nie da. Nikt czegoś takiego nie zbuduje, a nawet jeżeli się zdecyduje, to któregoś kryterium nie spełni. Wracając do tematu, gdyby Zamawiający pozwolił Wykonawcom pokazać jak zamierzają realizować przy pomocy swoich rozwiązań jego biznes, to uzyskałby rozwiązanie właśnie najbardziej zbliżone do jego oczekiwań. Mógłby oczywiście porównać rozwiązania i pomysły, popytać o możliwość dopasowania pewnych funkcjonalności podpatrzonych u konkurencji. Na tym etapie nastąpiłoby wyjaśnienie wszystkich wątpliwości, czyli eliminacja różnych interpretacji, co w ostateczności przełożyłoby się na bardziej precyzyjny harmonogram, wycenę i kryteria odbioru. Wszelkiego rodzaju modyfikacje byłyby traktowane jako ów tuning, ale z jasno określonymi oczekiwaniami znanymi Wykonawcy jeszcze przed położeniem oferty cenowej. Może się wtedy okazać, że Wykonawca nie będzie chciał podejmować się licznych i skomplikowanych modyfikacji, bo prowadzi politykę produktową i nie zamierza specjalnie zmieniać swoich celów. Może się również okazać, że nie jest w stanie sprostać oczekiwaniom. Ostatecznie po wyjaśnieniu wszystkich wątpliwości Wykonawcy składaliby ofertę cenową na produkt bazowy, wycenialiby koszt RBH w przypadku modyfikacji, określaliby czas jaki potrzebują na wykonanie zmian i ustabilizowanie wersji oprogramowania. I wtedy byłoby wszystko jasne i klarowne. A gdyby jeszcze Zamawiający nauczył się kilku prostych metod wyceny pracochłonności tworzenia oprogramowania, by nie błądził … ale to już temat na inny post.