Jak przygotować firmę do pierwszego dużego projektu IT: Praktyczny przewodnik dla właścicieli i zarządów

Firma rośnie. Na początku wystarczały arkusze kalkulacyjne, kilka folderów „na dysku" i dobra pamięć kluczowych osób. Z czasem jednak zamówienia zaczynają się mieszać, klienci pytają o statusy, raporty powstają „po godzinach", a każda nieobecność jednego pracownika potrafi zatrzymać proces. Właściciel lub zarząd widzi, że organizacja dojrzewa — i że dotychczasowe metody przestają dowozić wyniki.

W tym momencie naturalnie pojawia się myśl: „Potrzebujemy systemu". Tylko że przygotowanie firmy do pierwszego dużego projektu IT rzadko jest kwestią technologiczną. To przede wszystkim decyzja organizacyjna i strategiczna: co zmieniamy, po co, kto ma to poprowadzić i jak uniknąć paraliżu w codziennej pracy.

Rok 2021 dodatkowo wzmocnił tę presję. Po pandemicznym chaosie wiele firm zobaczyło, jak ważna jest odporność operacyjna: możliwość pracy zdalnej, szybki dostęp do danych, automatyzacja powtarzalnych czynności. Jednocześnie niepewność gospodarcza uczy ostrożności — inwestycje muszą być przemyślane, a ryzyko ograniczane mądrą organizacją projektu.

Z perspektywy właściciela to często wygląda tak: „Znajdźmy dobrego wykonawcę, a reszta się ułoży". I jasne — partner technologiczny ma ogromne znaczenie. Ale z doświadczenia wiem, że źródło większości problemów w projektach IT nie leży w „słabym kodzie" czy złej technologii. Leży w tym, że firma nie była gotowa na zmianę, a projekt od początku miał niejasny cel i zbyt wiele domysłów.

Wyobraźmy sobie średnią firmę usługową, nazwijmy ją roboczo „Alfa". Rosła szybko, więc zarząd postanowił wdrożyć system do obsługi zleceń i rozliczeń. Wybrali dostawcę, podpisali umowę i… po kilku tygodniach zaczęły się schody. Dział operacyjny mówił jedno, sprzedaż drugie, finanse trzecie. Nikt nie miał czasu na warsztaty, bo „bieżączka". Wykonawca zadawał pytania o procesy, a odpowiedzi były w stylu: „to zależy", „zawsze robimy to inaczej", „Pani Kasia wie". Projekt zaczął się rozjeżdżać, a po stronie firmy narastało rozczarowanie: „Mieli dostarczyć system, a tylko pytają".

To typowy mechanizm: bez przygotowania po stronie klienta projekt staje się serią doprecyzowań, zmian i gaszenia pożarów. Dostawca (nawet dobry) może pomóc uporządkować chaos, ale nie zastąpi decyzji biznesowych ani wewnętrznego lidera, który potrafi powiedzieć: „tak robimy" i wziąć za to odpowiedzialność.

Dobrze przygotowana firma to lepsza współpraca, mniej nieporozumień i szybsze efekty. A co ważne — to także mniejsze ryzyko, że po wdrożeniu ludzie powiedzą: „to nie działa", bo w praktyce nikt nie uzgodnił, jak ma działać.

Kiedy zaczynam rozmowy z firmami, najczęściej słyszę listę potrzeb: „chcemy moduł X", „raport Y", „aplikację dla handlowców", „integrację z…". To zrozumiałe — tak myśli biznes, kiedy czuje ból. Problem w tym, że same funkcje nie są celem. Celem jest poprawa działania firmy: szybciej realizować zamówienia, ograniczyć błędy, odzyskać czas kluczowych osób, lepiej kontrolować marżę, skrócić czas reakcji na klienta.

„Dlaczego" porządkuje priorytety. Jeśli dziś największym kosztem jest chaos w realizacji zleceń, to nie ma sensu zaczynać od rozbudowanych raportów zarządczych. Jeśli największym ryzykiem jest brak kontroli nad kosztami, to kluczowe będzie to, skąd bierzemy dane i kto je zatwierdza — a nie to, jak ładnie wygląda ekran.

W praktyce warto usiąść i odpowiedzieć sobie (szczerze, nawet jeśli odpowiedzi są niewygodne): co dokładnie spowalnia firmę i gdzie tracimy pieniądze lub klientów. Bardzo często są to miejsca, o których „wszyscy wiedzą", ale nikt nie nazwał ich wprost. A dopóki nie nazwiemy problemu, projekt IT będzie próbą leczenia objawów.

Pomocne bywa też spojrzenie na cele w horyzoncie 12–24 miesięcy. Jeśli firma planuje podwoić skalę, wejść na nowy rynek lub znacząco zwiększyć liczbę zamówień, to system ma wspierać właśnie ten kierunek. Wtedy brief dla software house'u nie jest „zróbcie nam narzędzie", tylko „pomóżcie nam przejść na kolejny poziom bez utraty kontroli".

Duży projekt IT to projekt zmiany w firmie. To oznacza, że nie może żyć na marginesie — „gdzieś w IT" albo „u kogoś, kto ma chwilę". Jeśli firma ma 50–500 pracowników, zwykle nie ma luksusu, żeby takie wdrożenie nie dotykało codzienności. Ono dotknie — pytanie tylko, czy w kontrolowany sposób.

Na start potrzebne są trzy perspektywy: decyzyjna, operacyjna i finansowa. Decyzyjna, bo ktoś musi mieć mandat, żeby rozstrzygać spory i utrzymać kierunek. Operacyjna, bo ktoś rozumie procesy „od środka" — nie z prezentacji, tylko z codziennych problemów. Finansowa, bo projekt to inwestycja i trzeba umieć ocenić konsekwencje zmian, także tych, które pojawią się po drodze.

Kluczową rolę odgrywa wewnętrzny lider projektu. To osoba, która trzyma rytm, zbiera informacje, pilnuje terminów ustaleń i potrafi powiedzieć „stop" wtedy, gdy organizacja zaczyna dodawać kolejne „a może jeszcze". W wielu firmach naturalnym kandydatem jest dyrektor operacyjny lub doświadczony manager procesu — ktoś, kto zna realia i ma autorytet.

Warto też jasno nazwać, że „osoba z IT" (jeśli jest) nie zawsze będzie najlepszym liderem. Nie dlatego, że nie potrafi — tylko dlatego, że w pierwszym dużym projekcie kluczowe są decyzje biznesowe i zarządzanie zmianą, a nie tylko tematy techniczne. Technik może być ogromnym wsparciem, ale ktoś musi zadbać o to, żeby projekt służył firmie, a nie odwrotnie.

Jedną z największych obaw nietechnicznych decydentów jest myśl: „Nie umiemy tego opisać profesjonalnie". I tu dobra wiadomość: nie musicie. Najbardziej wartościowe opisy procesów to często te nieidealne, ale prawdziwe. Nie potrzebujecie od razu diagramów i formalnej dokumentacji. Potrzebujecie szczerego obrazu tego, jak firma działa dziś.

Bardzo dobrze działa ćwiczenie „przejścia przez dzień pracy". Wybierzcie jeden kluczowy obszar (np. obsługa zamówienia od zapytania do faktury) i przejdźcie go krok po kroku: kto zaczyna, co powstaje (mail, plik, telefon), gdzie trafiają dane, kto zatwierdza, gdzie pojawiają się opóźnienia i dlaczego. W trakcie prawie zawsze wychodzą „niewidoczne" elementy procesu: ręczne przepisywanie, podwójne wprowadzanie danych, szukanie informacji w wielu miejscach, zależności od jednej osoby.

Jeśli macie poczucie, że procesy w firmie są „różne w zależności od sytuacji", tym bardziej warto to opisać. Dla partnera technologicznego to cenna informacja: gdzie potrzebna jest elastyczność, a gdzie warto wprowadzić standard. System nie ma odzwierciedlać chaosu w 100%, tylko pomóc go uporządkować — ale do tego trzeba zrozumieć punkt wyjścia.

Na tym etapie najlepiej działa prosta narracja: kilka stron tekstu, screeny używanych dziś narzędzi, przykładowe dokumenty (bez danych wrażliwych). Dobry partner pomoże to potem ustrukturyzować i zamienić na plan pracy. Jednak bez tej „surowej prawdy" projekt będzie budowany na domysłach, a domysły w IT są kosztowne.

Pierwszy duży projekt IT bywa dla firm zderzeniem z nową rzeczywistością: to nie jest zakup gotowego produktu z półki, tylko proces, w którym uczymy się firmy, podejmujemy decyzje i stopniowo wdrażamy zmianę. Warto nastawić się na maraton. Nawet jeśli pierwsze efekty mogą pojawić się relatywnie szybko, droga do stabilnego rozwiązania zazwyczaj ma etapy: odkrywanie, porządkowanie, wdrażanie, poprawki, kolejne usprawnienia.

Czas trwania zależy od skali i stopnia „uszycia na miarę". Inaczej wygląda projekt, który porządkuje jeden krytyczny proces, a inaczej taki, który dotyka wielu działów naraz. Dobrą praktyką jest etapowanie: zacząć od najważniejszego obszaru, dowieźć realną wartość i dopiero potem rozszerzać rozwiązanie. To ogranicza ryzyko i pozwala lepiej kontrolować priorytety.

Budżetowo najważniejsze jest zostawienie przestrzeni na rzeczy, których nie da się przewidzieć na starcie. I to nie dlatego, że ktoś jest niekompetentny, tylko dlatego, że dopiero w trakcie pracy wychodzą detale: wyjątki, nietypowe przypadki, potrzeba dodatkowych raportów, inne podejście do uprawnień czy akceptacji. Jeśli firma planuje budżet „na styk", każdy taki wniosek staje się konfliktem zamiast naturalną decyzją biznesową.

No i zaangażowanie: projekt nie wydarzy się obok firmy. Będą pytania, warsztaty, decyzje, testy i momenty, kiedy trzeba odłożyć bieżące sprawy, żeby nie zbudować systemu „w próżni". Z mojego doświadczenia największym ryzykiem jest nie brak pieniędzy, tylko brak czasu kluczowych osób — bo wtedy projekt zaczyna zwalniać, a po obu stronach rośnie frustracja.

Pierwsze rozmowy z software house'em mogą być stresujące, jeśli nie macie doświadczeń w IT. Warto pamiętać, że nie musicie przychodzić z gotowym rozwiązaniem. Waszym zadaniem jest dobrze opisać problem i kontekst biznesowy. Zadaniem partnera jest pomóc to poukładać i zaproponować podejście.

Zamiast pytać „ile kosztuje system do zarządzania zamówieniami", lepiej rozmawiać o tym, jak firma pracuje i gdzie boli. Dobre pytania do potencjalnego partnera dotyczą sposobu współpracy: jak będziecie poznawać nasze procesy, jak wygląda etapowanie prac, jak często będziemy podejmować decyzje, jak radzicie sobie ze zmianami w trakcie projektu i jak dbacie o to, żebyśmy nie utknęli w nieskończonym doprecyzowywaniu.

Warto też słuchać, czy po drugiej stronie padają pytania o cele biznesowe, a nie tylko o funkcje. Jeśli ktoś od razu składa obietnice bez zrozumienia waszej sytuacji, to powinien zapalić się sygnał ostrzegawczy. Dobry partner bywa „niewygodny" na początku — bo dopytuje, kwestionuje, pokazuje ryzyka. W długim terminie to właśnie chroni firmę przed kosztownymi błędami.

Jeśli miałabym wskazać jedną zasadę, która najbardziej ułatwia współpracę, to jest nią opisywanie problemów, nie rozwiązań. „Tracimy czas, bo trzy osoby przepisują dane" jest świetnym startem. „Zróbcie nam ekran z trzema tabelkami" — już niekoniecznie, bo może blokować lepsze pomysły.

Nawet najlepszy system nie zadziała, jeśli ludzie nie będą chcieli z niego korzystać. A opór przed zmianą jest naturalny — zwłaszcza gdy pracownicy nie wiedzą, co ta zmiana oznacza dla nich. W projektach IT często pojawia się cicha obawa: „czy system ma mnie zastąpić?" albo „czy teraz będą mnie rozliczać z każdej minuty?". Jeśli firma nie zadba o komunikację, plotki zrobią to za nią.

Dlatego przygotowanie zespołu warto zacząć wcześnie i prosto: po co to robimy, co to ma usprawnić, czego nie zmieniamy, czego jeszcze nie wiemy i kiedy będziemy wiedzieć. Szczerość jest lepsza niż „marketing" — ludzie i tak zobaczą, że projekt ma etapy i że pewne rzeczy wyjdą w praniu. Ważne, by czuli, że firma panuje nad kierunkiem i że ich perspektywa jest brana pod uwagę.

Bardzo pomaga znalezienie „ambasadorów zmiany". To nie muszą być managerowie. Często to osoby, które znają proces najlepiej, mają autorytet w zespole i potrafią konstruktywnie mówić o problemach. Jeśli takie osoby zostaną włączone w testy i konsultacje, później naturalnie pomagają reszcie zespołu przejść przez wdrożenie — i obniżają ryzyko, że system będzie odbierany jako coś „narzuconego z góry".

Dobrze też pamiętać, że wdrożenie to nie dzień „włączenia systemu". To okres uczenia się, poprawiania i dostosowywania. Jeśli firma zaplanuje czas na wsparcie po starcie (pytania, drobne korekty, szkolenia), akceptacja rośnie. Jeśli zostawi ludzi samych, nawet najlepsze rozwiązanie zacznie być omijane „na skróty".

Pierwszy duży projekt IT to moment przełomowy — bo dotyka fundamentów działania firmy: procesów, odpowiedzialności, przepływu informacji. Dobre przygotowanie nie polega na tym, że macie perfekcyjny dokument i znacie wszystkie odpowiedzi. Polega na tym, że wiecie, po co to robicie, macie właściwe osoby przy stole i jesteście gotowi podejmować decyzje.

Jeśli miałabym ująć to najprościej: przygotowanie to połowa sukcesu. Zwraca się w postaci sprawniejszej współpracy, mniejszej liczby zmian „w panice" w trakcie prac i szybszego dojścia do efektów, które realnie wspierają biznes.

Jeżeli planujecie pierwszy większy projekt IT i chcecie spokojnie omówić kierunek, ryzyka oraz realistyczne oczekiwania, zapraszam do kontaktu z aveneo. Taka rozmowa jest niewiążąca — często już na tym etapie pomaga poukładać priorytety i podjąć lepsze decyzje przed rozpoczęciem inwestycji.

— Milena