Koszty, wycena i brief
Zapytanie ofertowe na oprogramowanie: wzór i format odpowiedzi
Część poradnika: Ile kosztuje aplikacja mobilna: jak rozłożyć wycenę na czynniki
Zapytanie ofertowe na oprogramowanie to dokument, który opisuje projekt i jednocześnie narzuca zasady gry: w jakim układzie wykonawcy mają odpowiedzieć, według jakich kryteriów ocenisz odpowiedzi i do kiedy je przyjmujesz. Najczęstszy powód złego wyboru nie leży w cenie, tylko w tym, że trzy oferty przychodzą w trzech różnych układach i nie da się ich zestawić wiersz w wiersz. Poniżej masz strukturę takiego dokumentu dla zwykłej firmy prywatnej, gotowy akapit o wymaganym formacie odpowiedzi i tabelę do porównania tego, co wróci.
Czym zapytanie ofertowe różni się od briefu
Brief opisuje projekt, a zapytanie ofertowe organizuje proces zbierania i porównywania ofert. Praktycznie rzecz biorąc, zapytanie składa się z dwóch części: opisowej, czyli briefu, oraz proceduralnej — kryteriów oceny, wymaganego formatu odpowiedzi, terminów i trybu zadawania pytań.
Część opisową rozkłada na sekcje i pokazuje na wypełnionym przykładzie osobny tekst o tym, jak napisać brief dla software house. Ten materiał dotyczy drugiej połowy dokumentu — tej, która przesądza, czy odpowiedzi da się w ogóle zestawić.
Rozgraniczenie ma praktyczny skutek: brief piszesz raz i używasz przez cały rok, a zapytanie ofertowe przygotowujesz pod konkretną turę — z datami, listą zapytanych firm i kryteriami obowiązującymi tylko w tej turze.
Z jakich sekcji składa się zapytanie ofertowe na oprogramowanie
Zapytanie dla firmy prywatnej ma dziesięć sekcji, z czego pierwsze sześć to część opisowa, a cztery ostatnie odpowiadają za porównywalność ofert.
- Kontekst i problem. Czym zajmuje się firma, co dziś nie działa i ile to kosztuje czasu albo pieniędzy.
- Zakres MUST/SHOULD. Funkcje obowiązkowe w pierwszym wydaniu, oddzielone od tych, które mogą poczekać.
- Jawna lista wyłączeń. Osobna sekcja „czego projekt nie obejmuje”. To najtańszy akapit dokumentu, bo zdejmuje z wyceny bufor na niepewność.
- Systemy do integracji. Nazwy i wersje, informacja, czy mają API, i kto po Twojej stronie ma do nich dostęp.
- Ograniczenia. Hosting, dane osobowe, wymogi branżowe, technologie już używane w firmie.
- Budżet i termin. Widełki oraz data z powodem, dla którego jest ważna: targi, koniec umowy z dostawcą, zmiana przepisów.
- Kryteria oceny ofert z wagami. Lista czynników z procentami, według których podejmiesz decyzję.
- Wymagany format odpowiedzi. Ponumerowana lista punktów, w których ma być przedstawiona oferta.
- Termin i sposób składania. Data z godziną, adres e-mail, format pliku.
- Osoba kontaktowa. Jedna osoba i termin, do którego przyjmujesz pytania.
Jeśli część opisowa dopiero powstaje, przez komplet pytań o cel, zakres i ramy projektu przeprowadza w sześciu krokach kreator briefu — odpowiedzi zostają w karcie przeglądarki i składają się na gotową wiadomość.
Wymagany format odpowiedzi: sekcja, której brakuje w większości zapytań
Wymagany format odpowiedzi to lista punktów, w których każdy wykonawca ma przedstawić ofertę — w tej samej kolejności i w tym samym rozbiciu. Bez niej dostajesz trzy dokumenty zbudowane wokół trzech różnych pomysłów na to, co jest ważne, i porównujesz nie ceny, tylko cudze założenia.
Mechanizm jest prosty. Wykonawca układa ofertę tak, żeby pokazać swoje mocne strony: jeden rozpisze proces i metodykę, drugi da jedną kwotę i trzy zdania, trzeci wyliczy technologie. Wszystkie trzy mogą dotyczyć tego samego projektu i wszystkie trzy będą wyglądać na nieporównywalne, bo każda przemilcza coś innego.
Format wymuś siedmioma punktami:
- Wycena w rozbiciu na pozycje — moduły albo obszary funkcjonalne, każdy z osobną kwotą i pracochłonnością.
- Przyjęte założenia — co wykonawca przyjął tam, gdzie zapytanie milczało, bo to właśnie tu powstają późniejsze spory.
- Lista „out of scope” — co nie mieści się w kwocie; ten punkt wymuś nawet wtedy, gdy sam wypisałeś wyłączenia.
- Harmonogram z kamieniami milowymi — etapy, daty względne od podpisania umowy i zależności po Twojej stronie.
- Skład zespołu — role, liczba osób, ich zaangażowanie i informacja, kto pisze kod: pracownicy, współpracownicy czy podwykonawcy.
- Model rozliczenia i warunki płatności — z uzasadnieniem wyboru oraz procedurą zmiany zakresu.
- Gwarancja, wsparcie i prawa do kodu — okres gwarancji, czas reakcji, zakres przekazywanej dokumentacji i zasady przeniesienia praw.
Do punktu pierwszego dopisz jedno pytanie kontrolne: czy w cenie mieszczą się zarządzanie projektem, testy, wsparcie po wdrożeniu i licencje narzędzi. Te cztery pozycje najczęściej wracają później jako koszt dodatkowy, bo w pierwszej wersji oferty po prostu nie było o nich mowy. Z czego jeszcze składa się taka kwota, rozbieramy w tekście o tym, ile kosztuje aplikacja mobilna.
„Prosimy o ofertę w poniższym układzie, z zachowaniem numeracji i kolejności punktów. Oferty w innym układzie odeślemy do uzupełnienia przed oceną. (1) Wycena w rozbiciu na moduły lub obszary funkcjonalne, z pracochłonnością i kwotą dla każdej pozycji osobno. (2) Założenia przyjęte przy wycenie tam, gdzie nasze zapytanie nie rozstrzyga. (3) Lista «out of scope» — elementy, które nie mieszczą się w podanej kwocie. (4) Harmonogram z kamieniami milowymi, w dniach roboczych od podpisania umowy, wraz ze wskazaniem, czego oczekujecie od nas i w jakich terminach. (5) Skład zespołu: role, liczba osób, zaangażowanie oraz informacja, czy kod powstaje w zespole własnym, czy u podwykonawców. (6) Proponowany model rozliczenia wraz z uzasadnieniem, warunkami płatności i procedurą zmiany zakresu. (7) Warunki gwarancji i wsparcia po wdrożeniu, zakres przekazywanej dokumentacji oraz zasady przeniesienia praw do kodu. Prosimy dodatkowo o jednoznaczną odpowiedź, czy w podanej kwocie mieszczą się zarządzanie projektem, testy, wsparcie po wdrożeniu i licencje narzędzi zewnętrznych.”
Zapowiedź odsyłania niekompletnych ofert do uzupełnienia nie jest groźbą, tylko informacją. Firma, która i tak nie zamierzała rozbić wyceny, odpadnie sama — i dobrze, bo to samo podejście zobaczysz później przy rozliczeniach.
Kryteria oceny ofert: wagi zamiast wrażenia
Kryteria oceny to lista czynników z wagami sumującymi się do 100%, podana w zapytaniu, a nie ustalana po otwarciu ofert. Ich sens jest podwójny: wykonawca wie, gdzie ma się starać, a Ty masz gotowe uzasadnienie decyzji wobec zarządu czy wspólników.
Przykładowy zestaw dla wdrożenia oprogramowania: dopasowanie proponowanego rozwiązania do celu biznesowego 35%, cena wraz z kompletnością wyceny 25%, doświadczenie w podobnych integracjach 20%, harmonogram i dostępność zespołu 10%, warunki gwarancji i utrzymania 10%. Wagi dobierz do tego, co w Twoim projekcie jest naprawdę ryzykowne — jeśli całe ryzyko siedzi w wymianie danych ze starym systemem, doświadczenie w integracjach waży więcej niż cena.
Osobno wypisz warunki, których niespełnienie eliminuje ofertę z tury — na przykład brak gotowości do przeniesienia praw majątkowych do kodu albo brak możliwości utrzymania danych na serwerach w Unii Europejskiej. Warunek eliminujący to nie kryterium punktowane, więc trzymaj te dwie listy osobno.
Jak zestawić oferty wiersz w wiersz
Oferty porównuje się w jednej tabeli, w której wiersze pochodzą z Twojego wymaganego formatu, a kolumny to poszczególni wykonawcy. Puste pole nie oznacza wtedy braku informacji, tylko konkretne pytanie do zadania przed decyzją.
| Wiersz zestawienia | Co dokładnie porównujesz | Co oznacza rozjazd między ofertami |
|---|---|---|
| Wycena w rozbiciu | Kwotę i pracochłonność przy każdym module osobno | Różnica na jednej pozycji zwykle znaczy, że firmy rozumieją tę funkcję inaczej |
| Przyjęte założenia | Ile założeń padło i czego dotyczą | Dużo założeń to sygnał, że Twoje zapytanie milczy w ważnym miejscu |
| Lista „out of scope” | Co wypadło z kwoty u każdego wykonawcy | Najtańsza oferta z najdłuższą listą wyłączeń nie jest najtańsza |
| Harmonogram | Liczbę etapów i zależności po Twojej stronie | Brak zależności po stronie zamawiającego oznacza, że ktoś ich jeszcze nie policzył |
| Skład zespołu | Role, zaangażowanie i to, kto fizycznie pisze kod | Zespół wyłącznie podwykonawczy zmienia sytuację przy prawach do kodu |
| Model rozliczenia | Sposób rozliczenia i procedurę zmiany zakresu | Kwota ryczałtowa bez procedury zmian to przyszłe aneksy |
| Gwarancja i wsparcie | Okres, czas reakcji i to, co obejmuje | Gwarancja bez czasu reakcji nie jest zobowiązaniem |
Do jednego z wierszy wróć jeszcze przed podpisaniem umowy: sposób rozliczenia. Czy w Twoim przypadku właściwy jest fixed price czy time and material, przesądza dojrzałość zakresu, a nie wielkość projektu — i to pytanie warto rozstrzygnąć, zanim porównasz kwoty pochodzące z dwóch różnych modeli.
Ostatni krok to rozmowa z dwiema najlepszymi firmami o rozbieżnościach z tabeli. Kryteria, po których poznasz wykonawcę zdolnego dowieźć projekt, opisuje osobny poradnik o tym, jak wybrać software house.
Ile ofert zebrać i jak prowadzić turę pytań
Trzy do pięciu ofert wystarczają, o ile wszystkie wracają w tym samym układzie. Poniżej trzech nie widać rozpiętości założeń, powyżej pięciu porównanie kosztuje więcej czasu, niż jest warte.
Turę pytań prowadź jednym kanałem: jedna osoba kontaktowa, termin na pytania kilka dni przed terminem składania ofert i zapowiedź, że odpowiedzi trafią do wszystkich zapytanych firm w tym samym brzmieniu. Bez tej zasady część wykonawców wycenia projekt na podstawie informacji, których pozostali nie dostali.
Termin składania podaj z godziną i formą, na przykład plik PDF na wskazany adres e-mail. Dopisz, ile czasu zajmie Ci decyzja — wykonawcy planują wtedy dostępność zespołu, a Ty nie tracisz najlepszej oferty przez dwa tygodnie ciszy.
Czego nie przenosić z wzorów przetargowych
Formularze publikowane przy zamówieniach publicznych i w Bazie Konkurencyjności powstają pod inny reżim prawny i nie są wzorem dla firmy prywatnej. Kopiowanie ich dodaje oświadczenia i załączniki, które nikogo nie chronią, a potrafią zniechęcić mniejsze zespoły do odpowiedzi. Firma prywatna wybiera wykonawcę swobodnie, więc jej dokument ma wymuszać porównywalność, a nie odtwarzać procedurę.
Dwie rzeczy przenieś do części proceduralnej niezależnie od tego, jak nieformalną turę prowadzisz. Pierwsza to poufność: umowę NDA zawiera się, zanim przekażesz informacje poufne — strukturę cen, listę klientów, dane osobowe, kod czy dokumentację wewnętrzną — najpóźniej przed spotkaniem discovery, na którym wykonawca zbiera szczegóły do oferty. Sam opis problemu i skali zwykle takich danych nie zawiera, więc pierwsze zapytanie nie musi czekać na podpisy.
Druga to prawa do kodu. Zapłata faktury nie przenosi autorskich praw majątkowych: potrzebna jest umowa, która zgodnie z art. 53 ustawy z 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych wymaga formy pisemnej pod rygorem nieważności. W zapytaniu wystarczy zdanie, że oczekujesz przeniesienia praw wraz z wymienionymi polami eksploatacji oraz przekazania kodu źródłowego i dokumentacji; szczegóły klauzul rozkłada tekst o tym, komu przysługują prawa autorskie do kodu. Ten materiał ma charakter informacyjny i nie jest poradą prawną — brzmienie zapisów umownych uzgodnij z prawnikiem.
Checklista
Rozdziel zapytanie na część opisową i proceduralną — bez tej drugiej dostaniesz oferty w trzech różnych układach.
Wpisz wymagany format odpowiedzi jako ponumerowaną listę punktów i zaznacz, że braki odsyłasz do uzupełnienia.
Zażądaj wyceny w rozbiciu na pozycje zamiast jednej kwoty za całość.
Wymuś listę „out of scope” i pytanie, czy w cenie są zarządzanie projektem, testy, wsparcie po wdrożeniu i licencje narzędzi.
Podaj kryteria oceny z wagami sumującymi się do 100% i trzymaj się ich przy wyborze.
Wyznacz jedną osobę kontaktową oraz termin na pytania i termin składania ofert, oba z datą i godziną.
Odpowiedzi na pytania rozsyłaj wszystkim zapytanym firmom w tym samym brzmieniu.
Zawrzyj NDA, zanim przekażesz informacje poufne — najpóźniej przed spotkaniem discovery.
Zestaw oferty w jednej tabeli wiersz w wiersz i sprawdź, kto policzył coś, czego pozostali nie ujęli.
Najczęstsze pytania
- Jak napisać zapytanie ofertowe na oprogramowanie dla firmy prywatnej
- Zapytanie składa się z dwóch części. Opisowa to brief: kontekst i problem, cel, zakres MUST/SHOULD, jawna lista wyłączeń, systemy do integracji z nazwami i wersjami, ograniczenia oraz budżet i termin. Proceduralna to reguły tury: kryteria oceny z wagami, wymagany format odpowiedzi, termin i sposób składania ofert, termin na pytania oraz jedna osoba kontaktowa. Firma prywatna nie podlega reżimowi zamówień publicznych, więc formularze przetargowe są tu zbędnym balastem — potrzebujesz dokumentu, który wymusza porównywalność, a nie formalnej procedury.
- Ile ofert zebrać przy zapytaniu na oprogramowanie
- W praktyce trzy do pięciu wystarczają, pod warunkiem że wszystkie odpowiadają w tym samym układzie. Przy mniej niż trzech nie widać rozpiętości założeń, a przy więcej niż pięciu porównanie zaczyna zjadać więcej czasu, niż jest warte — każdą ofertę trzeba przeczytać ze zrozumieniem, a nie tylko spojrzeć na kwotę. Ważniejsza od liczby jest jednorodność: trzy oferty w jednym, narzuconym przez Ciebie formacie porównasz w godzinę, a pięć w dowolnych układach nie da się porównać wcale, bo każda liczy co innego.
- Jak porównać oferty, skoro każda ma inny układ
- Jeśli oferty już przyszły w różnych układach, jedynym wyjściem jest przepisanie ich do wspólnej tabeli i odesłanie pytań uzupełniających do wszystkich firm naraz. Zestaw wiersze: zakres w rozbiciu na pozycje, przyjęte założenia, lista wyłączeń, harmonogram, skład zespołu, model rozliczenia, gwarancja i wsparcie, prawa do kodu. Puste pole w tabeli to nie brak informacji, tylko pytanie do wykonawcy. Na przyszłość problem znika, gdy w zapytaniu narzucisz wymagany format odpowiedzi.
- Czy wymagać NDA przed wysłaniem zapytania ofertowego
- Do pierwszego zapytania o dostępność i orientacyjny koszt NDA zwykle nie jest potrzebne, bo opis problemu i skali nie musi zawierać informacji poufnych. Umowę o zachowaniu poufności zawiera się, zanim przekażesz materiały wrażliwe: strukturę cen, listę klientów, dane osobowe, kod czy dokumentację wewnętrzną — najpóźniej przed spotkaniem discovery, na którym wykonawca zbiera szczegóły do oferty. Warunkowanie samego zapytania podpisem NDA wydłuża turę o kilka dni i bywa odczytywane jako sygnał, że opis projektu jest zbyt ogólny.
- Co powinno znaleźć się w kryteriach oceny ofert
- Kryteria to lista czynników z wagami sumującymi się do 100% i z opisem, co konkretnie sprawdzasz w każdym z nich. Typowy zestaw dla wdrożenia oprogramowania: dopasowanie proponowanego rozwiązania do celu biznesowego, cena wraz z kompletnością wyceny, doświadczenie w podobnych integracjach, harmonogram i dostępność zespołu oraz warunki gwarancji i utrzymania. Wagi podaj w zapytaniu, a nie dopiero po otwarciu ofert — wtedy wykonawcy wiedzą, gdzie się starać, a Ty masz gotowy sposób uzasadnienia wyboru wewnątrz firmy.
Źródła i metodologia
Linki prowadzą do źródeł pierwotnych oraz zasad, według których przygotowujemy i aktualizujemy materiały.