Oprogramowanie na zamówienie: przewodnik zakupowy 2026 w 7 krokach
Oprogramowanie na zamówienie (custom software procurement) to proces zlecania dedykowanego oprogramowania zewnętrznemu dostawcy: uzasadnienie biznesowe, zakres prac, RFP, ocena dostawców, umowa i test odbiorczy, który ją zamyka. To nie jest produkt. To proces zakupowy, który przeprowadzasz.
Wpisz to w Google, a dostaniesz dziewięć katalogów narzędzi i jedną 900-wyrazową stronę polityki UCLA. Sam proces pozostaje nieopisany, bo treści piszą dostawcy narzędzi, którym zależy na pozycjach. Ten przewodnik odpowiada na to drugie pytanie: jak kupić oprogramowanie, które jeszcze nie istnieje?
Najważniejsze wnioski:
- Zamawianie oprogramowania na zamówienie to proces zlecania dedykowanego oprogramowania dostawcy, a nie kupowania narzędzia zakupowego.
- Pełny proces zakupowy obejmuje 7 kroków, od uzasadnienia biznesowego po odbiór końcowy, zwykle 10–16 tygodni przed rozpoczęciem prac.
- Budżet chroni dziewięć klauzul umownych; najtwardsze z nich to własność IP, kryteria odbioru i płatności etapowe.
Zamawianie oprogramowania to nie oprogramowanie zakupowe
Oprogramowanie zakupowe (procurement software) to narzędzie automatyzujące zakupy: zamówienia, akceptacje, fakturowanie, katalogi dostawców. Zamawianie oprogramowania na zamówienie to proces zlecania dedykowanego oprogramowania firmie developerskiej. Pierwsze to produkt, który licencjonujesz. Drugie to projekt, który prowadzisz, z umową i testem odbiorczym. Ten przewodnik dotyczy tego drugiego.
To pomieszanie jest zrozumiałe: rynek narzędzi jest ogromny i dobrze opisany. Katalog dostawców Art of Procurement wymienia ponad 200 platform w 19 kategoriach, a przewodnik zakupowy Brex na 2026 rok liczy prawie 4000 słów porównujących pięć z nich. Nikt w tym stosie nie wyjaśnia, jak zlecić oprogramowanie od zera. Tę lukę wypełnia ten wpis.
Zanim zaczniesz: czy custom to na pewno właściwy zakup?
Custom jest właściwym zakupem, gdy oprogramowanie stanowi rdzeń Twojego sposobu działania i żaden gotowy produkt nie obsługuje procesu bez prowizorki. Jest złym zakupem, gdy licencjonowany produkt pokrywa już 80% potrzeb. Zdecyduj uczciwie, zanim wydasz złotówkę na RFP na oprogramowanie na zamówienie.
| Opcja | Wygrywa, gdy | Uważaj na |
|---|---|---|
| Gotowy SaaS | Potrzeba jest standardowa (płace, CRM, fakturowanie) i 80% pokrycia wystarczy | Opłaty za użytkownika się kumulują; wynajmujesz, nigdy nie posiadasz |
| Customizacja platformy | Platforma w dużej mierze pasuje, a Twój przypadek brzegowy to konfiguracja, nie przebudowa | Dług customizacji; aktualizacje psują Twoje modyfikacje |
| Pełny custom build | Oprogramowanie jest Twoim procesem, konkurenci go nie kupią, a Ty potrzebujesz IP | Ponosisz ryzyko realizacji, więc umowa musi je alokować |
Nadal nie wiesz, w którym wierszu jesteś? Nasz framework oceny build-vs-buy odpowiada na pytanie „budować czy kupić"; ten przewodnik odpowiada na kolejne: jak przeprowadzić zakup, gdy już zdecydujesz.
Potem spisz uzasadnienie biznesowe. Wystarczy jednostronicowy szablon zakupu oprogramowania:
Problem: What is broken, in one sentence
Current cost: What it costs today (hours per week x rate, or lost revenue)
Outcome: The measurable result the software must produce
Ceiling: The maximum budget, and the date the money runs outNawet zakupy w dwie osoby zyskują na spisanej polityce zakupowej: jeden akapit o tym, kto akceptuje wydatki i kto podpisuje. To zapobiega chaosowi „founder klepnął na callu", który topi odbiory.
7-etapowy proces zakupu oprogramowania na zamówienie
Proces zakupu oprogramowania na zamówienie ma siedem etapów, z czego sześć dzieje się, zanim ktokolwiek napisze linijkę kodu. Całość, po jednym zdaniu:
- Potrzeba i uzasadnienie biznesowe: udowodnij, że problem jest wart pieniędzy
- Zakres prac (SOW): zapisz dokładnie, co znaczy „zrobione"
- Skanowanie rynku: zrób shortlistę dostawców, którzy robią ten rodzaj prac
- RFP / RFQ: wyślij wszystkim ten sam brief
- Ocena dostawców: punktuj odpowiedzi na podstawie dowodów, nie wrażeń
- Negocjacje i umowa: wpisz dziewięć klauzul na papier
- Dostawa i odbiór: przetestuj wobec kryteriów z kroku 2
Te widełki to nasza interpretacja typowych projektów SME, a nie mierzalny benchmark: przedłużenie umowy z jednym dostawcą trwa trzy tygodnie, regulowany przetarg trwa sześć miesięcy.
| Etap | Typowe tygodnie | Powstający artefakt | Właściciel |
|---|---|---|---|
| 1. Potrzeba i uzasadnienie | 1–2 | Jednostronicowe uzasadnienie | Ty (kupujący) |
| 2. Zakres prac | 2–4 | SOW plus kryteria odbioru | Ty, z wkładem dostawcy |
| 3. Skanowanie rynku | 1–2 | Shortlista 5–8 dostawców | Ty |
| 4. RFP / RFQ | 2–3 | Wysłany brief i odpowiedzi | Ty, potem dostawcy |
| 5. Ocena dostawców | 1–2 | Wypunktowana karta oceny | Ty |
| 6. Negocjacje i umowa | 2–3 | Podpisana umowa | Obie strony plus prawnicy |
| 7. Dostawa i odbiór | trwa przez cały build | Protokół odbioru | Obie strony |
| Suma przed buildem | 10–16 | Podpisana umowa i testowalny SOW | Ty |
1. Potrzeba i uzasadnienie biznesowe
Zacznij od jednostronicowego dokumentu powyżej. W naszych projektach te, które go pomijają, zmieniają zakres w trakcie prac, gdy zmiany kosztują prawdziwe pieniądze zamiast jednego akapitu. Dokument ustala też sufit budżetu, który podajesz w RFP.
2. Zakres prac (SOW)
Statement of work zamienia uzasadnienie biznesowe w specyfikację, o którą obie strony mogą się spierać: funkcje w zakresie i poza nim, integracje, harmonogram i kryteria odbioru, wobec których testowana jest dostawa. Jak określić zakres projektu web app zwraca się właśnie tutaj, albo określ zakres wymagań z AI, żeby szybciej mieć szkic.
3. Skanowanie rynku
Zbuduj shortlistę pięciu do ośmiu dostawców ze świeżymi referencjami z właściwej domeny. Pytaj znajomych z branży, którzy dowieźli podobne prace; sprawdzaj case studies ze swojej branży, nie strony główne. Omijaj katalogi rankingowane prowizją za polecenie.
4. RFP / RFQ
Wyślij każdemu dostawcy z shortlisty ten sam brief i wymagaj tego samego formatu odpowiedzi. RFP (request for proposal) pyta, jak by to zbudowali; RFQ (request for quotation) pyta, ile kosztuje zdefiniowany zakres. Przy zamawianiu oprogramowania na wymiar najpierw wysyłasz RFP.
5. Ocena dostawców
Punktuj każdą odpowiedź tą samą kartą oceny, ważąc referencje i prawa do audytu kodu wyżej niż cenę. Najtańsza propozycja to zwykle ta, która wyceniła najmniej pracy. Sam zadzwoń do referencji.
6. Negocjacje i umowa
Weź zwycięską propozycję i dołącz do niej dziewięć klauzul poniżej. Negocjuj najpierw kryteria odbioru i płatności etapowe, cenę na końcu: cenę najłatwiej przesunąć, odbiór jest tym, o co warto walczyć.
7. Dostawa i odbiór
Dostawa to nie „przysłali kod". Odbiór oznacza, że oprogramowanie spełnia kryteria z SOW w Twoim środowisku, z podpisanym przeniesieniem IP i przekazanym kodem źródłowym. Wstrzymaj ostatnią płatność etapową, aż ten test przejdzie.
RFP, które daje prawdziwe wyceny
RFP bez kryteriów odbioru to wycena pracy, której nikt nie zdefiniował. Szkielet poniżej to szablon RFP na oprogramowanie na zamówienie, który chcielibyśmy dostawać od każdego kupującego. Skopiuj go, wypełnij luki, a pięciu dostawców wyceni jeden zakres, a nie pięć zgadywanek.
CUSTOM SOFTWARE RFP
1. Company context
Who you are, team size, the system this replaces or connects to
2. Problem statement
The broken process, what it costs you today, who feels it
3. Scope
In: the features and integrations the first release must ship
Out: anything you have decided to defer
4. Technical constraints
Stack preferences, hosting rules, compliance (GDPR, HIPAA), SSO
5. Timeline
Hard dates, and what happens if you miss them
6. Budget range
A ceiling, not a target. Vendors price to the number you give.
7. Acceptance criteria
The pass/fail tests the final delivery must clear before sign-off
8. Evaluation criteria
How you will score responses, and the weight of price vs. references
9. Response format
Page limits, the questions to answer, and the reply deadlineDołącz przede wszystkim trzy rzeczy: sufit budżetu, kryteria odbioru, format odpowiedzi. To one zamieniają mgliste pitchy w porównywalne wyceny.
Wytnij trzy rzeczy: przepisy na implementację („użyjcie mikroserwisów"), NDA przed shortlistą, 40-stronicowe załączniki z wymaganiami. Kupujesz rezultat, nie architekturę.
Dwie praktyczne uwagi: wyślij każdemu dostawcy ten sam dokument, bo jednolite odpowiedzi to jedyny sposób, by karta oceny cokolwiek znaczyła; i podaj wagi oceny w samym RFP. Dostawcy piszą ostrzejsze propozycje, gdy wiedzą, że referencje ważą więcej niż cena.
Jak ocenić dostawcę oprogramowania na zamówienie?
Ocena dostawcy oznacza punktowanie każdej propozycji tą samą kartą ważoną dowodami, żeby decyzja obroniła się przy drugim spojrzeniu. Cena zasługuje na mniejszą wagę, niż nadaje jej większość kupujących: propozycje zaniżone względem reszty zwykle wyceniły najmniej pracy. Karta oceny, którą rekomendujemy dla budżetów SME:
| Kryterium | Waga | Jak punktować |
|---|---|---|
| Referencje z właściwej domeny | 25% | 5: dwie referencje, do których faktycznie zadzwoniłeś, z Twojej domeny. 1: ściana logotypów |
| Prawa do audytu kodu | 15% | 5: pisemna zgoda na zewnętrzny code review przed końcową płatnością |
| Kondycja finansowa | 10% | 5: rentowność, wieloletni track record. 1: nie potrafią tego pokazać |
| Postawa bezpieczeństwa | 15% | 5: udokumentowany SDLC, skanowanie zależności, dostęp least-privilege |
| Ciągłość i staż zespołu | 15% | 5: nazwany zespół, niska rotacja. 1: „skompletujemy zespół po podpisaniu" |
| Rytm komunikacji | 10% | 5: pisemne zobowiązanie do cotygodniowego demo. 1: „używamy Slacka" |
| Dyscyplina IP | 10% | 5: czyste przeniesienie work-for-hire, bez ponownie używanego rdzenia własnościowego |
Wagi to punkt wyjścia. Przesuwaj je, ale niech sumują się do 100 i zapisz je, zanim przeczytasz pierwszą propozycję. Jak rankujemy firmy developerskie stosuje tę samą dyscyplinę; co faktycznie obejmują usługi developerskie pomaga porównywać pozycje jak do like.
Checklist due diligence przy zakupie oprogramowania
Przeprowadź go na dwóch najlepszych dostawcach przed podpisaniem, nie na wszystkich pięciu:
- Referencje sprawdzone prawdziwymi pytaniami (co się zepsuło, jak to obsłużyli, czy zatrudniłbyś ponownie)
- Prawa do audytu kodu uzgodnione pisemnie, przed końcową płatnością etapową
- Kondycja finansowa potwierdzona (lata na rynku, rentowność, koncentracja klientów)
- Postawa bezpieczeństwa sprawdzona (SDLC, kontrola dostępu, historia incydentów)
- Ciągłość kluczowych osób potwierdzona (zespół z pitcha to zespół projektowy)
- Przeniesienie IP sprawdzone przez Twojego prawnika, nie ich
9 klauzul umownych, które chronią Twój budżet
Klauzulą chroniącą budżet nie jest cena. Jest test odbioru. Wytyczne zakupowe UCLA, jedyna instytucjonalna strona w top 10 Google na ten temat, buduje swoje rekomendacje dla oprogramowania na zamówienie wokół tej idei: zakres prac, własność IP, testy odbiorcze i gwarancja, zanim cena wejdzie do pokoju. Rozwinęliśmy tę taksonomię w dziewięć klauzul dla kupujących komercyjnych.
Jeśli składasz szablon umowy na zakup oprogramowania, tych dziewięć wierszy to kręgosłup:
| # | Klauzula | Dlaczego kąsa | Przykładowe brzmienie w jednym zdaniu |
|---|---|---|---|
| 1 | Własność IP / work-for-hire | Bez niej dostawca zachowuje prawa autorskie i licencjonuje Ci oprogramowanie z powrotem | „Wszystkie deliverables są work made for hire; po zapłacie kupujący posiada pełne IP" |
| 2 | Kryteria i procedura odbioru | Jedyna obiektywna definicja „zrobione"; bez niej spory stają się opiniami | „Dostawa jest przyjęta tylko, gdy wszystkie testy z Załącznika B przejdą w środowisku kupującego" |
| 3 | Płatności powiązane z etapami | Trzyma gotówkę za postępem; zabija ryzyko 100% z góry | „20% przy starcie, potem 20% za etap, 20% przy odbiorze końcowym" |
| 4 | Kontrola zmian | Zatrzymuje spory o zakres, zanim staną się sporami o faktury | „Zmiany zakresu wymagają pisemnego zlecenia zmiany z wpływem na cenę i harmonogram, podpisanego przez obie strony" |
| 5 | Okres gwarancji | Zmusza dostawcę do stania za kodem po przekazaniu | „Dostawca usuwa wady znalezione w ciągu 90 dni od odbioru bez opłat" |
| 6 | Ochrona ceny | Ogranicza promień rażenia optymistycznych szacunków | „Stawki T&M zamrożone na 12 miesięcy; sufit nie do przekroczenia bez pisemnej re-akceptacji" |
| 7 | Specyfikacje wydajności | Z „jest wolno" robi naruszenie umowy, nie skargę | „p95 ładowania strony poniżej 2s; API p99 poniżej 300ms przy 500 równoczesnych użytkownikach" |
| 8 | Kluczowy personel | Zatrzymuje zamianę senior-pitch, junior-build | „Nazwani liderzy nie mogą być oddelegowani bez pisemnej zgody kupującego" |
| 9 | Wypowiedzenie i escrow kodu źródłowego | Twoje wyjście, gdy dostawca staje, bankrutuje albo odchodzi | „Kupujący może wypowiedzieć z ważnej przyczyny za 14-dniowym wypowiedzeniem; escrowowany kod wydany przy niewypłacalności" |
Pomiń którąkolwiek, a finansujesz nadzieję. Jeśli Twój prawnik ma czas na trzy klauzule, daj mu 1, 2 i 3.
Ile kosztuje oprogramowanie na zamówienie i jak ustrukturyzować płatność?
Zakres ustala cenę, dlatego SOW istnieje, zanim jakakolwiek wycena cokolwiek znaczy. Opublikowaną kotwicą jest szacunek ScienceSoft: 200 000–400 000 USD i około 10 miesięcy na korporacyjne oprogramowanie zakupowe klasy enterprise; ScienceSoft przypisuje tamtejszy wynik ROI 315% badaniu Forrester Total Economic Impact.
To ich liczby dla dużych projektów enterprise, nie nasze. Mniejsze projekty SME, narzędzie wewnętrzne, portal klienta, aplikacja mobilna, lądują dobrze poniżej tego pasma; traktuj nasz odczyt dla SME jako interpretację i zbierz trzy wyceny, zanim cokolwiek uznasz za pewnik. Dla kotwicy per aplikacja nasza rozpiska kosztów aplikacji mobilnej wycenia buildy według typu aplikacji.
Struktura płatności liczy się tak samo jak suma:
| Model | Wygrywa, gdy | Ryzyko ponosi | Typowe zastosowanie |
|---|---|---|---|
| Stała cena | Zakres zamrożony, a SOW szczelny | Dostawca (wchłania przekroczenia) | Dobrze zdefiniowane pierwsze wersje |
| Time-and-materials | Zakres będzie ewoluował i ufasz zespołowi | Ty (każda dodatkowa godzina jest fakturowana) | Buildy z dużym discovery lub długie |
| Płatności etapowe | Każdy model, z płatnościami za przyjęte deliverables | Wspólne (gotówka idzie za dowodem) | Większość projektów custom w SME |
| Kupno vs licencja vs subskrypcja IP | Kod posiadasz wyłącznie, gdy umowa przenosi IP; licencja i subskrypcja SaaS go wynajmują | Vendor lock-in przy licencji i subskrypcji | Kupuj, gdy oprogramowanie jest rdzeniem; subskrybuj, gdy jest towarem |
Nasza rekomendacja: domyślnie płatności etapowe przy zamrożonym zakresie, 20% lub mniej przy starcie, ostatnia transza warunkowana testem odbiorczym. Stała cena tylko, jeśli Twój SOW przetrwa próbę rozmontowania; time-and-materials tylko z dostawcą, z którym już coś dowieźliście. Nigdy 100% z góry; ta struktura wraca poniżej.
Czerwone flagi: jak naprawdę sypią się zakupy oprogramowania
Płacenie 100% z góry nie kupuje Ci priorytetu. Przenosi całe ryzyko dostawy na Ciebie. Każda czerwona flaga poniżej oddaje dostawcy siłę negocjacyjną, której nie odzyskasz:
- Mglisty SOW. „Zbudujcie nam CRM", bez listy funkcji. Każdy niezdefiniowany termin staje się zleceniem zmiany, wycenianym bez konkurencji.
- Brak testu odbioru. „Poznamy, jak zobaczymy." Wtedy nigdy nie zobaczysz, bo „zrobione" nigdy nie zostało zdefiniowane.
- Płatność 100% z góry. Gotówka to Twój jedyny argument po podpisaniu; wydaj ją całą pierwszego dnia i nie zostaje nic.
- Brak kontroli zmian. Zakres rośnie, faktury rosną, nikt nie podpisał wzrostu.
- Brak przeniesienia IP. Zapłaciłeś za oprogramowanie i wziąłeś je w licencję zwrotną, nawet tego nie zauważając.
- Brak klauzuli kluczowego personelu. Senior team, który wygrał pitch, znika w tygodniu po podpisaniu.
Co kwartał odpowiadamy na RFP na oprogramowanie na zamówienie po stronie dostawcy i dwa wzorce wracają tak regularnie, że traktujemy je jako bazowy odsetek porażek zakupowych: RFP bez jakichkolwiek kryteriów odbioru oraz harmonogramy płatności z większością z góry, dające dostawcy wszelkie powody, by odłożyć projekt na boczny tor, gdy gotówka już wpłynie. Nasza interpretacja, i jest to interpretacja, nie pomiar: kupujący, którzy najtwardziej negocjują cenę, to ci, którzy pominęli dwie klauzule, odbiór i etapy, które by ją ochroniły.
Dane branżowe wskazują w tę samą stronę. The Standish Group od trzech dekad śledzi wyniki projektów w badaniu CHAOS; jego powracającym wnioskiem jest to, że projekty zagrożone, z przekroczonym budżetem, spóźnione albo uboższe w funkcje, przewyższają liczbą czyste sukcesy, a mgliste wymagania i słaby sponsoring siedzą blisko szczytu list przyczyn.
Jeśli masz naprawić tylko jedną rzecz, napraw kryteria odbioru. To klauzula, która czyni egzekwowalną każdą inną.
Jak Techsy podchodzi do zamawiania oprogramowania
Nasz proces przyjęcia zlecenia przechodzi te same siedem kroków, tylko od drugiej strony stołu. Przygotowujemy SOW i kryteria odbioru, zanim podamy liczbę, bo wycenianie mglistego briefu to sposób, w jaki dostawcy zaniżają, a kupujący przepłacają. Buildy idą na płatnościach etapowych, cotygodniowych demo, prawach do audytu kodu w każdej umowie. Gdy odbiór przechodzi, posiadasz IP i repozytorium, nie licencję.
Uczciwe ograniczenia: jeśli potrzebujesz licencjonowanego narzędzia SaaS automatyzującego zakupy, jesteśmy złym wyborem. To zakup produktu, nie build; dostawca narzędzia obsłuży Cię szybciej i taniej. Bierzymy prace custom tam, gdzie oprogramowanie jest procesem, a IP ma znaczenie.
Jeśli Twój projekt mieści się w tym drugim koszyku, umów bezpłatną konsultację.
Najczęściej zadawane pytania
Czym jest zakup oprogramowania?
Zakup oprogramowania to proces pozyskiwania oprogramowania: zdefiniowanie potrzeby, ocena opcji, negocjacja warunków, przyjęcie dostawy. Obejmuje zarówno produkty licencjonowane, jak i buildy na zamówienie. Ten przewodnik skupia się na tym drugim: procesie od uzasadnienia biznesowego przez RFP, umowę i test odbiorczy.
Jakie są 4 typy zakupów?
Cztery powszechnie cytowane typy to zakupy bezpośrednie (wkłady produkcyjne), pośrednie (towary i usługi operacyjne), towarów i usług. Oprogramowanie leży na styku pośrednich i usług: licencjonowane narzędzie to zakup pośredni; custom build to usługa kończąca się dostarczonym towarem.
Jaka jest różnica między oprogramowaniem zakupowym a zamawianiem oprogramowania?
Oprogramowanie zakupowe to narzędzie automatyzujące procesy zakupowe, jak Tradogram czy Tipalti. Zamawianie oprogramowania na zamówienie to proces zlecania dedykowanego oprogramowania firmie developerskiej. Szukasz najlepszej platformy zakupowej? Chodzi Ci o to pierwsze; ten przewodnik jest o tym drugim.
Ile trwa zamawianie oprogramowania na zamówienie?
Zaplanuj 10–16 tygodni od uzasadnienia biznesowego do podpisanej umowy w typowym projekcie SME, zanim ruszy build; traktuj to jako interpretację, nie benchmark. Przedłużenie umowy z jednym dostawcą skraca się do tygodni; regulowany przetarg potrafi przeciągnąć się poza sześć miesięcy.
Ile kosztuje oprogramowanie na zamówienie?
ScienceSoft szacuje 200 000–400 000 USD i około 10 miesięcy na korporacyjne oprogramowanie zakupowe klasy enterprise, przypisując wynik ROI 315% badaniu Forrester. Mniejsze projekty SME lądują dobrze poniżej tego pasma. Przy zamawianiu oprogramowania na wymiar zakres ustala cenę: RFP i SOW istnieją, zanim jakakolwiek wycena cokolwiek znaczy.
Kto posiada IP w oprogramowaniu na zamówienie?
Ten, kogo wskazuje umowa. Bez wyraźnej klauzuli work-for-hire lub przeniesienia IP dostawca zachowuje prawa autorskie i licencjonuje Ci oprogramowanie z powrotem. Zapisz własność na piśmie, powiązaną z płatnością: po końcowej płatności kupujący posiada wszystko. Powiąż to przeniesienie z ostatnią transzą warunkowaną odbiorem, nie z płatnością startową, żeby własność przeszła dopiero wtedy, gdy przechodzi oprogramowanie.
RFP czy RFQ, czego potrzebuję?
RFP (request for proposal) pyta, jak dostawcy rozwiązaliby Twój problem; RFQ (request for quotation) pyta, ile kosztuje zdefiniowany zakres. Przy oprogramowaniu na zamówienie wyślij najpierw RFP: dostawcy muszą zaproponować podejście, zanim cena cokolwiek znaczy. RFQ przychodzi, gdy SOW jest zamrożony.
Stała cena czy time-and-materials?
Stała cena chroni Cię, gdy SOW jest szczelny: dostawca wchłania przekroczenia. Time-and-materials pasuje do prac z dużym discovery, gdzie zakres będzie ewoluował, ale ryzyko przekroczeń ponosisz Ty. Większość kupujących z SME wychodzi najlepiej na płatnościach etapowych przy zamrożonym zakresie, z ostatnią transzą warunkowaną testem odbiorczym.
Co powinien zawierać statement of work?
Statement of work powinien nazywać funkcje w zakresie i poza nim, integracje, harmonogram, kryteria odbioru, wobec których testowana jest dostawa, oraz etapy płatności powiązane z każdym deliverable. Jeśli jakiegoś terminu nie ma w SOW, nie ma go w projekcie.
O autorze
Mert Batur jest współzałożycielem Techsy.io, gdzie zespół dostarcza agentów AI, systemy automatyzacji i pipeline'y voice/SDR dla klientów B2B. Pisze o stosie narzędzi LLM, którego zespół Techsy faktycznie używa w produkcji. Prowadzi też projekty dostawy oprogramowania na zamówienie, z których czerpie ten przewodnik, od odpowiedzi na RFP po przyjęty odbiór. Połącz się na LinkedIn.
Podsumowanie
Zamawianie oprogramowania na zamówienie sprowadza się do artefaktów, nie negocjacji: jednostronicowe uzasadnienie biznesowe, SOW z kryteriami odbioru, szkielet RFP, karta oceny, umowa z dziewięcioma klauzulami. Dopracuj tych pięć dokumentów, a rozmowa z dostawcą potoczy się sama. Przeprowadź siedem kroków w kolejności, wstrzymaj końcową płatność do testu odbioru, a jeśli chcesz drugiej opinii o swoim RFP, umów bezpłatną konsultację.