Dig.IT – od diagnozy cyfrowej do transformacji firmy

Zakup systemu ERP, nowej obrabiarki albo zestawu czujników nie jest jeszcze transformacją cyfrową. Zmiana zaczyna się wtedy, gdy dane przestają być przepisywane między arkuszem, kartką i programem, decyzje mogą być podejmowane na podstawie aktualnych informacji, a proces po wdrożeniu działa inaczej niż wcześniej.

Dlatego przygotowanie projektu Dig.IT warto rozpocząć od procesu, a nie od katalogu dostawcy. Najpierw trzeba ustalić, gdzie firma traci czas, materiał, energię lub informację. Dopiero później można zaprojektować docelowy przepływ danych, dobrać oprogramowanie, urządzenia, integracje oraz mierniki potwierdzające rezultat.

1. Aktualny status Dig.IT i znaczenie pilotażu

Na dzień 4 września 2026 r. ARP nie opublikowała dokumentacji nowego konkursu. Na oficjalnej stronie projektu widnieje informacja, że trwają uzgodnienia harmonogramu i zasad kolejnego naboru, planowanego na przełom III i IV kwartału. ARP zastrzega jednocześnie, że pilotaż miał służyć sprawdzeniu instrumentu, a część kryteriów może zostać zmieniona.

W sierpniu 2026 r. Agencja zapowiedziała jeszcze dwa nabory w tym roku, z łączną alokacją 80 mln zł. Nie oznacza to jednak, że można już przyjąć daty, limity lub kryteria nowej edycji. Dopóki nie zostanie opublikowany regulamin, wartości z konkursu 1/2025 są punktem odniesienia, a nie obietnicą przyszłych warunków.

Pilotaż dostarcza za to ważnej informacji o poziomie trudności. Złożono 146 wniosków, 143 poddano ocenie, a pozytywny wynik uzyskało 51 projektów. Oznacza to, że pozytywnie oceniono około 35,7% ocenianych wniosków. Pozostałe 92 odpadły na etapie formalnym lub merytorycznym. Samo posiadanie pomysłu na oprogramowanie i maszynę wyraźnie nie wystarczało.

2. Pierwszy filtr dotyczy firmy, nie technologii

Konkurs pilotażowy nie był programem dla każdego MŚP. Obejmował mikro-, małe i średnie przedsiębiorstwa z całej Polski, ale tylko takie, których główną działalnością było przetwórstwo przemysłowe albo określone usługi produkcyjne. Aktywny kod właściwej działalności musiał być kodem przeważającym w rejestrze, a faktyczne prowadzenie tej działalności należało potwierdzić danymi i dokumentami.

Najważniejsze warunki wejścia w pilotażu przedstawia poniższa tabela. Trzeba je ponownie sprawdzić po ogłoszeniu nowej edycji.

Obszar	Zasada konkursu 1/2025	Praktyczne znaczenie
status przedsiębiorstwa	mikro-, małe lub średnie przedsiębiorstwo	status trzeba liczyć z uwzględnieniem przedsiębiorstw partnerskich i powiązanych
profil działalności	przetwórstwo przemysłowe lub usługi produkcyjne jako działalność przeważająca	sam handel, doradztwo albo zwykłe usługi biurowe nie otwierały dostępu do konkursu
historia działalności	co najmniej 5 pełnych zamkniętych lat obrotowych	nowa firma, nawet z dobrym projektem, nie spełniała warunku
lokalizacja	dokładny adres realizacji w Polsce i prawo do korzystania z niego w okresie projektu oraz trwałości	lokalizacji nie należało pozostawiać jako ogólnego województwa lub planowanego najmu
zdolność finansowa	ROS co najmniej 4%, Quick Ratio od 0,7 do 1,8 i zadłużenie ogólne nie wyższe niż 68%	każdy wskaźnik był warunkiem zero-jedynkowym, bez możliwości poprawy danych dotyczących tego warunku
skala grantu	grant nie większy niż 30% średnich rocznych przychodów netto ze sprzedaży z 3 ostatnich lat	limit 850 tys. zł nie był automatycznie dostępny każdej firmie
specjalizacja	zgodność projektu z co najmniej jedną Krajową Inteligentną Specjalizacją	należało wykazać związek zakresu projektu z treścią KIS, nie tylko wskazać jej numer
pomoc publiczna	pomoc de minimis	przed ustaleniem kwoty trzeba było sprawdzić dostępny limit dla jednego przedsiębiorstwa

Wskaźniki finansowe liczono jako średnią ważoną z trzech lat: ostatni rok miał wagę 0,45, wcześniejszy 0,35, a trzeci 0,20. To ważny detal. Prosta średnia arytmetyczna mogła dać inny wynik i fałszywe poczucie spełnienia kryterium.

3. Cyfryzacja nie polega na przeniesieniu chaosu do programu

Jeżeli firma nie ma uzgodnionych indeksów materiałowych, odpowiedzialności za dane, kolejności operacji i zasad raportowania, nowy system może tylko przyspieszyć obieg błędów. Projekt powinien zmieniać sposób działania procesu, a nie wyłącznie nośnik informacji.

Dobrą logikę projektu można zapisać w jednym ciągu:

problem procesu → przyczyna → dane bazowe → zmiana organizacyjna i technologiczna → integracja → mierzalny rezultat

Przykładowo informacja, że firma chce kupić MES, nie wyjaśnia jeszcze potrzeby inwestycji. Znacznie więcej mówi opis, że planiści układają produkcję w arkuszu, operatorzy raportują wykonanie na papierze, informacje o przestoju docierają pod koniec zmiany, a termin dostawy jest aktualizowany ręcznie w drugim systemie. Dopiero do takiej diagnozy można dobrać rejestrację operacji, integrację z ERP, terminale, pobieranie stanów maszyn i reguły harmonogramowania.

4. Sześć dziedzin transformacji w pilotażu

Projekt musiał obejmować co najmniej jedną z sześciu dziedzin wskazanych w regulaminie. Można było je łączyć, ale każdy element powinien wynikać z realnego problemu przedsiębiorstwa.

Dziedzina	Przykładowa zmiana w firmie produkcyjnej	Słabe, niewystarczające ujęcie
automatyzacja procesów i analityka biznesowa	automatyczne przekazywanie zleceń, raportowanie wykonania i analiza przyczyn przestojów	zakup programu bez opisania, które czynności znikną lub zostaną zautomatyzowane
sztuczna inteligencja i uczenie maszynowe	kontrola jakości obrazu, prognozowanie awarii albo optymalizacja planu na podstawie danych	wpisanie AI do zakresu bez danych, modelu zastosowania i sposobu sprawdzenia wyniku
cyfrowa sprzedaż i kontakt z klientem	konfigurator B2B połączony z wyceną, produkcją i statusem realizacji zamówienia	strona internetowa, reklamy lub kampania w mediach społecznościowych
cyberbezpieczeństwo	ochrona środowiska produkcyjnego i danych oparta na analizie ryzyk, testach i wielowarstwowych zabezpieczeniach	samodzielny zakup podstawowego antywirusa lub zwykłego firewalla
rozwiązania chmurowe	bezpieczna infrastruktura, baza danych albo aplikacja zapewniająca wspólny dostęp i skalowanie procesów	abonament bez określonego procesu, danych, poziomu usług i planu migracji
zarządzanie zasobami	cyfrowe planowanie materiałów, ludzi i maszyn oraz traceability od surowca do wyrobu	elektroniczna lista stanów magazynowych bez powiązania z produkcją i decyzjami

W pilotażu wykluczono rozwiązania marketingu internetowego, w tym narzędzia do pozycjonowania, reklam, content marketingu i kampanii w mediach społecznościowych. Nie kwalifikowały się również arkusze kalkulacyjne, zwykłe pakiety biurowe i systemy operacyjne. Cyfrowa sprzedaż mogła być wspierana, ale musiała dotyczyć procesu zawierania transakcji lub obsługi klienta, a nie promocji.

5. Diagnoza procesu powinna opierać się na danych

Przed rozmową z dostawcą warto przeprowadzić warsztat z osobami, które wykonują proces: produkcją, utrzymaniem ruchu, jakością, logistyką, sprzedażą, finansami i IT. Zarząd często zna skutek problemu, ale nie wszystkie ręczne obejścia stosowane na hali.

Dla każdego procesu należy zebrać co najmniej:

• początek i koniec procesu oraz jego właściciela,
• systemy, maszyny, dokumenty i arkusze wykorzystywane na każdym etapie,
• miejsca ręcznego przepisywania, zatwierdzania i poprawiania danych,
• czas wykonania, kolejki, przestoje, poprawki i odsetek błędów,
• źródło danych oraz informację, kto i kiedy je rejestruje,
• wyjątki obsługiwane poza oficjalnym procesem,
• zagrożenia dla dostępności, poufności i integralności informacji,
• koszty problemu w skali miesiąca lub roku.

Nie każda wartość bazowa musi pochodzić z zaawansowanego systemu. Można ją ustalić z raportów produkcyjnych, kart pracy, reklamacji, historii serwisowej lub pomiaru wykonanego na reprezentatywnej próbie. Ważne, aby metoda była opisana i możliwa do powtórzenia po wdrożeniu.

6. Architektura docelowa pokazuje, czy elementy utworzą jeden system

Lista „ERP, MES, skaner, serwer, maszyna” nie opisuje rozwiązania. Potrzebna jest mapa pokazująca, które dane powstają w danym miejscu, gdzie są przechowywane, w jaki sposób przechodzą między systemami i która informacja jest nadrzędna.

W planie docelowym warto określić:

1. źródło każdego kluczowego rodzaju danych,
2. identyfikatory łączące zamówienie, materiał, partię, operację i wyrób,
3. kierunki oraz częstotliwość wymiany danych między systemami,
4. zakres interfejsów API, konektorów i migracji danych,
5. uprawnienia użytkowników, kopie zapasowe oraz sposób odtworzenia działania,
6. odpowiedzialność dostawców za integrację i testy,
7. scenariusze odbiorowe potwierdzające działanie całego procesu,
8. zasady utrzymania systemu po zakończeniu projektu.

Szczególnie ryzykowna jest integracja kilku dostawców. Jeżeli producent maszyny odpowiada tylko za sterownik, dostawca MES za swój moduł, a integrator ERP za interfejs, w umowach musi być jasno określone, kto odpowiada za rezultat końcowy. Inaczej każdy element może działać osobno, a przepływ danych nadal będzie wymagał ręcznej pracy.

7. Technologia cyfrowa była rdzeniem, a maszyny dodatkiem

W konkursie 1/2025 każdy projekt musiał zawierać komponent obligatoryjny: zakup i wdrożenie gotowej technologii cyfrowej albo zamówienie prac programistycznych prowadzących do jej stworzenia i wdrożenia.

Maszyny, urządzenia, materiały wdrożeniowe oraz szkolenia stanowiły komponent fakultatywny. Jego łączna wartość nie mogła przekroczyć 40% wszystkich kosztów kwalifikowanych. Nie był to więc osobny limit 40% dla maszyn, kolejny dla szkoleń i kolejny dla materiałów.

Komponent	Przykładowe elementy	Najważniejszy warunek pilotażu
obligatoryjny	licencja na technologię cyfrową, dedykowane oprogramowanie, prace programistyczne, integracja i wdrożenie	technologia musiała zostać uruchomiona operacyjnie w firmie
fakultatywny	maszyny i urządzenia, czujniki, czytniki, lokalizatory, okablowanie, szkolenia użytkowników	wszystkie pozycje łącznie maksymalnie 40% kosztów kwalifikowanych i bezpośredni związek z technologią

Warunek dla środków trwałych był bardzo wąski. Maszyna musiała być niezbędna, a zależność od technologii tak bezpośrednia, że wykorzystanie wdrażanej technologii bez tego środka trwałego nie byłoby możliwe. Komputery osobiste, drukarki, smartfony, środki transportu, nieruchomości i infrastruktura o uniwersalnym przeznaczeniu były wykluczone.

8. Przykładowy budżet pokazuje trzy różne ograniczenia

Załóżmy, że firma planuje wdrożyć zintegrowane środowisko CAD/CAM i MES, automatycznie przekazywać programy do urządzeń, zbierać dane z produkcji oraz śledzić partie materiału.

Element	Komponent	Koszt netto
licencje CAD/CAM i MES	obligatoryjny	420 000 zł
integracja z ERP, migracja danych i uruchomienie	obligatoryjny	180 000 zł
dedykowany konektor i prace programistyczne	obligatoryjny	200 000 zł
urządzenie produkcyjne niezbędne do wykorzystania technologii	fakultatywny	350 000 zł
czujniki, czytniki i okablowanie	fakultatywny	70 000 zł
szkolenia użytkowników	fakultatywny	30 000 zł
Razem		1 250 000 zł

Komponent fakultatywny wynosi 450 tys. zł, czyli 36% budżetu kwalifikowanego. Mieści się w historycznym limicie 40%. Przy intensywności 50% potencjalny grant wyniósłby 625 tys. zł, a więc nie przekroczyłby limitu 850 tys. zł.

To nadal nie kończy kalkulacji. Grant 625 tys. zł nie mógł w pilotażu przekraczać 30% średnich rocznych przychodów netto z trzech lat. Firma potrzebowałaby więc średniej co najmniej około 2,084 mln zł. Przy założeniu, że wszystkie pozycje podlegają VAT 23%, musiałaby też przygotować do opłacenia 1 537 500 zł brutto. Grant był wypłacany dopiero po realizacji i zatwierdzeniu wniosku o płatność końcową.

Przykład pokazuje trzy osobne testy: strukturę kosztów, maksymalną intensywność oraz relację grantu do przychodów. Spełnienie jednego nie zastępuje pozostałych.

9. Licencje, SaaS i prawa autorskie wymagają analizy przed wyceną

W pilotażu technologia miała być nowa dla wnioskodawcy. Zakup aktualizacji lub nowej wersji oprogramowania już używanego w firmie był niekwalifikowalny, nawet gdy produkt miał inną nazwę albo był sprzedawany przez innego dostawcę, ale pozostawał funkcjonalnie tożsamy.

Przy gotowym oprogramowaniu należało sprawdzić okres licencji, zakres użytkowników, terytorium, pola eksploatacji, utrzymanie, aktualizacje i możliwość korzystania przez cały okres trwałości. W przypadku usług SaaS, PaaS, IaaS lub CSaaS kwalifikowalność zależała m.in. od ich ujęcia księgowego i okresu wykorzystania. Opłaty przypadające po okresie kwalifikowalności mogły obciążać firmę ze środków własnych, jeżeli rozwiązanie było nadal potrzebne do utrzymania rezultatów.

Przy oprogramowaniu tworzonym na indywidualne zamówienie wykonawca miał przenieść na firmę całość autorskich praw majątkowych. Osobne opłaty licencyjne za korzystanie z tak stworzonego programu były niekwalifikowalne. Nie należało również zakładać, że technologia sfinansowana jako narzędzie transformacji własnej firmy będzie następnie sprzedawana lub licencjonowana klientom.

Już w zapytaniu do dostawcy warto więc rozdzielić:

• cenę licencji i jej okres,
• konfigurację oraz wdrożenie,
• migrację i oczyszczenie danych,
• integracje oraz interfejsy,
• prace programistyczne,
• utrzymanie, aktualizacje i wsparcie,
• prawa do kodu, dokumentacji i rezultatów prac,
• koszty po zakończeniu okresu kwalifikowalności.

10. Cyberbezpieczeństwo powinno wynikać z ryzyka

Cyberbezpieczeństwo nie powinno być dopisywane tylko po to, aby zdobyć punkty. W pilotażu projekt w tej dziedzinie należało oprzeć na analizie potrzeb i ryzyk przedstawionej we wniosku. Wdrożone technologie musiały wynikać z rekomendacji testów penetracyjnych lub audytu bezpieczeństwa i pochodzić od dostawców z główną siedzibą w Unii Europejskiej.

Koszty testów i audytów wykonywanych bezpośrednio przed implementacją oraz po jej zakończeniu mogły być kwalifikowane, jeżeli spełniały warunki dokumentacji. Audyt wykonany wcześniej na potrzeby przygotowania wniosku nie stawał się automatycznie kosztem projektu.

Regulamin odróżniał zaawansowane rozwiązania, takie jak DLP, ochrona przed DDoS, EDR i Endpoint Protection, od podstawowych narzędzi. Samodzielny zakup zwykłego antywirusa, firewalla lub menedżera haseł był wykluczony. Bezpieczeństwo należało projektować jako warstwę całego środowiska: urządzeń, sieci produkcyjnej, tożsamości użytkowników, kopii, danych oraz procedur odtworzenia.

11. Wskaźnik powinien mierzyć zmianę procesu

Liczba zakupionych licencji lub urządzeń potwierdza wykonanie wydatku, ale nie pokazuje efektu transformacji. Dobry wskaźnik opisuje zmianę, którą można porównać przed wdrożeniem i po nim.

Problem	Wskaźnik bazowy	Przykładowy cel	Źródło weryfikacji
ręczne planowanie zleceń	6 godzin pracy planisty dziennie	2 godziny dziennie	rejestr czynności i logi systemu
opóźniona informacja o przestojach	8 godzin do ujęcia zdarzenia w raporcie	poniżej 5 minut	logi maszyn i MES
brak identyfikacji partii	72% operacji z pełną ścieżką danych	100%	raport traceability
straty materiałowe	8,2% masy materiału	6,5%	dokumenty magazynowe i raport produkcyjny
długi czas realizacji	12 dni od przyjęcia do wysyłki	8 dni	ERP i rejestr wysyłek
ręczne przepisywanie danych	11 punktów ponownego wprowadzania	2 punkty	mapa procesu i test odbiorowy

Wartości w tabeli są przykładowe. W rzeczywistym projekcie muszą wynikać z pomiaru i możliwego technicznie rezultatu.

W pilotażu obowiązkowy był również Test Dojrzałości Cyfrowej przed złożeniem wniosku. Test wykonywano ponownie po zakończeniu projektu oraz po każdym roku trzyletniego okresu trwałości. Nie zastępował on jednak diagnozy procesu. Ogólny wynik dojrzałości nie pokaże sam, skąd biorą się przestoje albo ile czasu pochłania ręczne przygotowanie zlecenia.

12. Najpierw kryteria obligatoryjne, później punkty premiujące

W pilotażu kryteria premiujące nie miały minimalnego progu, ale wpływały na miejsce na liście rankingowej. Nie można było ich poprawiać ani uzupełniać po złożeniu wniosku. Maksymalnie można było uzyskać 13 punktów za:

• status mikro- lub małego przedsiębiorstwa – 1 punkt,
• mierzalny wpływ na zieloną i zrównoważoną gospodarkę – 1 punkt,
• przewagę konkurencyjną – do 2 punktów,
• poprawę bezpieczeństwa lub warunków pracy – do 2 punktów,
• dostosowanie stanowiska do potrzeb osoby z niepełnosprawnością – 1 punkt,
• usprawnienie relacji z klientem – 1 punkt,
• zwiększenie cyberbezpieczeństwa – 2 punkty,
• wykorzystanie chmury, dużych zbiorów danych lub sztucznej inteligencji – do 3 punktów.

Nie należy jednak projektować inwestycji jako kolekcji punktów. Sztucznie dodana usługa chmurowa, deklaracja AI bez danych albo ogólne hasło o ekologii może zwiększyć koszt i ryzyko niespójności, nie tworząc wiarygodnej korzyści. Najpierw projekt musi przejść wszystkie kryteria formalne, kosztowe i branżowe. Dopiero później naliczane są punkty premiujące.

13. Harmonogram musi kończyć się działającym procesem

Wdrożenie nie kończy się wraz z wystawieniem faktury. Harmonogram powinien obejmować:

1. przygotowanie środowiska i danych,
2. przeprowadzenie właściwej procedury zakupowej,
3. dostawę licencji, urządzeń i infrastruktury,
4. konfigurację oraz prace programistyczne,
5. migrację i integracje,
6. testy bezpieczeństwa oraz testy techniczne,
7. szkolenia użytkowników,
8. testy odbiorowe całego procesu,
9. uruchomienie operacyjne,
10. pomiar wskaźników i zebranie dokumentów do rozliczenia.

Wyceny przygotowane przed wnioskiem służą uzasadnieniu budżetu, ale nie zawsze zastępują rozeznanie rynku podczas realizacji. W pilotażu rozeznanie zachowywało ważność przez trzy miesiące od otrzymania pierwszej oferty. Wyjątek dla rozwiązania unikatowego wymagał wykazania braku równoważnego zamiennika oraz praw wyłącznych dostawcy. Sam argument o kompatybilności lub wygodzie współpracy z dotychczasową firmą nie był wystarczający.

14. Finansowanie trzeba zaplanować przed złożeniem wniosku

W konkursie 1/2025 grant wynosił od 150 tys. do 850 tys. zł i pokrywał maksymalnie 50% kosztów kwalifikowanych. Pomoc była wypłacana jednorazowo jako refundacja, bez zaliczek i płatności pośrednich. Firma musiała więc wykazać środki pozwalające na prefinansowanie projektu.

Poza wkładem własnym trzeba było pokryć VAT, koszty niekwalifikowane oraz finansowanie pomostowe. Koszty kredytu lub pożyczki na prefinansowanie, prowizje walutowe, koszty zarządzania projektem, przygotowania i rozliczenia wniosku oraz ustanowienia zabezpieczeń były niekwalifikowalne.

Plan płynności powinien pokazywać miesiąc po miesiącu:

• zaliczki i płatności dla dostawców,
• pełną wartość brutto faktur,
• termin odzyskania VAT, jeżeli firmie przysługuje takie prawo,
• dostępne środki własne i limity kredytowe,
• koszty finansowania poza dotacją,
• rezerwę na kurs waluty, wzrost cen i prace dodatkowe,
• termin złożenia i możliwego zatwierdzenia wniosku o płatność końcową.

Sposób obliczenia rzeczywistej luki finansowej opisujemy szerzej w artykule Wkład własny w projekcie unijnym – jak zaplanować finansowanie.

Przykład projektu zakładu obróbki metalu

Firma wykonuje krótkie serie elementów. Konstruktor przygotowuje dokumentację, technolog ręcznie przepisuje dane do programu maszyny, planista układa zlecenia w arkuszu, a informacja o wykonaniu wraca na koniec zmiany. Nie ma jednego numeru łączącego zapytanie, wersję rysunku, partię materiału, program obróbczy i kontrolę jakości.

Słaby projekt zakłada zakup nowego lasera, prasy i programu CAD/CAM. Opis koncentruje się na parametrach urządzeń, ale nie pokazuje przepływu danych ani mierzalnej zmiany.

Dobrze przygotowany projekt obejmuje:

• uporządkowanie indeksów, wersji dokumentacji i marszrut technologicznych,
• integrację CAD/CAM z przyjmowaniem zleceń, planowaniem i raportowaniem produkcji,
• automatyczne przekazywanie programów oraz parametrów do urządzeń,
• zbieranie stanów maszyn, czasów operacji, przyczyn przestojów i danych jakościowych,
• identyfikację materiału oraz partii na kolejnych etapach,
• pulpity dla planisty, produkcji i zarządu oparte na tym samym źródle danych,
• role, uprawnienia, kopie zapasowe i zabezpieczenie sieci produkcyjnej,
• test odbiorowy od przyjęcia zamówienia do potwierdzenia wysyłki.

Maszyna może znaleźć się w takim projekcie tylko wtedy, gdy zasady naboru na to pozwalają i zostanie wykazane jej bezpośrednie, niezbędne powiązanie z technologią cyfrową. To cyfrowy proces jest rdzeniem projektu, a nie uzasadnieniem dopisanym do wcześniej wybranego urządzenia.

Najczęstsze błędy w projektach cyfrowych

Projekt wymaga ponownej analizy, jeżeli firma:

• zaczyna od ofert dostawców, a nie od problemu i danych bazowych,
• utożsamia transformację cyfrową z zakupem maszyny lub programu,
• przenosi niespójny proces do systemu bez uporządkowania danych i odpowiedzialności,
• nie wskazuje, jak systemy i maszyny będą wymieniały informacje,
• wpisuje AI, chmurę albo cyberbezpieczeństwo tylko dla punktów,
• traktuje reklamę internetową jako cyfrową sprzedaż,
• ujmuje aktualizację używanego programu jako nową technologię,
• nie rozdziela licencji, wdrożenia, integracji i późniejszego utrzymania,
• pomija prawa autorskie do dedykowanego oprogramowania,
• przekracza łączny limit komponentu fakultatywnego,
• opisuje maszynę jako powiązaną z systemem, choć technologia może działać bez niej,
• używa liczby zakupionych licencji jako jedynego miernika rezultatu,
• nie planuje testów odbiorowych całego procesu,
• opiera budżet na ofertach, które stracą ważność przed zakupem,
• nie uwzględnia refundacji, VAT i pełnej wartości potrzebnej do prefinansowania,
• przyjmuje parametry pilotażu jako pewne zasady nowego naboru.

Checklista gotowości projektu Dig.IT

1. Firma spełnia warunki podmiotowe wynikające z aktualnej dokumentacji konkursowej.
2. Status MŚP został policzony razem z podmiotami partnerskimi i powiązanymi.
3. Faktyczna działalność produkcyjna lub usługa produkcyjna znajduje potwierdzenie w dokumentach.
4. Lokalizacja projektu jest znana, a firma ma do niej odpowiedni tytuł prawny.
5. Wskaźniki finansowe obliczono dokładnie według wzorów i wag naboru.
6. Dostępny limit pomocy de minimis wystarcza na planowany grant.
7. Proces obecny został rozpisany wraz z czasem, błędami, wyjątkami i źródłami danych.
8. Każdy problem ma wartość bazową i możliwe do powtórzenia źródło pomiaru.
9. Opisano proces docelowy, role użytkowników i zmianę organizacyjną.
10. Przygotowano mapę integracji systemów, maszyn i przepływów danych.
11. Ustalono właściciela każdego rodzaju danych oraz zasady ich jakości.
12. Technologia cyfrowa stanowi rdzeń projektu, a urządzenia jedynie niezbędne uzupełnienie.
13. Wszystkie koszty fakultatywne mieszczą się w limicie określonym w nowym regulaminie.
14. Warunki licencji, SaaS i praw autorskich umożliwiają utrzymanie rezultatów.
15. Cyberbezpieczeństwo wynika z analizy ryzyka i architektury rozwiązania.
16. Wskaźniki mierzą efekt procesu, a nie wyłącznie wykonanie zakupów.
17. Harmonogram obejmuje integrację, migrację, testy, szkolenia i uruchomienie operacyjne.
18. Umowy i zamówienia nie zostaną zawarte przed dopuszczalnym momentem rozpoczęcia.
19. Budżet jest oparty na aktualnych, porównywalnych i technicznie kompletnych wycenach.
20. Firma ma środki na wkład własny, VAT, koszty niekwalifikowane oraz pełne prefinansowanie.
21. Założenia projektu zostaną ponownie porównane z dokumentacją nowego naboru po jej publikacji.

Dobry projekt cyfrowy można przygotować przed ogłoszeniem naboru

Firma nie musi czekać na regulamin, aby zmierzyć proces, uporządkować dane, opisać integracje, ustalić prawa do oprogramowania i przygotować plan finansowania. Te prace pozostaną przydatne nawet wtedy, gdy ARP zmieni progi finansowe, listę załączników albo sposób punktowania.

Nie należy natomiast przed publikacją nowej dokumentacji zamykać budżetu, zawierać wiążących umów ani przyjmować historycznych kryteriów jako obowiązujących. Ostateczny zakres trzeba sprawdzić ponownie w dniu ogłoszenia konkursu.

W FSL Consulting analizujemy projekt cyfrowy od strony procesu, technologii, kwalifikowalności kosztów, kryteriów, harmonogramu i finansowania. Pozwala to ocenić nie tylko możliwość uzyskania dotacji, lecz także to, czy wdrożenie rzeczywiście połączy dane, ludzi i maszyny w działający proces.

Opisz planowaną transformację cyfrową i sprawdź gotowość projektu →