Typowy przetarg, czyli jak zmarnować kasę

22 kwietnia 2013

FreeDigitalPhotos.net-Businessman With Money by Ambro-ID-10040833Ogłoszenie przetargu  to bardzo powszechny sposób pozyskiwania oprogramowania. Co takiego jest w nim korzystnego dla zamawiającego? Nie wiem. Ktoś potrafi powiedzieć?

Typowe przetargi

Pod pojęciem “typowy przetarg” rozumiem rozesłanie lub upublicznienie opisu przedmiotu zamówienia, które, jak ufa zamawiający, rozwiąże jego biznesowy problem. Ile zazwyczaj ma taki dokument? Od kilkunastu do kilkudziesięciu stron? Co wchodzi w jego skład? Spora część poświęcona jest opisowi firmy zamawiającego (czasem z perspektywy rzeczywiście przydatnej, czasem nie), oczekiwaniom wobec dostawcy i samego przebiegu postępowania. Ile zostaje na opis tego, co należy właściwie wykonać? Niewiele. Wylewność (długość tego opisu) to jedno, jego jakość to drugie. Jeśli ocenimy tę jakość w kontekście jednoznaczności, kompletności i zrozumiałości dla wykonawców, bywa kiepsko.

Jakość opisu wymagań w RFP pozwala puszczać wodze wyobraźni

Jak długo żyję, nie widziałam dobrze przygotowanego zapytania ofertowego (RFP – Request For Proposal). Być może pech prześladuje mnie ze szczególną zawziętością, albo po prostu mają one często niską jakość. Zazwyczaj wygląda to tak, jakby pisała to osoba pewnie znająca swoją firmę i jej potrzeby, ale jednak nie sposoby komunikowania wymagań w IT, a nawet jeśli jakieś, to niezbyt wielkie. W efekcie nie jest dokładnie wiadomo, co należy wykonać. Jeśli ktoś pokusi się o stwierdzenie, że wie, opiera się to na ogromie założeń, o których nie wiadomo w danym momencie czy są słuszne, czy nie. Taki dokument może być jakąś zajawką na rozpoczęcie tematu, ale jeśli chcemy mieć porządny materiał wejściowy do projektu, musimy i tak to RFP zaorać i przygotować coś samemu.

Organizacja przetargów nie wspiera zrozumienia, co jest do zrobienia

Sama organizacja przetargów również nie sprzyja zrozumieniu, co właściwie trzeba dostarczyć. Czas składania oferty bywa krótki. Co prawda wychodzi się na przeciw problemowi niepełnego zrozumienia RFP umożliwiając zadawanie pytań. Jasne, to lepsze niż nic, może rozwiać kilka wątpliwości. Wyobraźmy sobie jednak jak wygląda zwyczajna rozmowa, kiedy chcemy się dobrze porozumieć. Im bardziej bezpośrednia, tym lepiej. Niektórych rzeczy nie załatwia się mailem, a osobiście, żeby uniknąć nieporozumienia. Jest też taka własność komunikatów międzyludzkich, że bez potwierdzenia zrozumienia, nie mamy pewności, czy o to chodziło (znów pole do popisu własnej interpretacji). Udzielane pisemnie odpowiedzi rodzą kolejne pytania, na które już odpowiedzi nie ma. Moim zdaniem taka forma to stanowczo za mało, żeby dobrze zrozumieć dokładnie czym i jakim ma być przedmiot zamówienia.

Typowe odpowiedzi na typowe przetargi

Typowe odpowiedzi na typowe przetargi nie mogą zatem wyglądać inaczej niż tak, że wykonawca przyjmuje mnóstwo założeń apropos tego, co ma wykonać. Niepotwierdzonych założeń. Pod rzucanymi hasłami może się kryć wiele rzeczy różnych postaci i dopóki nie zostaną one uszczegółowione, pozostają ciemną, mroczną masą. Masę tę trzeba jakoś wycenić. Wycenia się więc ją jakoś, licząc na swoje strzeleckie zdolności. Czy analogia do podobnych projektów może pomóc? Być może. Pamiętajmy jednak, że projekt to z samej definicji przedsięwzięcie unikatowe, jak zatem je porównywać? Nawet, jeśli przedmiot zamówienia wydaje się podobny do wcześniej realizowanego, to mamy mnóstwo czynników, które sprawią, że i tak będzie to całkiem inny projekt – inny klient i jego potrzeby, inny zespół do współpracy, inne środowisko, itd.

Tychże konsekwencje

Widzę tutaj trzy możliwe scenariusze.

  • Wykonawca składający ofertę jest genialnym strzelcem lub ma świetną intuicję i faktycznie dobrze oszacował czas i koszty. Efekt: wszyscy zadowoleni.
  • Wykonawca przeczuwając, że poczynił wiele niepotwierdzonych założeń, narzuca dla bezpieczeństwa na wycenę jakiś procent adekwatny do ponoszonego ryzyka. Efekt: zamawiający przepłaca.
  • Wykonawca wie, że cena w przetargach odgrywa dużą rolę (nie daj Boże, decydującą), więc przyjmuje założenia szalenie optymistyczne albo po prostu rzuca niską cenę z sufitu. Efekt: wykonawca musi tę niską cenę jakoś zrównoważyć. Jeśli mamy określony zakres i termin wdrożenia (często jakieś oczekiwania są), to z trójkąta projektów (zakres, czas, jakość) zostaje tylko zejść z jakości 🙁

Tak czy inaczej – problem ma zawsze zamawiający

Powyższe pokazuje, że jakkolwiek nie potoczą się losy przetargu, traci na tym zamawiający – albo przepłaca albo za niską cenę dostaje coś, co może być nieużyteczne, pełne błędów, niebezpieczne lub kosztowne w utrzymaniu i rozwijaniu, bo niedostatecznie przemyślane.

Jak żyć w związku z tym?

Mam wrażenie, że przeprowadzanie solidnej analizy, która dałaby pewność, że wyceniamy wszyscy tę samą i właściwą rzecz, pozostaje niepopularna wśród zamawiających. Pisanie jej samemu rękami biznesu jest kiepskim pomysłem, przekazanie działowi IT, jeśli posiada głównie kompetencje programistyczne i administracyjne, to też nie to. Potrzebny Ci analityk. Taki nie tylko z nazwy, ale taki, który rzeczywiście posiada potrzebne umiejętności.
Pytanie na dobranoc: Jak możesz wycenić coś, kiedy jeszcze nie wiesz, co masz dokładnie do zrobienia?

Cześć, jestem Hania.

Jako strategiczny analityk biznesowy na pograniczu zarządzania i IT zapewniam, że projekty i działania w organizacji przynoszą wartość biznesową. Dostarczam kompetencji analitycznych managerom i zarządom z Polski, Niemiec i Szwajcarii przy tworzeniu strategii oraz wdrażaniu jej w kilkuset osobowej międzynarodowej organizacji.

Może zaciekawi Cię także:

www.analizait.pl by ProjectUP (C) 2020