Wybór dostawcy systemu IT to jedna z tych decyzji, przy której wielu właścicieli firm i prezesów czuje niepewność. Siedzimy na spotkaniu, słuchamy przekonującego handlowca, oglądamy efektowne demo, a w głowie kołacze się jedno pytanie: czy ci ludzie naprawdę są w stanie to dowieźć, czy tylko świetnie sprzedają obietnice?

Znam to uczucie. I wiem, że ból pojawia się zazwyczaj nie podczas podpisywania umowy, ale sześć miesięcy później, kiedy okazuje się, że projekt się przeciąga, budżet rośnie, a system nie robi tego, co miał robić. Dlatego chcę podzielić się sprawdzonymi sposobami na to, jak zweryfikować dostawcę zanim jeszcze cokolwiek podpiszecie.

Prezentacja funkcjonalności systemu to za mało

Klasyczny scenariusz wygląda tak: dostawca zaprasza na spotkanie, przychodzi z piękną prezentacją, pokazuje wszystkie moduły systemu np. ERP przez trzy godziny, a wy wychodzicie z wrażeniem, że widzieliście coś skomplikowanego, ale nie wiecie, czy to rozwiąże wasz konkretny problem.

To pułapka. Systemy IT, które są wykorzystywane w przedsiębiorstwach o różnych potrzebach mają dziesiątki jak nie setki funkcji. Pokazywanie ich wszystkich szerokiemu gronu osób z waszej firmy to strata czasu – lepszym wyjściem jest skupić się na tym, co krytyczne dla biznesu.

Zamiast tego, poproście o coś innego: weryfikację konkretnych funkcji, które są kluczowe dla waszych procesów. Niech dostawca pokaże, jak system obsłuży wasz realny scenariusz – nawet jeśli macie go tylko opisany słowami, a nie rozrysowany w postaci schematów. Jeśli dostawca jest w stanie wskazać, jak jego narzędzie rozwiąże wasz konkretny problem (np. ręczne raportowanie realizacji zleceń produkcyjnych lub brak identyfikowalności partii produkcyjnych), macie pierwszy sygnał, że wie, o czym mówi. Jeśli zaczyna uciekać w ogólne slogany – to alarm.

Spotkajcie się z ludźmi od realizacji, nie tylko od sprzedaży

Tu dochodzimy do sedna. Większość firm pokazuje wam tylko twarz sprzedażową – elokwentnego handlowca, który obiecuje złote góry. Ale kto będzie pracował z wami przy tworzeniu rozwiązania, gdy zacznie się projekt?

Świadomy, doświadczony dostawca nie będzie miał problemu, żeby na spotkanie przyjść z osobą, która realnie poprowadzi wdrożenie – architektem rozwiązania, analitykiem biznesowym czy project managerem. To ważny test: jeśli firma chowa swój zespół techniczny przed klientem na etapie sprzedaży, zastanówcie się dlaczego. Być może nie ma pewności co do swoich ludzi, albo – co gorsza – planuje „sprzedać” jednym zespołem, a wdrożyć drugim, tańszym.

Poproście o krótkie spotkanie z przyszłym PM-em, architektem i głównym developerem. Sprawdźcie, czy rozumieją waszą branżę, czy zadają trafne pytania, czy potrafią wskazać ryzyka. To spotkanie powie wam więcej niż sto slajdów.

Jak rozmawiają o zmianach? To test na uczciwość

W każdym projekcie IT zakres się zmienia. To naturalne – dopiero w trakcie pracy odkrywacie, że coś trzeba dopracować. Ale tu jest kluczowy moment: obserwujcie, jak dostawca reaguje na propozycje zmian.

Jest różnica między partnerem a wykonawcą, który chce tylko zarobić. Ten drugi przytakuje na wszystko: „tak, tak, to da się zrobić”, bo wie, że każda zmiana to dla niego dodatkowa faktura. Nie interesuje go, czy projekt się przeciągnie czy przekroczycie budżet – byleby tylko podpisać aneks.

Dobry dostawca będzie pilnował granic. Jeśli ustaliliście fixed price, będzie transparentnie mówił: „tak, to jest poza zakresem, ale zróbmy to w kolejnej fazie, żeby nie zagrozić terminowi”. Będzie umiał wytłumaczyć wpływ zmiany na koszty i czas, i będzie proponował, które decyzje podjąć na poziomie operacyjnym, a które wymagają decyzji waszego zarządu. To oznaka dojrzałości – ktoś, kto chce, żeby projekt się udał, a nie tylko żeby wyciągnąć od was jak najwięcej pieniędzy.

Transparentność, której nie da się podrobić

Kolejny test: poproście o wgląd w narzędzia, których używają do zarządzania projektem. Nie chodzi o to, żebyście sami musieli w nich pracować, ale żebyście widzieli, jak wygląda rejestr czasu pracy, zadań, postępów.

Dostawca, który ma czyste intencje i pewność swoich wycen, nie będzie ukrywał danych. Pokaże wam, ile godzin poświęcili na analizę, ile na development, jak wygląda backlog. Dostawca niepewny swoich kompetencji będzie się wycofywał: „damy wam raport raz w miesiącu, w Excelu, bez szczegółów”.

To samo dotyczy architektury systemu. Poproście o rysunek architektury z poprzedniego, podobnego projektu. Jeśli dostawca jest w stanie pokazać, jak rozwiązał podobne wyzwanie u innego klienta, opisać proces analizy przedwdrożeniowej, wytłumaczyć, jak zarządzał zmianami – macie dowód, że to nie jest jego pierwszy projekt.

Referencje, które mają wartość

Wszyscy dostawcy podają referencje. Ale nie opierajcie weryfikacji na pytaniu: „Czy jesteście zadowoleni?” Oczywiście, że są – inaczej dostawca by ich nie podał.

Zadawajcie pytania techniczne: Jaki był realny skład zespołu? Czy był tam dedykowany analityk, czy jedna osoba robiła wszystko? Jak wyglądała transparentność – mieliście wgląd w narzędzia projektowe? Jak dostawca reagował na zmiany zakresu – akceptował wszystko, czy pilnował was przed błędami? Czy projekt był realizowany metodyką, którą obiecywali na starcie?

To są pytania, które weryfikują, czy dostawca jest spójny między tym, co mówi na etapie oferty, a tym, co robi na projekcie.

Sprawdźcie, czy rozumieją wasz biznes, nie tylko software

To subtelna, ale kluczowa różnica. Czy dostawca pyta o parametry sukcesu projektu? Czy zastanawia się, jak zmierzyć zwrot z inwestycji? Czy potrafi doradzić, jak uniknąć błędów, które popełniali inni klienci?

Firmy, które przeszły już kilkanaście wdrożeń, mają w głowie bibliotekę case’ów. Wiedzą, że wdrażanie systemu to nie tylko instalacja oprogramowania, ale zmiana procesów. Jeśli dostawca potrafi powiedzieć: „u poprzedniego klienta w tej branży zrobiliśmy tak, a nie inaczej, bo…”, to macie do czynienia z partnerem, nie tylko wykonawcą.

Metodyka i zespół – czyli kto konkretnie to zrobi?

Na koniec – sprawdźcie, czy dostawca ma pomysł na skład zespołu. W profesjonalnym wdrożeniu nie może być tak, że jedna osoba jest analitykiem, architektem, testerem i project managerem naraz.

Poproście o propozycję składu: kto będzie odpowiadał za architekturę (łączenie komponentów), kto za analizę biznesową (zbieranie wymagań i tłumaczenie waszych potrzeb na zadania dla programistów), kto za testowanie, kto za zarządzanie projektem. Zwróćcie uwagę na seniority – czy to będą doświadczone osoby, czy juniorzy uczący się na waszym projekcie.

Dobry dostawca zaproponuje też stworzenie macierzy odpowiedzialności (RACI) jeszcze przed startem – dokumentu, który precyzyjnie określa, kto za co odpowiada po obu stronach. To znak, że myśli o zarządzaniu ryzykiem i nie chce, żeby później były niejasności typu „a myślałem, że wy to robicie”.

Podsumowując – nie musicie być ekspertami IT

Weryfikacja dostawcy nie wymaga od was technicznej wiedzy na poziomie programisty. Wymaga zdrowego rozsądku i odwagi, żeby zadać niewygodne pytania. Przejrzyjcie dostawcę przez trzy pryzmaty: komunikację (czy rozmawiacie z ludźmi od realizacji, nie tylko od sprzedaży), doświadczenie (czy potrafią opisać realne case’y i pokazać narzędzia do zarządzania projektami) oraz metodykę (czy mają proces wdrożenia, który uwzględnia migrację danych, szkolenia użytkowników i testowanie oprogramowania, czy mają kompetentny zespół i są transparentni w trakcie współpracy).

To potrafi zająć kilka godzin, ale może uratować przed wielomiesięcznym bólem wdrożeniowym. Bo kiedy już podpiszecie umowę, wasze pole manewru drastycznie się zmniejsza. Lepiej zadać trudne pytania teraz, niż żałować później.