A DIMOP Plusz digitalizációs pályázat 2026 kapcsán már a pályázati kiírás véglegesítése előtt érdemes előkészíteni a fejlesztési projektet. Nemcsak azért, hogy gyorsabban lehessen reagálni a megjelenő feltételekre, hanem azért is, mert egy digitális fejlesztés akkor tervezhető és értékelhető, ha pontosan leírható: milyen problémát old meg, kik használják, milyen rendszerkapcsolatokra van szükség, és milyen eredmény jön létre.

A DIMOP Plusz-1.2.6/C-26, a kkv-k digitális infrastruktúráját és transzformációját támogató felhívás budapesti, III. körének tervezete 2026. március 15-ig társadalmi egyeztetésen szerepelt. A pályázati környezet azonban változhat, ezért a végleges felhívás és a kapcsolódó dokumentumok ellenőrzése szükséges. A hivatalos társadalmi egyeztetés oldalán követheted az aktuális információkat.

Az első lépés: a jelenlegi működés feltérképezése

A fejlesztési projektet nem a választott technológiával érdemes kezdeni. Először azt kell rögzíteni, hogyan működik most az érintett folyamat.

Egy tipikus kkv-nál ugyanaz az információ több helyen is megjelenhet: Excel-fájlokban, e-mailekben, számlázóprogramban, belső üzenetekben vagy papíralapú dokumentumokban. Ilyenkor nem elég azt leírni, hogy „egy központi rendszerre van szükség”. A pályázati és műszaki előkészítéshez ennél konkrétabb kép kell.

Érdemes folyamatonként végigvenni például:

  • honnan érkezik az adat;
  • ki rögzíti vagy ellenőrzi;
  • milyen döntési pontok vannak;
  • milyen dokumentumok keletkeznek;
  • mely adatokat kell más rendszerbe továbbítani;
  • hol fordul elő ismételt kézi adatbevitel;
  • mi történik kivételes esetben;
  • milyen riportokra és visszakereshetőségre van szükség.

Tegyük fel, hogy egy gyártó cég ajánlatkérésekből indít projekteket. Ilyenkor nemcsak az a kérdés, hogy kell-e „gyártásirányítási szoftver”, hanem az is, hogyan lesz az ajánlatból megrendelés, hogyan változik a verzió, honnan érkezik a készletinformáció, és mikor kerül adat a műhelyhez.

A Nexus projektben például egységes gyártásirányítási rendszer váltotta fel az Excel-munkafüzetekre épülő működés egy részét. A rendszer verziózott ajánlatokat, projekteket, több tárhelyes készletet és műhelyi munkaidő-nyilvántartást kezel. Ez jó példa arra, hogy a fejlesztési igény konkrét működési elemekből áll össze, nem egy általános szoftverigényből.

A fejlesztési cél legyen üzleti probléma megoldása

A „digitalizálni szeretnénk a cég működését” fontos irány, de önmagában nem projektcél. A célokat olyan formában érdemes megfogalmazni, amelyből a fejlesztési tartalom és a projekt lezárásakor vizsgálható eredmény is levezethető.

Használható célmeghatározások lehetnek például:

  • az ajánlatok, projektek és kapcsolódó dokumentumok egy rendszerben kezelhetők;
  • az ügyfél egy saját felületen látja a projekt állapotát és dokumentumait;
  • az érdeklődői adatokból automatikusan létrejön egy strukturált ügyfélrekord;
  • a belső jóváhagyási folyamat nyomon követhető;
  • a rendszer szerepkörök szerint teszi elérhetővé az adatokat;
  • az ismétlődő adatátadások szabályok alapján, automatikusan történnek.

A cél nem feltétlenül egyetlen nagy rendszer bevezetése. Lehet weboldal, ügyfélportál, operatív webalkalmazás, belső automatizáció vagy ezek együttese. A weboldal-készítés és a webalkalmazás-készítés eltérő fejlesztési tartalmat jelent, ezért előbb a működési feladatokat kell tisztázni, és csak utána a technikai megoldást.

Írd le, kik használják majd a rendszert

Egy digitális fejlesztésnél az érintett felhasználók köre legalább olyan fontos, mint maga a funkciólista. Más igényei vannak a cégvezetőnek, az értékesítőnek, a pénzügyi munkatársnak, a műhelyben dolgozónak és az ügyfélnek.

Az előkészítés során érdemes meghatározni:

  • milyen felhasználói szerepkörök lesznek;
  • ki milyen adatokat láthat és módosíthat;
  • mely feladatokat végeznek asztali gépen és melyeket mobilon;
  • szükséges-e külső felhasználói hozzáférés;
  • milyen értesítésekre van szükség;
  • hol kell jóváhagyás vagy vezetői kontroll;
  • milyen oktatási és bevezetési igény várható.

Egy ügyfélportál például nem pusztán egy új weboldal. Meg kell határozni, hogyan azonosítja magát az ügyfél, milyen dokumentumokat lát, milyen állapotokat követhet, és hogyan kommunikál a céggel. Az ügyfélportál-fejlesztés ezért önálló üzleti rendszerként kezelendő, nem egyszerű tartalmi aloldalként.

Vedd számba a kapcsolódó rendszereket

A fejlesztés gyakran nem önállóan működik. Kapcsolódhat számlázóhoz, könyvelési rendszerhez, CRM-hez, webshophoz, levelezéshez, naptárhoz, készletnyilvántartáshoz vagy külső adatforráshoz.

Minden kapcsolódó rendszer esetében tisztázd:

  • milyen adatot kell átadni;
  • melyik rendszer legyen az adat elsődleges forrása;
  • milyen gyakran történjen az adatátadás;
  • van-e elérhető API vagy más technikai csatlakozási lehetőség;
  • mi történjen hiba esetén;
  • ki ellenőrzi és javítja az eltéréseket.

Ezeket a kérdéseket nem érdemes a fejlesztés végére hagyni. Egy rendszerkapcsolat jelentősen befolyásolhatja a műszaki tartalmat, a fejlesztési sorrendet, a tesztelést és a költségtervet is.

Az irodai automatizáció tervezésénél különösen fontos felmérni az ismétlődő adatmozgatásokat és döntési szabályokat. Az automatizáció ugyanis csak akkor működik megbízhatóan, ha a bemeneti adatok, a kivételek és a felelősségi körök is tiszták.

A költségtervhez előbb műszaki tartalom kell

Egy „weboldal vagy szoftver kell” típusú leírásból nem lehet megalapozott fejlesztési költséget készíteni. Ugyanaz a megnevezés nagyon eltérő tartalmú projekteket takarhat.

Egy weboldal lehet egyszerű bemutatkozó oldal, többnyelvű katalógus, ajánlatkérő felület vagy külső rendszerekhez kapcsolódó értékesítési csatorna. Egy szoftver lehet néhány adatlapból álló belső eszköz, de lehet több szerepkörös, dokumentumkezelő, riportáló és integrált üzleti alkalmazás is.

A költségterv előkészítéséhez legalább az alábbiakat célszerű rögzíteni:

  • a fejlesztendő modulok és funkciók;
  • a felhasználói szerepkörök;
  • a szükséges rendszerkapcsolatok;
  • a migrálandó adatok és dokumentumok;
  • a jogosultsági és biztonsági elvárások;
  • a tesztelés és bevezetés feladatai;
  • az üzemeltetéshez szükséges technikai elemek;
  • a szállító és a megrendelő felelősségei.

Hasznos lehet a kézi munkára fordított idő költségét is külön megvizsgálni. A kézi munka kalkulátor segíthet annak becslésében, hogy egy ismétlődő manuális folyamat milyen éves ráfordítást jelent. Ez nem helyettesíti a fejlesztési árajánlatot, de segít az üzleti probléma súlyának bemutatásában.

A projektkimenetek legyenek ellenőrizhetők

A projekt végére ne csak az szerepeljen, hogy „elkészül a rendszer”. A kimeneteket úgy érdemes meghatározni, hogy egyértelműen ellenőrizhető legyen, mi valósult meg.

Ilyen kimenet lehet például:

  • működő, jogosultságkezelt webalkalmazás;
  • konfigurált ügyfél- vagy partnerportál;
  • dokumentált rendszerkapcsolat;
  • importált és ellenőrzött alapadat-állomány;
  • elkészült adminisztrációs felület;
  • tesztelt automatizált munkafolyamat;
  • felhasználói dokumentáció és oktatási anyag;
  • átadott tesztelési és bevezetési jegyzőkönyv.

A mérhetőség itt nem feltétlenül konkrét pénzügyi vagy százalékos eredményt jelent. Azt kell tudni megmutatni, hogy a projekt milyen funkcionális és működési állapotot hoz létre. Az eredményeket természetesen mindig a végleges pályázati felhívásban szereplő követelményekhez kell igazítani.

A szállítói feladatokat is tisztázd előre

A fejlesztő vagy szállító kiválasztása előtt érdemes leírni, mit vársz tőle, és mi marad a saját szervezet feladata. Ide tartozhat a folyamatfelmérés, a specifikáció, a tervezés, a fejlesztés, az integráció, a tesztelés, az adatbetöltés, az oktatás, az élesítés és az utókövetés.

Különösen fontos tisztázni, hogy ki biztosítja:

  • a hozzáféréseket és külső szolgáltatói információkat;
  • a tisztított és átadható adatokat;
  • a döntést a funkcionális kérdésekben;
  • a tesztelők és kulcsfelhasználók idejét;
  • a szükséges jogi, adatvédelmi vagy információbiztonsági egyeztetést.

A fejlesztési projekt akkor lesz előkészíthető, ha a szállító nemcsak egy képernyőképet vagy prezentációt mutat, hanem a tervezett működést is meg lehet vizsgálni. A Netlin Group ajánlat előtt működő demót mutat a tervezett rendszerből, így már a döntés előtt látható, milyen folyamatot és felhasználói működést fed le a megoldás.

Mit készíts elő most?

A végleges pályázati feltételek megjelenéséig érdemes összeállítani egy rövid, de konkrét projekt-előkészítő anyagot. Tartalmazza:

  1. a jelenlegi folyamatok leírását és a fő problémákat;
  2. a fejlesztés üzleti célját;
  3. az érintett felhasználói szerepköröket;
  4. a szükséges funkciók és rendszerkapcsolatok listáját;
  5. a várható projektkimeneteket;
  6. a szállítói feladatok és felelősségek vázlatát;
  7. a költségterv elkészítéséhez szükséges műszaki tartalmat.

Így nem egy általános digitális fejlesztési ötlettel indulsz, hanem egy olyan projekttel, amelyről a pályázati, műszaki és üzleti szempontok alapján is lehet egyeztetni. Ha már körvonalazódik, milyen rendszerre van szükséged, a DIMOP Plusz fejlesztésekhez kapcsolódó kivitelezési lehetőségekről érdemes szakmai egyeztetést kérni. A következő lépés a folyamatok és a tervezett műszaki tartalom közös áttekintése lehet a kapcsolat oldalon.