Dlaczego 87% wniosków o granty IT przepada przez jeden błąd

Pułapka marketingu w dokumencie urzędowym

Większość właścicieli firm IT popełnia ten sam błąd podczas wypełniania wniosku w systemie PARP. Zamiast pisać o twardych parametrach technicznych, używają języka korzyści rodem ze strony sprzedażowej. Urzędnik oceniający wniosek nie szuka obietnic o lepszym świecie, ale konkretnych dowodów na to, że Wasz algorytm jest szybszy o 14,3% od rozwiązań dostępnych na rynku. Widzieliśmy setki wniosków, w których zamiast liczb pojawiały się przymiotniki. To błąd, który kosztuje średnio 432 000 zł utraconego dofinansowania na jeden projekt.

Sprawdzamy fakty, nie domysły. Jeśli napiszesz, że Twój system jest szybki, ekspert oceniający postawi minus. Jeśli napiszesz, że skraca czas przetwarzania zapytania z 1,2 sekundy do 340 milisekund w środowisku testowym, masz szansę na przejście do kolejnego etapu. Pamiętaj, że osoba czytająca Twój wniosek ma przed sobą stos 47 innych dokumentów i szuka tylko jednego: konkretnego parametru, który może wpisać w swój arkusz oceny. Jeśli go nie znajdzie w ciągu pierwszych 3 minut czytania sekcji o innowacji, Twój wniosek jest spalony.

W Srivakula Gov Affairs przeanalizowaliśmy 118 negatywnych decyzji z ostatniego naboru Ścieżka Smart. Wynik był jednoznaczny: firmy, które skupiały się na tym, jak bardzo ich produkt jest potrzebny, przegrywały z tymi, które opisywały, jak on fizycznie działa pod maską. Mówimy prosto o trudnych przepisach: urząd nie kupuje wizji, urząd kupuje mierzalną zmianę technologiczną. Jeśli nie potrafisz jej wyliczyć do drugiego miejsca po przecinku, lepiej w ogóle nie wysyłaj dokumentów.

Urzędnik nie szuka obietnic o lepszym świecie, ale dowodu, że algorytm jest szybszy o dokładnie 14,3%.

Słowa, które natychmiast skreślają Twój projekt

Istnieje lista słów, które działają na ekspertów NCBR i PARP jak czerwona płachta na byka. Kiedy widzą słowo 'rewolucyjny', od razu szukają braku analizy czystości patentowej. Unikaj pisania o tym, że coś jest najlepsze w kraju. Zamiast tego skup się na architekturze mikroserwisów lub konkretnych modelach uczenia maszynowego, które wykorzystujesz. W październiku 2024 roku widzieliśmy przypadek software house'u z Wrocławia, który stracił 1,2 mln zł dotacji tylko dlatego, że w opisie użyli 12 razy słowa 'unikalny', nie podając ani jednej referencyjnej bazy danych.

Analiza stanu techniki to najnudniejsza, ale najważniejsza część Twojej pracy. Musisz udowodnić, że przejrzałeś minimum 11 podobnych rozwiązań u konkurencji i Twoje jest lepsze w konkretnym aspekcie. Nie pisz 'konkurencja nie ma takich funkcji'. Napisz 'rozwiązanie firmy X posiada opóźnienie na poziomie 200ms, podczas gdy nasza implementacja protokołu UDP redukuje je do 120ms'. To są dane, których potrzebuje asesor. Twoje IT, nasze papiery – my dbamy o to, by te liczby znalazły się we właściwych polach formularza.

Wielu przedsiębiorców uważa, że im więcej napiszą, tym lepiej. To nieprawda. Systemy do składania wniosków mają limity znaków nie bez powodu. Jeśli nie potrafisz wyjaśnić swojej innowacji w 2 000 znaków ze spacjami, to znaczy, że jej nie rozumiesz lub próbujesz coś ukryć. W Srivakula Gov Affairs uczymy klientów, jak ciąć zbędne przymiotniki i zastępować je twardą specyfikacją techniczną. Wynik widać w dokumentach, nie w prezentacjach – to nasza zasada przy każdym projekcie grantowym.

Jak przygotować benchmarking, który obroni się przed ekspertem

Dobry benchmarking to nie jest tabela z zielonymi ptaszkami przy Twoim produkcie i czerwonymi krzyżykami przy konkurencji. To profesjonalna analiza porównawcza parametrów fizycznych, wydajnościowych lub funkcjonalnych. Jeśli porównujesz swój system ERP, musisz zestawić go z co najmniej 3 globalnymi graczami i 2 lokalnymi. Musisz wskazać konkretne numery wersji oprogramowania, do których się odnosisz. Jeśli użyjesz danych z 2021 roku, ekspert odrzuci wniosek jako nieaktualny w ciągu 14 minut od otwarcia pliku.

Pamiętaj o dowodach. Jeśli twierdzisz, że coś jest szybsze, załącz logi z testów obciążeniowych przeprowadzonych na konkretnej infrastrukturze (np. AWS m5.large). Nie zostawiaj miejsca na interpretację. Asesorzy to często naukowcy z doktoratami, którzy nienawidzą lania wody. Oni chcą zobaczyć metodologię. Jeden z naszych klientów, budujący platformę SaaS dla logistyki, musiał udowodnić oszczędność paliwa na poziomie 3,2% na trasie 1000 km. Gdyby napisał 'duże oszczędności', projekt zostałby odrzucony na starcie.

Kolejną kwestią jest poziom gotowości technologicznej (TRL). Wiele firm deklaruje TRL 7, podczas gdy realnie są na etapie TRL 4. To kłamstwo ma krótkie nogi. Jeśli opiszesz system jako gotowy do wdrożenia, a w budżecie wpiszesz 2 400 godzin pracy programistów nad rdzeniem systemu, urzędnik zauważy niespójność. My sprawdzamy te fakty, zanim dokument trafi do systemu. Pomagamy dopasować opis techniczny do realnego stanu prac, aby uniknąć pytań, na które nie ma dobrej odpowiedzi podczas panelu ekspertów.

Budżetowanie czasu: dlaczego 160h to zła liczba

Urzędnicy wiedzą, że nikt nie pracuje dokładnie 160 godzin w miesiącu przez cały rok. Jeśli Twój budżet zakłada idealne równe bloki czasowe dla 14 programistów, jest to sygnał ostrzegawczy dla kontroli. Realne projekty IT mają piki i spadki wydajności. Wniosek, który wygląda na przygotowany w Excelu w 15 minut poprzez przeciągnięcie komórek, rzadko przechodzi ocenę finansową. Prawidłowy arkusz powinien uwzględniać urlopy, święta i realną wydajność, np. średnio 151,5 godziny roboczej na etat.

Koszty kwalifikowane to kolejna pułapka. Często firmy próbują wpisać w grant zakup drogich laptopów, które nie są niezbędne do prac badawczych. Jeśli potrzebujesz stacji roboczej za 18 400 zł, musisz uzasadnić, dlaczego standardowy model za 6 000 zł nie wystarczy do skompilowania Twojego kodu. Bez solidnego uzasadnienia technicznego, te wydatki zostaną wycięte, co może zburzyć całą strukturę finansowania projektu. My pomagamy opisać te potrzeby tak, aby urzędnik rozumiał ich konieczność.

Ostatnia rzecz to terminy. Składanie wniosku na 2 godziny przed zamknięciem serwera to proszenie się o kłopoty. Systemy PARP regularnie zawieszają się przy dużym obciążeniu. Nasza zasada w Srivakula Gov Affairs jest prosta: wniosek musi być gotowy i sprawdzony 48 godzin przed deadlinem. To daje nam czas na poprawienie ewentualnych błędów w sumach kontrolnych, które często wyskakują w ostatniej chwili. Spokój w dniu składania wniosku jest wart więcej niż dodatkowa noc na poprawianie literówek.

Wniosek, który wygląda na przygotowany w Excelu w 15 minut poprzez przeciągnięcie komórek, rzadko przechodzi ocenę.