Zapytanie „ile kosztuje integracja sklepu z ERP?" to najdroższa rozmowa w polskim MŚP. Nie dlatego, że dostawcy są drodzy. Dlatego, że nikt — włącznie z Tobą — tak naprawdę nie wie, o co pytasz.
Typowy scenariusz. Właściciel firmy wysyła maila do czterech dostawców IT, których ktoś mu polecił. Pytanie jedno: „ile to będzie kosztowało". Po tygodniu wracają cztery oferty. Jedna za 24 tysiące. Druga za 48. Trzecia za 92. Czwarta za 180 — i jeszcze zastrzeżenie, że „to kwota wyjściowa, bo wymagania są nieprecyzyjne". Właściciel patrzy w ekran i nie wie, co z tym zrobić. Każdy dostawca zrozumiał „integrację" po swojemu.
To nie jest problem dostawców. To jest problem zapytania. I to problem, który można rozwiązać w jedno popołudnie, zanim ktokolwiek wyśle pierwszą ofertę.
Dlaczego „RFP ze szablonu" nie działa
Jeśli wpiszesz w Google „szablon zapytania ofertowego IT", dostaniesz 40-stronicowy dokument z sekcjami o historii firmy, misji, strategii pięcioletniej i matrycy odpowiedzialności RACI. Dla MŚP to jest marnowanie czasu — po obu stronach.
Dostawca nie potrzebuje misji Twojej firmy. Potrzebuje odpowiedzi na kilka bardzo konkretnych pytań, których szablony RFP akurat nie zadają. Dwustronicowa, uczciwa odpowiedź na te pytania jest warta więcej niż czterdziestostronicowy szablon, w którym 90% pól wypełniłeś „do uzgodnienia".
Specyfikacja wymagań dla MŚP ma zrobić trzy rzeczy:
- Opisać problem, który chcesz rozwiązać. Nie technologię, którą chcesz kupić.
- Dać dostawcy twarde dane, żeby mógł policzyć pracę. Ilości, przykłady, scenariusze — nie slogany.
- Pokazać, jak będziesz oceniać, czy się udało. Czyli co się zmieni w firmie, gdy projekt skończy się dobrze.
To wszystko. Bez tego nie ma rozmowy o pieniądzach — jest licytacja na życzenia.
Minimum, które warto opisać
Dla większości projektów integracyjnych i wdrożeniowych w MŚP spokojnie wystarczy 2–4 strony A4. Zawartość:
- Dziś (jeden akapit). Jak dziś wygląda proces, który chcesz zmienić. Krótko: kto, w jakim systemie, ile razy dziennie, ile czasu to zajmuje. Jedno zdanie o tym, co boli najbardziej.
- Systemy, które są w grze. Nazwa, wersja, kto jest producentem lub serwisantem, czy mają API, kto zna hasło administratora. „Comarch Optima 2026, serwisant: XYZ, API dostępne, kontakt techniczny: Jan Kowalski (jan@...)". Bez tego dostawca strzela.
- Co ma się zmienić. Opisany w kategoriach codziennej pracy, nie technologii. „Zamówienie ze sklepu ma trafiać do Optimy w ciągu 15 minut, bez przepisywania ręcznego, z zachowaniem rabatu klienta i formy płatności". A nie: „zbudujmy mikroserwis integracyjny".
- Ilości. Ile transakcji dziennie? Ile pozycji w kartotece? Ile oddziałów? Ile walut? Ile dokumentów miesięcznie? To są dane, od których zależy cała architektura. Dostawca, który dostaje liczby, policzy pracę. Dostawca, który dostaje „raczej dużo", policzy na wszelki wypadek dwa razy więcej.
- Przypadki brzegowe, których nie chcesz zapomnieć. Co z zamówieniami przedpłaconymi? Co ze zwrotami? Co z klientami zagranicznymi? Co z fakturami walutowymi? Wypisz 5–10 sytuacji, które się u Was zdarzają — nawet rzadko. Dostawcy wyceniają głównie przypadki brzegowe, bo one zjadają 60% czasu wdrożenia.
- Co ma być zrobione, a co nie. Czyli zakres: „zakres obejmuje integrację zamówień i stanów magazynowych; nie obejmuje integracji płatności, lojalności, zwrotów". Jeśli tego nie napiszesz, pierwszy dostawca wyceni dwa procesy, drugi siedem — i oferty nie będą porównywalne.
- Jak poznasz, że projekt się udał. Jedno–dwa zdania, mierzalnie. „Ręczne przepisywanie zamówień spadnie z 2 godzin dziennie do zera; błędy adresowe spadną o 90%". To nie jest formalność — to jest kryterium odbioru.
- Twoje ograniczenia. Budżet orientacyjny (nie trzymaj go w tajemnicy — i tak dostawcy zapytają), termin, dostępność Waszych ludzi, zależności od zewnętrznych serwisów ERP.
Jeśli dokument robi się dłuższy niż cztery strony, to zwykle znak, że pakujesz do niego rzeczy, które powinny być osobnym projektem.
Jeden konkretny przykład
U jednego z naszych klientów — 18-osobowej hurtowni armatury sanitarnej z Dolnego Śląska — zaczęło się właśnie od tego klasycznego maila: „ile kosztuje integracja naszego sklepu z Comarch Optima?". Właściciel wysłał go do czterech firm. Wrócił z ofertami: 24 tys. zł, 48 tys. zł, 92 tys. zł i 180 tys. zł.
Zadzwonił do nas po drugiej opinii, bo nie wiedział, czy ten pierwszy to okazja, czy pułapka. Usiedliśmy na trzy godziny, spisaliśmy spec na 3 strony. Zawartość:
- Dziś: 2 handlowców przepisuje zamówienia ze sklepu do Optimy, średnio 60 zamówień dziennie, czas: ok. 2,5 h łącznie. Błędy adresowe raz w tygodniu.
- Systemy: PrestaShop 8.1 (hosting zewnętrzny, dostęp admin), Comarch Optima 2026 (serwisant X, API dostępne).
- Zakres: zamówienia (B2C i B2B), aktualizacja stanów magazynowych w sklepie, dane klientów. Poza zakresem: płatności (zostaje PayU), kartoteka produktów (zostaje jednostronny eksport z Optimy raz dziennie), zwroty i reklamacje.
- Ilości: 60 zamówień/dzień, 4 500 indeksów produktowych, 2 oddziały, 1 waluta, docelowo może dojść EUR.
- Brzegowe: zamówienia z rabatem klienta B2B, zamówienia na „pobranie", stany ujemne (nie dopuszczać), produkty na zamówienie (nie integrować stanów), wysyłka na adres inny niż fakturowy.
- Sukces: handlowcy odzyskują min. 2 godziny dziennie, zero ręcznego przepisywania, błędy adresowe < 1 miesięcznie, rozliczenie VAT bez zmian.
- Budżet orientacyjny: do 60 tys. zł, start kwartał I, wdrożenie etapami.
Właściciel wysłał tę samą specyfikację do tych samych czterech dostawców. Nowe wyceny: 42, 48, 51, 54 tys. zł. Odchylenie 29% zamiast 650%. Dwóch dostawców, którzy wcześniej wycenili skrajnie (24 i 180), odpadli — jeden sam przyznał, że „nie zauważył połowy wymagań", drugi w nowej wycenie zrezygnował z udziału. Projekt dojechał za 51 tys. zł, w terminie, z dwoma zmianami zakresu po drodze, które były wycenione osobno — bez awantury.
Czas spędzony na pisaniu specyfikacji: 3 godziny. Oszczędność netto: trudno policzyć dokładnie, ale co najmniej 4 miesiące błądzenia po omacku i 100 tysięcy złotych na stole. Nic nowego pod słońcem — po prostu ktoś w końcu zapytał się konkretnie.
Czego nie wstawiaj do specyfikacji
Specyfikacja robi się bezużyteczna, kiedy zaczyna się robić bezpieczna.
- „Nowoczesny, intuicyjny, skalowalny." To są słowa, które niczego nie mówią dostawcy. Każdy odpowie: „oczywiście, nasze rozwiązanie jest nowoczesne". Zamiast tego: liczby, procesy, nazwy.
- Konkretne technologie w roli celu. „Chcemy to w .NET 8 na Azure" ma sens, jeśli masz twarde ograniczenia (bo istniejący zespół pracuje w .NET). Nie ma sensu, jeśli przepisujesz z internetu, bo wygooglałeś co jest modne. Opisz problem, dostawca zaproponuje stos.
- Wymagania w stylu „coś takiego jak u konkurencji". Dostawca nie wie, co dokładnie widzisz u konkurencji. Opisz dwa–trzy konkretne ekrany lub przepływy.
- „Reszta do uzgodnienia na warsztatach." To zdanie w specyfikacji oznacza, że sobie przerzucasz pracę. Dostawca wyceni warsztaty dwa razy wyżej, bo nie wie, co z nich wyjdzie.
Jeśli czegoś nie wiesz, napisz wprost: „na dziś nie wiemy, czy to będzie w zakresie — proszę o wycenę oddzielnie". To uczciwe i wyceny będą rozsądne.
Jak zacząć w jedno popołudnie
Nie musisz pisać traktatu. Kolejność, która działa:
- 90 minut rozmowy z ludźmi, którzy faktycznie pracują w procesie. Nie z zarządem. Dwóch handlowców, księgowa, magazynier — zależnie od projektu. „Co dzisiaj robicie ręcznie? Gdzie najczęściej są błędy? Co by zmieniło Wam życie?"
- 60 minut spisania wymagań na 2–4 strony. Nie szablon RFP. Zwyczajny dokument Word albo Markdown ze strukturą: dziś, systemy, zakres, ilości, brzegowe, sukces, budżet. Po polsku, bez żargonu.
- 30 minut przeczytania tego osobie, która będzie korzystać z nowego systemu. „Czy to opisuje Twoją pracę?". Jeśli odpowie „tak, ale brakuje jeszcze X" — dopisujesz X.
- Wysłanie do 3–4 dostawców. Nie więcej. Pięciu i więcej to już ciężar, którego nie przerobisz uczciwie.
I pytanie, które warto zadać dostawcy na końcu zapytania, zamiast listy pytań z internetu: „Czego brakuje w tej specyfikacji, żebyś mógł dać rzetelną wycenę?". Dostawca, który odpowie konkretnie — już widać, że myśli. Dostawca, który odpowie „wszystko jest jasne, wycena w załączeniu" — już widać, że nie myśli.
Jeśli nie wiesz, jak opisać projekt tak, żeby wyceny się nie rozjeżdżały o rząd wielkości — pół godziny rozmowy z kimś, kto widział tego setki, oszczędza miesiące licytacji na życzenia.
Dobra specyfikacja nie opisuje systemu, który chcesz. Opisuje problem, który masz — na tyle konkretnie, żeby ktoś z zewnątrz mógł policzyć, co z tym zrobi.
Porozmawiajmy o Twoim projekcie IT, zanim wyślesz zapytania →