niedziela, 29 listopada 2009

Administracja Publiczna – niepowodzenia cz. III (Komunikacja wewnętrzna)

Zła komunikacja wewnętrzna (zbyt zbiurokratyzowana) w jednostkach Administracji Publicznej jako pochodna nieprzygotowania się Zamawiającego do przeprowadzenia projektu, jest kolejnym powodem dlaczego duża część projektów kończy się niepowodzeniem lub opóźnieniem. Projekt wdrożeniowy można porównać do jednorazowego procesu biznesowego, które celem jest zoptymalizowanie działania organizacji w pewnych określonych obszarach. Kierownik Projektu po stronie Zamawiającego zostaje wtedy właścicielem takiego procesu tzn. sprawuje nad nim nadzór i przejmuje odpowiedzialność za niego. Niestety, ktoś inny najczęściej definiuje mu cel, klientów i produkty tego procesu. Co gorsza jego pozycja w organizacji stawia go gdzieś na poziomie menedżera funkcjonalnego tzn. jest odpowiedzialny za określoną swoją grupę zasobów ludzkich, które w projekcie należy wykorzystać, lecz nie ma wpływu decyzyjnego na pozostałe jednostki. I nie ma tutaj znaczenia, że w Komitecie Sterującym zasiada grupa ludzi reprezentująca pełne spectrum interesów dostawcy, czyli z jednostek które mu są potrzebne. Bo żaden Kierownik Projektu nie będzie przecież w nieskończoność angażował KS.

Stara się więc sam zdobywać odpowiednie zasoby nie pochodzące z jego jednostki. Ma szczęście, jeżeli osoba zarządzająca inną jednostką oddeleguje pod jego kontrolę odpowiednie osoby, ale przecież w Administracji Publicznej oznaczałoby to pozbycie się władzy nad tymi ludźmi, dlatego rzadko kiedy tak się dzieje. Z reguły wprowadza się wewnętrzną komunikację na poziomie kierowniczym w formie pisemnej – a to już podlega pod wewnętrzną procedurę akceptacji wydanych decyzji, co z reguły trwa i trwa. Skutkiem jest oczekiwanie Wykonawcy na podjęcie prostej decyzji, którą jednak samodzielnie Kierownik Projektu nie może (nie ma prawa) podjąć. I wszyscy czekają, aż ktoś inny podejmie decyzję. Nierzadko się zdarza, że osoba ta nic nie wie o prowadzonym w organizacji projekcie i nie dość, że wymaga nagle dodatkowych informacji to jeszcze musi się potem z nimi zapoznać.

A wystarczyłoby zanim się rozpocznie procedurę przetargową spotkać się, przedyskutować cele biznesowe projektu, podzielić odpowiedzialności, zaplanować przekazanie kompetentnych zasobów ludzkich pod nadzór Kierownika Projektu, ocenić ryzyko i zidentyfikować obostrzenia jakie występują w organizacji. Czym to skutkuje ? Przekazaniem Wykonawcy odpowiednio wcześniej, bez żądania z jego strony, wszystkich niezbędnych dokumentów związanych z procedurami wewnętrznymi, wymaganiami bezpieczeństwa czy standardami, które mogą mieć wpływ na późniejsze opóźnienia – będące opóźnieniami po stronie Zamawiającego, lecz lekką ręką przerzucane na Wykonawcę.

Celowo użyłem porównania do procesów biznesowych, bo ostatnio w Administracji Publicznej zapanowała moda na budowanie systemów / aplikacji tylko i wyłącznie w oparciu o podejście procesowe. Często jest to przerost formy nad treścią … ale o tym następnym razem.

niedziela, 15 listopada 2009

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.

piątek, 13 listopada 2009

Administracja publiczna - niepowodzenia cz. I

Po lekturze artykułu zamieszczonego 13 października 2009 w ComputerWorld "Informatyzacja na tróję" zacząłem się zastanawiać nad faktycznymi przyczynami niepowodzeń wdrażania projektów informatycznych w Administracji Publicznej. Sam biorę udział w projektach dla instytucji państwowych i zauważam, że słowo informatyzacja jest różnie postrzegane i ma kilka różnych znaczeń.

Tylko co tak naprawdę rozumiemy poprzez informatyzację ?

Czy jest to zakup tylko i wyłącznie sprzętu teleinformatycznego czy też wdrożenie oprogramowania wspierającego procesy biznesowe realizowane w danych jednostkach ?

Odpowiedź na to pytanie wydaje się być odpowiedzią dlaczego tak kiepsko nam idzie. Podczas swojej pracy spotykam się z niezliczoną ilością przetargów, gdzie najważniejszym dokumentem jest Specyfikacja Istotnych Warunków Zamówienia (czyli SIWZ). To co jest tam napisane jest święte i wszyscy Wykonawcy muszą się do tego zastosować. Czyli dosłownie na tej podstawie opracować harmonogram i szacunkową wycenę swoich prac. Do SIWZ oczywiście można zadawać pytania zaczepne, ale z odpowiedzi najczęściej nic nie wynika. Dlaczego ?
Moim zdaniem dlatego, że:
  • W większości przypadków celem nie jest system informatyczny, tylko sama infrastruktura sprzętowa, ale przecież nie można ogłosić przetargu na wymianę serwerów lub oprogramowania systemowego, bo Zamawiający zaraz zostanie posądzony o niegospodarność i rozrzutność (po co im tyle sprzętu ?). Więc dopisuje się wymagania na system informatyczny. Nie ważne, że nie są spójne, ważne że są.
  • W pozostałych przypadkach Zamawiający nie przygotowuje się odpowiednio do wdrożenia jakiegokolwiek rozwiązania w swojej organizacji.
  • Jedyne do czego się dąży to stosowanie PRINCE2 lub ITIL - jakby to było panaceum na cale zło.
Rezultatem jest chaotycznie postępowanie, krótkie czasy realizacji oraz ciągle zmieniające się oczekiwania Zamawiającego wobec Wykonawcy.

Dlaczego nie można postępować w trochę inny, bardziej przemyślany sposób. Owszem, wymaga on więcej czasu, ale przynajmniej będzie skutkować zakupem i wdrożeniem rozwiązania najbardziej optymalnego dla danej organizacji, stabilnego i przemyślanego. Gdyby Zamawiający, zanim zacznie się starać o fundusze na zakup rozwiązania, zastanowił się nie nad tym czy jakikolwiek system informatyczny jest mu potrzebny, tylko co i w jaki sposób mógłby zmienić w swojej organizacji pracy, by procesy były realizowane sprawniej.

Jedną z przyczyn niepowodzenia informatyzacji jest kompletny brak dostosowania się pracowników do nowych warunków pracy. Zamawiający zwykle oczekuje, że system informatyczny zostanie dostosowany do jego obecnej organizacji pracy. I co uzyskuje ? Że zamiast przerzucać papiery przez 8 godzin dziennie, urzędnik będzie klikał po systemie przez 8 godzin, realizując taką samą ilość zadań. Czyli zamiast być sprawniej, będzie dalej tak samo, a w większości przypadków nawet wolniej.

A gdyby tak Zamawiający najpierw zastanowił się nie nad tym czy jakakolwiek informatyzacja jest mu potrzebna, tylko co i w jaki sposób mógłby zmienić w swojej organizacji pracy, by procesy były realizowane sprawniej, by procedury nie blokowały i nie opóźniały jego bieżącej działalności. Po takiej analizie biznesowej pojawiłyby się pomysły na zmianę procedur pracy, a więc również definicji procesów biznesowych (w niektórych przypadkach te definicji pojawiłyby się po raz pierwszy). Dopiero potem zespół złożony ze specjalistów technologicznych mógłby się zastanowić jakie rozwiązania teleinformatyczne są potrzebne by spełnić wymagania biznesu. Czasami wystarczyłby zwykły Excel. A czasami skomplikowane rozwiązanie informatyczne wymagające miesięcy pracy programistów. Czegoś jednak w tym podejściu brakuje. Czego ? Mianowicie dopasowania nowej wizji działania do realiów pracy codziennej. Co z tego, że wymyślimy nowe definicje procesów biznesowych, dopasujemy rozwiązania informatyczne, skoro nie przekonamy lub nie damy radę przeszkolić Głównego Użytkownika do korzystania z nich. To jest jeden z głównych powodów niepowodzeń, który praktycznie nigdy nie jest brany pod uwagę przy analizie problemów (szczególnie przez prasę, która zwykle zwala winę na Wykonawcę). Warto więc zadać sobie trud i porozmawiać z pracownikami o nowej wizji, nowych możliwościach, szkoleniach, zagrożeniach. Bo może się okazać, że aby móc przyśpieszyć, by móc sprawniej działać należy wymienić przede wszystkim ….. załogę. A przynajmniej ją przeorganizować w taki sposób, by osoby ze zdolnością korzystania z aplikacji informatycznych były na pierwszej linii frontu, natomiast te które sobie nie radzą z komputerem, lecz mają wiedzę merytoryczną z biznesu służyły im radą i pomocą.


Mam nadzieję, że uda mi się zainteresować osoby na co dzień zajmujące się projektami informatycznymi po stronie Zamawiającego i Wykonawcy do rozpoczęcia dyskusji na temat zmian jakie pozwoliłyby rozpocząć bardziej świadomą informatyzację naszego państwa. A może ja się mylę ?