Przetargi IT dla software house’u: co bym zrobił inaczej

Zastanawiasz się, czy mała lub średnia firma programistyczna ma sens startować w zamówieniach publicznych? Przetargi IT dla software house’u to osobny rodzaj sprzedaży: mniej rozmów, więcej dokumentów, sztywne terminy i zasady, których nie da się negocjować po złożeniu oferty. Przez ostatni rok przygotowywaliśmy w Web Systems oferty przetargowe regularnie. Poniżej opisuję swoją opinię o tym, co bym zrobił inaczej, gdybym zaczynał od nowa. Bez nazw zamawiających i bez wyników postępowań, bo nie o konkretne przetargi tu chodzi, tylko o sposób pracy.

Pytania do zamawiającego zadawaj wcześnie i konkretnie

Najbardziej niedoceniane narzędzie wykonawcy to wniosek o wyjaśnienie treści specyfikacji. Ustawa Prawo zamówień publicznych daje wykonawcy prawo do takich pytań, a odpowiedzi zamawiającego są publikowane dla wszystkich. To nie jest oznaka słabości, tylko normalna część procesu.

Dziś zadawałbym pytania od razu po pierwszej lekturze dokumentów, zwłaszcza o:

• niejasny zakres, na przykład liczbę integracji albo to, czy migracja danych jest w cenie,
• sposób odbioru i kryteria, po których zamawiający uzna system za gotowy,
• środowisko docelowe: kto zapewnia serwery, licencje i dostęp do systemów, z którymi trzeba się połączyć,
• wymagania, które się wykluczają albo nie pasują do opisanego budżetu.

Dobrze zadane pytanie bywa też sygnałem dla zamawiającego, że opis zamówienia wymaga poprawki. Pomaga przy tym umiejętność czytania specyfikacji, o której pisałem w tekście o tym, jak przygotować specyfikację wymagań systemu.

Referencje to waluta, zbieraj je od pierwszego dnia

W zamówieniach publicznych doświadczenie liczy się tak, jak da się je udokumentować. Warunki udziału zwykle wymagają wykazania zrealizowanych zamówień podobnego rodzaju, potwierdzonych referencjami albo innymi dokumentami od odbiorcy.

To, co bym zmienił: prosiłbym o referencje przy każdym odbiorze projektu, także komercyjnego, zanim kontakt z klientem się rozluźni. Odtwarzanie dokumentów po latach jest trudne, a czasem niemożliwe, bo osoba, która odbierała system, już nie pracuje u klienta. Referencja powinna opisywać zakres, charakter systemu i datę realizacji, bo to właśnie te elementy porównuje zamawiający.

Konsorcja i podwykonawcy: kiedy łączyć siły

Wspólne ubieganie się o zamówienie, czyli konsorcjum, pozwala startować tam, gdzie żadna z firm nie spełnia sama wszystkich warunków. Przy przetargach IT to częsty scenariusz: jedna firma ma doświadczenie w danej dziedzinie, druga w technologii albo w utrzymaniu.

Konsorcjum ma jednak koszty organizacyjne. Partnerzy odpowiadają za wykonanie zamówienia solidarnie, więc zanim podpiszesz umowę konsorcjum, ustal na piśmie podział zakresu, lidera, sposób rozliczeń i to, co się dzieje, gdy jeden partner nie dowiezie swojej części. Konsorcjum z firmą, z którą nigdy wcześniej nie pracowałeś, to ryzyko, które trudno wycenić w ofercie. Lepiej zacząć od mniejszego postępowania z partnerem, którego zna się z projektów komercyjnych, i dopiero po nim sięgać po większe zamówienia.

Plany postępowań jako źródło leadów

Zamawiający publiczni sporządzają i publikują plany postępowań na dany rok. Dla software house’u to źródło wiedzy o tym, czego instytucje będą szukać, zanim ogłoszenie trafi do biuletynu.

Gdybym zaczynał od nowa, przeglądałbym te plany regularnie i wybierał kilka postępowań, które pasują do naszych kompetencji i referencji. Daje to czas na przygotowanie konsorcjum, zebranie dokumentów i zrozumienie, czym zamawiający się zajmuje. Oferta przygotowana w ostatnim tygodniu przed terminem zwykle przegrywa z ofertą firmy, która wiedziała o postępowaniu wcześniej.

Co sprawdzić przed decyzją o starcie

Przetargi IT dla software house’u kryją wymagania, które przy pobieżnej lekturze łatwo przeoczyć. Przed decyzją przechodzę dziś przez krótką listę:

1. Dostępność cyfrowa. Systemy i serwisy podmiotów publicznych muszą spełniać wymagania z ustawy o dostępności cyfrowej, która odwołuje się do standardu WCAG. To praca projektowa i testowa, którą trzeba ująć w cenie od początku. Podobne wymagania dotykają też biznesu, o czym pisałem przy akcie o dostępności dla sklepów.
2. Terminy. Czy termin realizacji jest realny przy uwzględnieniu analizy, testów i odbioru, a nie tylko programowania.
3. Kary umowne. Za co są naliczane, czy mają limit i czy zależą od czynników, na które wykonawca nie ma wpływu, na przykład od opóźnień po stronie zamawiającego.
4. Prawa autorskie. Jakie pola eksploatacji i czy zamawiający oczekuje przekazania kodu źródłowego, w tym bibliotek, które są własnością wykonawcy.
5. Gwarancja i utrzymanie. Jak długo, z jakim czasem reakcji i czy jest wyceniane osobno.

Kiedy odpuścić przetargi IT dla software house’u

Najtrudniejsza lekcja tego roku: nie każdy przetarg, do którego da się złożyć ofertę, jest wart złożenia oferty. Przygotowanie dokumentów zajmuje dużo czasu zespołu, a ten czas nie wraca, jeśli oferta przegra. Dlatego decyzję o starcie podejmowałbym tak samo jak decyzję o każdym innym projekcie: z oceną szans, kosztu przygotowania i tego, czy wygrana w ogóle się opłaca przy opisanych warunkach.

Odpuściłbym od razu, gdy kryterium ceny przeważa, a zakres jest opisany na tyle ogólnie, że każdy wykonawca wyceni inny system. Odpuściłbym też, gdy kary umowne są nieograniczone, termin nie zostawia miejsca na testy, a pytania o kluczowe niejasności pozostają bez odpowiedzi. W takich warunkach wygrywa oferta, która najmocniej niedoszacowała ryzyko, o czym pisałem przy porównaniu modeli fixed price i time and materials.

Jeśli rozważasz przetargi IT dla software house’u, zacznij od uporządkowania referencji i przeglądu planów postępowań w swojej specjalizacji, zanim weźmiesz się za pierwszą ofertę. Jeśli szukasz partnera do konsorcjum albo chcesz porozmawiać o wspólnym starcie, sprawdź zasady współpracy z Web Systems.