RFP na tworzenie oprogramowania: lista kontrolna

RFP na tworzenie oprogramowania powinno przed odpowiedziami dostawców opisywać problem, wymagania funkcjonalne i pozafunkcjonalne, potrzeby bezpieczeństwa i danych, warunki handlowe oraz metodę punktacji. Oceniaj kryteria według ustalonych wag, weryfikuj referencje zamiast polegać na studiach przypadku i przeprowadź krótki płatny pilotaż, zanim podpiszesz zobowiązanie budżetowe.

Co powinno zawierać RFP na tworzenie oprogramowania?

Dokument ma umożliwić porównanie odpowiedzi. Dostawca może odpowiedzieć tylko na to, co zapisano; RFP opisujące samą wizję i proszące o cenę zachęca do ofert, które wszystkie brzmią dobrze, ale których nie da się zestawić. Zakres funkcjonalny, ograniczenia i zasady oceny trzeba ustalić przed pierwszą odpowiedzią. Inaczej sama ocena zamienia się w negocjowanie kryteriów.

Ważna jest też kolejność prac, która może oszczędzić miesiące: RFP nie służy do odkrywania, czego potrzebuje firma. Wymagania powinny wynikać z wewnętrznej analizy. Właściciele procesów opisują rzeczywistą pracę, finanse określają zasady uzgadniania, a przyszli użytkownicy wskazują codzienne problemy. To czasochłonna i czasem polityczna praca, którą należy wykonać przed zaangażowaniem dostawcy. Zespoły zlecające ją pierwszemu oferentowi mogą dostać wymagania zapisane językiem jego produktu. Wtedy pozostałe oferty wyglądają na niedopasowane nie dlatego, że takie są, lecz dlatego, że punkt odniesienia opracowano wokół jednego z uczestników.

Warto rozróżniać 3 dokumenty, które bywają mylone. RFI pyta rynek, jakie rozwiązania istnieją; jest krótkie, poprzedza wymagania i do niczego nie zobowiązuje. RFP prosi o ofertę odpowiadającą zdefiniowanym wymaganiom i opisanej metodzie oceny. RFQ pyta o cenę dla określonego zakresu. Wysłanie RFQ przed zdefiniowaniem zakresu to częsty sposób na porównanie 3 cen oznaczających 3 różne założenia.

Kompletne RFP robi 5 rzeczy, których brakuje dokumentowi niekompletnemu:

• Opisuje problem, nie gotowe rozwiązanie. „Skrócić przygotowanie miesięcznego raportu skonsolidowanego z dni do ustalonej liczby godzin” opisuje problem. „Zbudować hurtownię danych” jest założeniem o rozwiązaniu, które może go nie rozwiązać.


• Oddziela wymagania od preferencji. Wymagania konieczne przesądzają o przejściu oceny, pożądane wpływają na pozycję w rankingu, a dodatkowe nie powinny niczego rozstrzygać. Dostawcy odpowiadają poważniej, gdy rozróżnienie jest widoczne.


• Nazywa ograniczenia. Istniejące systemy do integracji, dane do migracji, obowiązki audytowe i retencyjne, termin uruchomienia oraz osoby zatwierdzające.


• Podaje metodę oceny z wyprzedzeniem. Kryteria i ich wagi, osoby oceniające, wymagane dowody oraz termin przekazania niezakwalifikowanym oferentom podsumowania punktów.


• Ustala daty procesu. Termin pytań, okres wyjaśnień, termin złożenia, czas oceny i data decyzji. Proces bez terminów przyciąga dostawców, którzy i tak są zajęci.

Struktura RFP

Wymagania funkcjonalne i pozafunkcjonalne

Wymagania funkcjonalne opisują, co system robi: jakie procesy obsługuje, dla których ról i z jakimi wynikami. Wymagania pozafunkcjonalne określają, jak dobrze działa. To one najczęściej są pomijane, a później egzekwowane dużym kosztem albo wcale.

W projektach B2B warto wyraźnie opisać:

• Wydajność. Czasy odpowiedzi dla określonego obciążenia i działań istotnych dla firmy, takich jak wprowadzanie zamówień, generowanie raportów i zamknięcie miesiąca.


• Dostępność. Wymagany czas działania, okna serwisowe i zachowanie podczas awarii. Cel procentowy bez określenia dopuszczalnego przestoju nie jest kompletnym wymaganiem.


• Odtwarzanie. RTO i RPO zapisane zrozumiałym językiem: jak szybko po incydencie mają wrócić operacje i ile pracy można stracić. Obie wartości należy uwzględnić w ocenie, nie dopiero w umowie.


• Ślad audytowy. Kto co zmienił i kiedy, jak długo zapis jest przechowywany oraz kto może go odtworzyć — zwłaszcza gdy przepływają pieniądze, zapasy lub dane osobowe.


• Dostępność i użyteczność. Kto korzysta z systemu, na jakich urządzeniach i w jakich językach. Systemu, którego nie potrafi używać magazyn, nie można uznać za wdrożony bez względu na uzyskane punkty.


• Integracja i dane. Które systemy się łączą, w jakim kierunku płyną dane i kto jest właścicielem rekordu podstawowego dla każdej kategorii.

Pytania o bezpieczeństwo i zgodność

Zamiast pytania „tak czy nie” żądaj dowodów związanych z bezpieczeństwem. Warto uwzględnić:

• ISO/IEC 27001 — czy dostawca ma certyfikat i jaki zakres on obejmuje? Certyfikat dotyczący działu sprzedaży, lecz nie zespołów realizacyjnych, przekazuje konkretną informację o granicach certyfikacji.


• Bezpieczne tworzenie oprogramowania — na jakich etapach uwzględnia się bezpieczeństwo: projektowania, przeglądu kodu i testów; czy obsługa zależności oraz podatności jest rutynowa.


• OWASP Top 10 — czy dostawca stosuje tę listę podczas przeglądu elementów dostępnych przez internet; to konkretne i weryfikowalne pytanie.


• Kontrola dostępu — kto może korzystać ze środowisk i danych firmy, jak dostęp jest nadawany i odbierany oraz jakie istnieje logowanie.


• Obowiązki ochrony danych — KVKK i GDPR, gdy mają zastosowanie; kto jest administratorem, kto procesorem oraz co umowa powierzenia danych mówi o podwykonawcach i zgłaszaniu naruszeń.

Warunki handlowe i SLA

Poproś o cenę w strukturze umożliwiającej porównanie: co obejmuje, co jest rozliczane osobno i jak wycenia się zmiany. Jedna kwota bez przypisanego zakresu nie daje się porównać z inną kwotą bez zakresu. Typowe modele i pytania związane z każdym z nich opisuje strona o modelach kosztów i cen.

SLA wymaga równie precyzyjnych definicji jak wymagania. Procent dostępności ma znaczenie tylko z metodą pomiaru, wyjątkami i środkiem zaradczym. Czas odpowiedzi można ocenić tylko z definicjami ważności i godzinami pracy. Zamiast akceptować stronę procentów bez objaśnień, poproś dostawcę o zdefiniowanie pojęć zawartych w SLA.

Macierz oceny ofert na tworzenie oprogramowania

Poniższy szablon można skopiować. Wagi są przykładowe; dopasuj je do priorytetów i zachowaj sumę 100. Zanim ktokolwiek przyzna punkty, określ, co oznaczają oceny 1, 3 i 5. Nie rób tego dopiero po rozpoczęciu sporu.

Dwie praktyki zwiększają użyteczność macierzy. Po pierwsze, każdy oceniający punktuje samodzielnie przed wspólną rozmową, aby pierwsza stanowcza opinia nie narzuciła oceny całemu zespołowi. Po drugie, przy każdym wyniku zapisz jednozdaniowe uzasadnienie. Dostawcy łatwiej akceptują podsumowanie z przyczynami, a twój zespół może obronić decyzję także 6 miesięcy później.

Trzecia kwestia dotyczy składu komisji. Powinni w niej uczestniczyć ludzie, którzy będą żyć z rezultatem: właściciel procesu, osoba odpowiadająca za dane oraz ktoś od bezpieczeństwa lub finansów, jeśli takie funkcje są w firmie. Nie wystarczy sam dział zakupów. Oceny po cichu tracą jakość, gdy komisja punktuje to, co umie ocenić — układ oferty i sprawność sprzedawcy — a odkłada na później dopasowanie integracji do obecnych systemów. Jedna osoba techniczna, która może powiedzieć „to nie zadziała z naszym środowiskiem”, pozwala zaoszczędzić więcej niż rabat.

Wagi również wymagają namysłu, bo pokazują dostawcom priorytety firmy. Jeśli bezpieczeństwo waży 5%, a cena 30%, zauważą to oferenci zwracający uwagę na bezpieczeństwo, a twój zespół zauważy po podpisaniu umowy. Wagi ustalone w pośpiechu, tylko po to, by wypełnić tabelę, wszyscy poza salą odczytują jako rzeczywiste. Ustal je raz, razem z decydentami, a później zmieniaj wyłącznie w równie formalny sposób.

Weryfikacja referencji i pilotaż

Studium przypadku jest materiałem marketingowym; sprawdzona referencja jest dowodem. Skuteczna rozmowa jest krótka i dotyczy przebiegu projektu, a nie samego rezultatu: czy projekt zakończono, co zmieniło się w zakresie, kto faktycznie pracował, co klient zrobiłby inaczej i czy ponownie rozpocząłby projekt z tym dostawcą. Konkretne odpowiedzi w czasie przeszłym są dobrym sygnałem.

Poproś o kontakt z klientem projektu podobnego pod względem skali i złożoności, nie tylko z najbardziej dumnym zlecenia. Wdrożenie flagowe za dwa razy większy budżet niewiele mówi o zachowaniu zespołu przy twojej skali. Referencję sprawdź samodzielnie: kontakt przygotowany przez dostawcę do konkretnych pytań jest świadectwem marketingowym, nie niezależną referencją. Wartościowa rozmowa to taka, podczas której klient poznaje pytania dopiero na miejscu.

Krótki płatny pilotaż pozwala sprawdzić coś, czego nie pokaże żadna referencja: jak konkretny zespół współpracuje z twoimi ludźmi przy niepełnych wymaganiach. Zasady projektowania są takie jak dla każdego pilotażu: rzeczywista praca, pisemne kryteria odbioru, jedna zmiana w trakcie i wcześniej uzgodniona reguła decyzji. Strona outsourcingu IT omawia pilotaż szerzej.

Klauzule umowy do sprawdzenia

• Przeniesienie IP — prawa do kodu, dokumentacji i opracowań pochodnych przechodzą na ciebie od chwili ich powstania, a nie dopiero przy płatności końcowej.
• Własność danych — twoje dane pozostają twoje; prawa dostawcy ograniczają się do tego, co jest konieczne do realizacji usługi.
• Odbiór — co oznacza odbiór, kto go zatwierdza i jaka procedura obowiązuje, gdy rezultat nie spełnia kryteriów.
• Kontrola zmian — jak zgłasza się, wycenia i zatwierdza zmianę zakresu. Bez tej procedury każda zmiana może stać się sporem.
• Zakończenie i przekazanie — dostęp do kodu źródłowego, środowisk i dokumentacji oraz pomoc na koniec; ustal, jak przekazuje się wiedzę przy zmianie dostawcy.
• Escrow — jeśli ciągłość działalności zależy od komponentów utrzymywanych przez dostawcę, określ, co nastąpi, gdy nie będzie mógł kontynuować pracy.
• Odpowiedzialność — limity, wyłączenia i ryzyka nieobjęte ubezpieczeniem. Czytaj te zapisy z taką samą uwagą jak cenę.
• Rozwiązanie umowy — okresy wypowiedzenia, obowiązki po rozwiązaniu oraz procedura zwrotu lub usuwania danych.

Najczęściej zadawane pytania

Czy najpierw wysłać RFI czy RFP?

Wyślij RFI, gdy rynek albo problem nie są jasne i chcesz ustalić, jakie rozwiązania istnieją oraz ile kosztują. RFP wysyłaj po określeniu wymagań i metody oceny. Wcześniejsze RFP przenosi pracę nad wymaganiami do ofert dostawców, napisanych ich językiem i według ich priorytetów.

Ilu dostawców zaprosić?

Tylu, żeby móc uważnie przeczytać każdą ofertę i sprawdzić każdą referencję. Jakość oceny często spada przy większej liczbie niż kilka firm. Krótka lista utworzona na podstawie RFI, rozmowy wstępnej i jednej referencji z podobnego projektu jest zwykle użyteczniejsza od długiego zestawienia znanych marek.

Jak ustalać wagi?

Na podstawie własnych priorytetów, przed poznaniem ofert, wspólnie z osobami odpowiedzialnymi za rezultat. Częstym błędem są jednakowe wagi dla wszystkiego, co oznacza, że nic nie jest ważniejsze od reszty. Jeśli głównym kryterium jest cena lub ryzyko, macierz powinna to jasno pokazywać.

Czy punktować cenę?

Tak, jako jedno ważone kryterium i przy ustalonym zakresie, a nie jako całą ocenę. Cena bez zakresu nagradza dostawcę, który założył najmniejszy nakład pracy. Najpierw wyceń wymagania, potem porównuj całkowity koszt tego samego rozwiązania.

Jak oceniać odpowiedzi dotyczące bezpieczeństwa?

Na podstawie dowodów, nie tonu wypowiedzi. Można zastosować 3 poziomy: brak stanowiska — 1, opisane polityki — 3, zweryfikowany zakres certyfikatu, opis bezpiecznego tworzenia i przedstawione dowody — 5. Jeśli dostawca nie ma certyfikatu, poproś o pisemne informacje o równoważnych kontrolach. Uczciwa odpowiedź „nie” poparta udokumentowanymi zasadami jest lepsza od nieweryfikowalnej odpowiedzi „tak”.

Czy można zmienić wymagania po wysłaniu RFP?

Przed złożeniem ofert — tak, pod warunkiem że zmianę otrzymają wszyscy. Po ich złożeniu wprowadzaj wyjaśnienia formalnie i udostępniaj je wszystkim oferentom. Cicha zmiana dla jednego dostawcy niszczy porównywalność, na której opiera się cały proces. Po podpisaniu umowy służy do tego procedura kontroli zmian.

Źródła i standardy

• ISO — wydawca ISO/IEC 27001 dotyczącej zarządzania bezpieczeństwem informacji. Przed poleganiem na certyfikacie sprawdź aktualne wydanie normy i zakres certyfikacji.
• OWASP — organizacja publikująca wymienioną na stronie listę Top 10 zagrożeń dla aplikacji internetowych.
• Zasady macierzy punktacji odpowiadają praktyce stosowania opublikowanych szablonów RFP. Przedstawione wagi są przykładem do zmiany, nie rekomendacją. To poradnik zakupowy, nie porada prawna; WorldwideTradeX nie deklaruje posiadania certyfikatu ani przeprowadzenia audytu.

Powiązane strony

Tworzenie oprogramowania · Outsourcing IT z Turcji · Modele kosztów i cen · Audyt IT i doradztwo · Poproś o wycenę