Dostawca, który mówi „nie” — dlaczego odradzenie projektu to czasem najlepsza usługa
Zbierasz oferty na duży projekt IT. Pierwszy dostawca mówi, że zrobi wszystko z listy wymagań. Drugi obiecuje zespół od poniedziałku. Trzeci pyta, po co wam połowa tych funkcji, i sugeruje zacząć od czegoś mniejszego. Naturalna reakcja to pójść za dwoma pierwszymi. Przecież chcesz partnera, który chce projektu.
Tylko że najdroższy błąd w IT rzadko brzmi „wybraliśmy złą technologię”. Częściej brzmi „podpisaliśmy umowę na coś, co od początku nie miało sensu” – i dowiedzieliśmy się o tym po wydaniu pierwszych kilkuset tysięcy. Dostawca, który mówi „nie” albo „nie w tej formie”, niekoniecznie traci zlecenie. Czasem robi najlepszą robotę, jaką może zrobić przed podpisaniem umowy.
W skrócie
|
Dlaczego rynek nagradza „tak”, a nie uczciwość
Dostawca zarabia na podpisaniu umowy, nie na tym, czy inwestycja się zwróci.
W modelu rozliczenia za czas pracy każdy miesiąc developmentu to faktura. Im większy zakres na starcie, tym dłuższy kontrakt. Dostawca, który powie „połowa tego nie jest potrzebna”, sam skraca swój przychód. Dostawca, który powie „najpierw sprawdźmy, czy w ogóle potrzebujecie dedykowanego systemu”, ryzykuje, że projekt w ogóle nie wystartuje.
Po twojej stronie presja jest podobna. Zarząd chce daty. Inwestor pyta o roadmapę. Zespół sprzedaży obiecał klientom funkcje. W takiej atmosferze oferta zawierająca „tak” brzmi jak rozwiązanie problemu. Oferta z „nie” brzmi jak kolejna przeszkoda.
Problem w tym, że tylko 48% inicjatyw cyfrowych dowozi zakładany efekt biznesowy – według badania Gartner na ponad czterech tysiącach liderów IT i biznesu. Połowa projektów nie dowozi tego, co miały, często dlatego, że nikt na początku nie zatrzymał się i nie zapytał: czy to w ogóle ma sens w tej skali i w tej formie.
„Nie” ma kilka znaczeń – i rzadko chodzi o odrzucenie całego pomysłu
Kiedy dobry dostawca mówi „nie”, zwykle precyzuje, czego dotyczy odmowa.
To ważne rozróżnienie. CEO, który słyszy odmowę, często zakłada: „nie chcą naszych pieniędzy”. W praktyce odmowa wygląda inaczej:
- Nie ten zakres. „Nie zbudujemy wszystkiego naraz. Tak – zacznijmy od modułu, który rozwiązuje jeden konkretny problem.”
- Nie teraz. „Nie zaczynajmy developmentu, dopóki nie ustalicie metryki sukcesu.”
- Nie custom software. „Wasz problem da się rozwiązać gotowym narzędziem albo integracją. Dedykowany system będzie droższy niż korzyść.”
- Nie ten model współpracy. „Przy tym poziomie niepewności fixed price się nie broni. Potrzebujecie fazy discovery, zanim ustalimy zakres.”
Każda z tych odmów może prowadzić do współpracy – tylko w zdrowszej formie. Dostawca, który odmawia całego projektu bez wyjaśnienia i bez alternatywy, robi to samo co ten, który mówi „tak” do wszystkiego: zostawia cię z decyzją, której nie rozumiesz.
Cztery sytuacje, w których odradzenie chroni budżet
Największa oszczędność w IT to czasem uniknięcie inwestycji, która od początku nie miała szans na zwrot.
Poniżej cztery wzorce z realnych rozmów sprzedażowych. Nazwy firm i szczegóły branżowe pomijamy – mechanizm jest ten sam niezależnie od sektora.
Wiele pomysłów na automatyzację, a nie jeden problem do rozwiązania
Firma przyszła z listą pomysłów na automatyzacje: kilka różnych procesów, które „warto by było usprawnić”. Każdy z osobna brzmiał sensownie. Razem tworzyły zakres na wiele miesięcy pracy i setki tysięcy złotych – bez jednej liczby, która miałaby pokazać, czy całość się zwróci.
Po weryfikacji zaproponowaliśmy coś innego niż „zrobimy wszystko z listy”. Wskazaliśmy automatyzacje, które według nas miały szansę się opłacić biznesowo – i te zrealizowaliśmy. Resztę odrzuciliśmy albo odłożyliśmy.
Równolegle zarekomendowaliśmy zmianę podstawowego systemu zarządzającego w firmie na bardziej zaawansowany. Połowa funkcji, o które klient pytał w kontekście custom developmentu, była w nim już wbudowana. Zamiast budować od zera, wystarczyło wdrożyć narzędzie, które firma i tak potrzebowała na wyższym poziomie dojrzałości.
Odmowa nie brzmiała „nie chcemy waszego projektu”. Brzmiała: „nie budujcie dedykowanego oprogramowania do rzeczy, które macie w gotowym systemie – i nie automatyzujcie wszystkiego naraz, tylko to, co ma sens ekonomiczny”. Klient dostał krótszą drogę do efektu i mniejszy rachunek niż przy pełnej liście pomysłów.
Automatyzacja „żeby zwolnić dwie osoby”
Inna firma przyszła z jasnym celem: pięcioosobowy dział biurowy, z którego dwie osoby mają przejść na inne zadania. Pomysł: zautomatyzować ich pracę, żeby reszta zespołu dała radę bez nich.
Tego projektu nie rekomendowaliśmy.
Automatyzacja ma sens przy bardzo powtarzalnej pracy – takiej, gdzie ten sam schemat powtarza się setki razy w miesiącu i da się go opisać regułami. Gdy głównym celem jest „zastąpić ludzi AI” albo custom software, a chodzi o dwie osoby w niewielkim zespole, matematyka zwykle się nie domyka. Koszt budowy, wdrożenia i utrzymania systemu przewyższa oszczędność na pensjach – zwłaszcza jeśli proces nie jest w pełni powtarzalny i wymaga wyjątków, których automat nie obsłuży.
Wyjątek zaczyna się dopiero przy większej skali: powyżej pięciu osób na jednym, prostym procesie. Wtedy kalkulacja może się zgadzać. Przy dwóch osobach w pięcioosobowym dziale – rzadko.
Dostawca, który powiedziałby „tak, zrobimy platformę”, zarobiłby na kontrakcie. Dostawca, który powiedział „nie, to się nie opłaca” – oszczędził klientowi projekt, który wyglądał nowocześnie, ale nie miał szans na zwrot.
Brak właściciela biznesowego i mierzalnego celu
Średnia firma produkcyjna chciała „systemu, który usprawni operacje”. Na spotkaniu było pięć osób z pięcioma różnymi definicjami „usprawnienia”. Ktoś mówił o raportach. Ktoś o integracji z ERP. Ktoś o aplikacji dla techników w terenie. Nikt nie mógł odpowiedzieć na pytanie: jaką jedną liczbę biznesową ten projekt ma poprawić w ciągu sześciu miesięcy?
Odmowa brzmiała: „Nie zaczynamy developmentu, dopóki nie wyznaczycie jednej osoby po stronie biznesu, która odpowiada za priorytety, i jednej metryki, po której ocenicie, czy projekt się udał.”
To nie była drobna formalność. Bez tego zespół developerski buduje funkcje, które nikt nie będzie mierzył. Za kwartał usłyszysz „dowieźliśmy moduł X”, ale nie będziesz w stanie powiedzieć, czy operacje wysyłają szybciej, czy spadł koszt obsługi zlecenia. Więcej o tym, jak połączyć strategię firmy z projektami IT, piszemy w artykule o strategii biznesowej a projektach IT.
Liczby się nie spinają – nawet gdy pomysł brzmi nowocześnie
Cel „zwolnij dwie osoby przez automatyzację” to jeden przykład. Ten sam wzorzec wraca w innych formach: platforma AI, własny moduł raportowy, integracja „bo konkurencja już ma”. Technicznie da się to zbudować. Pytanie brzmi, czy koszt budowy, wdrożenia i utrzymania zwróci się w horyzoncie, który akceptujesz.
Jeśli dostawca nie zadaje tego pytania na starcie, odpowiedź usłyszysz dopiero po wydaniu budżetu. W modelu rozliczenia za czas pracy ryzyko ekonomiczne ponosisz ty. Dostawca, który odmawia mimo że mógł podpisać kontrakt, robi robotę doradcy – nie sprzedawcy.
Jak rozpoznać dostawcę, który powie prawdę
Szukaj kogoś, kto zadaje niewygodne pytania, zanim zaproponuje zespół.
Kilka sygnałów, które warto sprawdzić jeszcze przed podpisaniem umowy:
- Pyta „po co”, zanim pyta „jak”. Zanim usłyszysz o technologii i liczbie developerów, dobry dostawca chce zrozumieć problem biznesowy i metrykę sukcesu.
- Odmawia elementów twojej listy wymagań. Jeśli wszystko, co wpiszesz w brief, ląduje w zakresie bez dyskusji, ktoś albo nie rozumie kontekstu, albo nie planuje ci powiedzieć „nie” nigdy.
- Proponuje mniejszy krok zamiast dużego kontraktu. Warsztat discovery przed developmentem albo proof of concept na jednym module to nie opóźnienie projektu. To sposób na sprawdzenie założeń, zanim wydasz sześć cyfr.
- Mówi wprost o ryzykach. Nie „wszystko da się zrobić”, tylko „przy tym zakresie i tym budżecie ryzykujemy X – oto co proponujemy zamiast tego”.
- Nie boi się stracić kontraktu. Dostawca, który woli powiedzieć prawdę niż podpisać zły deal, traktuje relację długoterminowo. Nawet jeśli teraz nie podpiszecie umowy na pełny projekt.
To nie znaczy, że masz szukać dostawcy, który odmawia wszystkiego. Chodzi o to, żeby „tak” było uzasadnione, a nie automatyczne.
Co zrobić, gdy słyszysz „nie”
Pierwsza reakcja CEO jest zrozumiała: skoro ten nie chce, znajdę kogoś, kto chce. Czasem to ma sens – np. gdy odmowa wynika z braku kompetencji w branży, a nie z realnej analizy. Częściej jednak szukanie dostawcy, który powie „tak” za wszelką cenę, kończy się dokładnie tym, przed czym pierwszy dostawca chciał cię ochronić.
Zadaj trzy pytania:
- Czego dotyczy odmowa? Cały projekt, zakres, timing, technologia – czy model współpracy?
- Co dostawca proponuje zamiast tego? Jeśli odmawia bez alternatywy, to słaba odmowa. Jeśli mówi „nie tak, ale tak w innej formie” – masz materiał do rozmowy.
- Czy moja strona spełnia warunki, które wymienił? Czasem „nie” oznacza: najpierw uporządkujcie decyzje wewnętrzne, wyznaczcie właściciela, policzcie ROI – i wróćcie.
Co dalej
- Jeśli odmowa dotyczyła za dużego zakresu na start, sprawdź, jak scope creep po cichu pożera budżet – i jak go zatrzymać, zanim wystartujesz z pełną listą wymagań.
- Jeśli chcesz porównać oferty i wiedzieć, czego wymagać przed umową, zacznij od transparentności kosztów w projekcie software – to drugi artykuł z serii „zanim podpiszesz umowę”.
- Jeśli brakowało celu biznesowego i metryki sukcesu, wróć do fundamentów: strategia biznesowa a projekty IT.
- Jeśli dostawca zaproponował mniejszy krok zamiast pełnego kontraktu, zobacz, co daje faza discovery w ramach tworzenia produktów cyfrowych – zanim wydasz pierwsze poważne pieniądze na development.
Podsumowanie
Dostawca, który mówi „nie”, nie jest dostawcą, który nie chce pracować. Często jest dostawcą, który rozumie, że jego prawdziwa praca zaczyna się od uczciwej oceny, czy inwestycja ma sens – nie od podpisania umowy na wszystko, co zmieści się w budżecie.
Większość rynku nagradza „tak”. Twoim zadaniem nie jest znaleźć kogoś, kto powie “tak” najszybciej, ale kogoś, kto powie prawdę, zanim wydasz pieniądze, których nie odzyskasz przez sam fakt, że system „działa”.
Czasem najlepsza usługa, jaką dostawca może ci zaoferować, to odradzenie projektu, który nigdy nie powinien wystartować w formie, w jakiej go zaplanowałeś. Reszta to szczegóły negocjacji.
Zanim podpiszesz umowę – wiesz, czego wymagać od dostawcy?
Checklista kondycji produktu to 25 pytań w pięciu obszarach: strategia, discovery, delivery, współpraca i odpowiedzialność. Przejdź przez nią przed rozmową z dostawcą – i wejdź w negocjacje ze standardami, nie z listą życzeń.
