Informatikai projektek külföldön: lehetőségek magyar fejlesztőcégeknek és IT-szolgáltatóknak

Egy magyar IT-cég külföldi ügyfélszerzésénél nem elég azt mondani, hogy szoftvert fejleszt vagy rendszereket üzemeltet. A partner azt szeretné érteni, milyen problémát old meg, milyen felelősséget vállal, és hogyan illeszkedik a meglévő működésébe. A projekt pontos leírása a kereskedelmi ajánlatot, a csapat tervezését és az átadást is átláthatóbbá teszi.

Válasszon feladattípust, ne minden technológiát soroljon fel

Egyedi alkalmazás, rendszerintegráció, adatkezelési feladat, tesztelés és üzemeltetés más üzleti ajánlat. A programozási nyelvek felsorolása mellé írjon konkrét teljesítési helyzetet. Milyen rendszert köt össze, milyen folyamatot támogat, vagy milyen üzleti hibát szüntet meg? A partner így nemcsak technikai címkéket, hanem megérthető felhasználási célt lát.

A csapat valós kapacitását mutassa be. Nem mindegy, hogy egyetlen szakember tud egy technológiát, vagy helyettesíthető, több szerepet lefedő csapat áll rendelkezésre. A projektvezetés, az üzleti elemzés és a minőségellenőrzés is időt igényel. A fejlesztésre szabad órák nem azonosak egy teljes projekt minden feladatára rendelkezésre álló kapacitással.

Hol találhat megfelelő ügyfelet?

A vállalati beszállítói csatornák és az Enterprise Europe Network partnerkeresője a tájékozódás eszközei lehetnek. Szűrje külön a közvetlen ügyfelet, a másik fejlesztőcégnek végzett részfeladatot és a hosszú távú szolgáltatási igényt. A szerződő partner szerepe határozza meg, kivel egyeztet az üzleti követelményről és ki fogadja el a munkát.

Intézményi projektek esetén a TED közbeszerzési portál is használható keresési kiindulásként. A hirdetmény címe nem elég az indulási döntéshez. A rendszerkövetelmény, az alkalmasság, a dokumentáció és a teljesítési modell külön vizsgálandó. A külföldi közbeszerzési útmutató ezt a folyamatot részletesebben bemutatja.

A felmérés külön szakmai feladat

Ha az ügyfél csak üzleti célt fogalmaz meg, abból még nem következik egyértelmű fejlesztési terjedelem. Kérdezzen rá a felhasználókra, a rendszerkapcsolatokra, az adatokra és az elfogadás módjára. A bizonytalan követelményt ne alakítsa át hallgatólagos korlátlan vállalássá. Egy előzetes elemzési szakasz feltételeit is lehet külön egyeztetni.

A projektben szereplő feltételezéseket tegye láthatóvá. Például ki biztosítja a hozzáférést, a tesztadatot vagy a külső rendszer leírását? Ha ezek késnek, a fejlesztőcsapat ütemezése is változhat. Az ajánlat pontosabb lesz, ha a határidő nem szakad el a szükséges bemenő feltételektől és a partner együttműködési feladataitól.

Átadás és változáskezelés

A „kész rendszer” kifejezés helyett határozzanak meg ellenőrizhető eredményt. Milyen funkció, dokumentáció és teszteredmény szükséges az elfogadáshoz? Ki vizsgálja meg, és mi a hibajelzés rendje? A fejlesztés közbeni új ötletet különítsék el a már vállalt követelménytől. Mindkettő lehet fontos, de nem ugyanazt jelenti az ár és a határidő szempontjából.

A forráskód, a tárhely, a fiókok és az átadott jogosultságok kezelése legyen rendezett. A megrendelőnek tudnia kell, milyen hozzáférést és milyen használati feltételt kap. Külső komponens vagy licenc esetén a kapcsolódó feltételt is vizsgálni kell. Az üzleti félreértés nem csak a program működéséről szólhat, hanem arról is, ki és hogyan használhatja később.

Adatbiztonság és távoli munkavégzés

A távoli projekt nem jelenti azt, hogy minden adat szabadon küldhető bármelyik eszközön. Tisztázza a hozzáférések, a tesztkörnyezet, a bizalmas információ és a személyes adatok kezelését. Ha a projektben adatfeldolgozói szerep merül fel, a szükséges megállapodást és működési követelményt a tényleges helyzet alapján kell rendezni.

Az üzleti elvárásokhoz igazodó biztonsági vállalást adjon. Ne ígérjen korlátlan rendelkezésre állást vagy minden kockázat kizárását. Legyen ismert, mikor érhető el a csapat, mi számít hibának és mi új fejlesztési igénynek. A munkaidőn kívüli támogatás szervezése és díja külön kérdés lehet, amelyhez tényleges emberi kapacitást kell biztosítani.

Árazás és partnerfüggőség

Fix díj, időalapú elszámolás és mérföldköves megállapodás eltérő kockázatot oszt meg. A választást a követelmény tisztázottságához és az együttműködés módjához igazítsa. Az óradíj önmagában nem mutatja meg a projekt eredményét: a vezetés, az egyeztetés és az utólagos javítás terhe is számít. A költségtervezési cikk ehhez ad további szempontokat.

Ha egy külföldi ügyfél a csapat nagy részét lekötné, mérlegelje a kapacitás felszabadításának és a kapcsolat megszűnésének hatását is. A rendszeres bevétel kedvező lehet, de a szervezeti függést nem szünteti meg. Az ügyfélkör megosztásáról szóló útmutató a hosszabb távú egyensúlyhoz ad gondolkodási keretet.

Közbeszerzési irányú felkészülés

Az E‑Tender előminősítőjében a valós technológiai, szakmai és szervezési kapacitását mutassa be. A projektlehetőség konkrét feltételeit ezután lehet vizsgálni. Az előzetes áttekintés nem pótolja az adott kiírás dokumentációját, és nem ígér megbízást. A cél az, hogy a cég olyan feladatot keressen, amelynek tartalmát és kockázatát is kezelni tudja.

Döntési példa: egy kis fejlesztési feladatból ne legyen korlátlan projekt

A következő történet kitalált. Egy magyar fejlesztőcsapat külföldi szolgáltató vállalkozásnak készítene belső ügyfélkezelési integrációt. Az érdeklődő első levele szerint csak két rendszer összekapcsolására van szükség. A csapat korábbi tapasztalata alapján ezt néhány hét alatt megvalósíthatónak tartja. Az első műszaki megbeszélésen azonban kiderül, hogy nincs egységes adatmodell, az egyik rendszerhez pedig csak részleges hozzáférés áll rendelkezésre. A fejlesztés időtartamát ezért még nem lehet felelősen megígérni.

A csapat először fizetett feltárási szakaszt javasol, előre meghatározott eredménnyel. Ennek része a két rendszer adatainak áttekintése, az elérhető kapcsolódási módok kipróbálása és a nyitott kérdések listája. A feltárás nem rejti el a későbbi fejlesztési árat, hanem megmutatja, mely feltételek mellett lehet azt kiszámítani. A megrendelő megkapja az elkészült összefoglalót, és önállóan dönthet a következő szakaszról. A magyar csapatnak így nem kell bizonytalan műszaki feladatra korlátlan eredménykötelezettséget vállalnia.

A vizsgálatból három külön munkacsomag lesz: az adatmezők rendezése, az adatátadás kialakítása és a hibajelzések kezelése. Mindegyikhez elfogadási példát írnak. A vevő kijelöli azt a munkatársat, aki a tesztadatot és a szakmai választ biztosítja. Külön megállapodnak arról is, hogy az ügyfél oldali késlekedés hogyan érinti az ütemezést. A projektvezető nem csak a fejlesztők idejét foglalja be, hanem a tesztelés és a javítás számára is hagy kapacitást.

A kivitelezés közben a vevő új kimutatást kér. A csapat nem egyszerűen nemet mond, és nem is kezdi el hallgatólagosan. Bemutatja, milyen többletfeladatot jelent az igény, és hogyan módosítaná a költséget vagy az átadást. A megrendelő végül az eredeti integráció elkészülte utánra ütemezi a kimutatást. A változáskezelés így nem akadályozza az együttműködést, hanem segít megőrizni az első szállítható eredményt. A döntés írásban is bekerül a projekt nyilvántartásába.

Az átadáskor a csapat nem csupán egy működő felületet mutat. Átadja a megállapodott dokumentációt, rendezi a hozzáféréseket, és bemutatja, milyen hibákat jelez a rendszer. A későbbi támogatás külön szolgáltatási keretet kap, mert az egyszeri fejlesztési díj nem jelent állandó készenlétet. A példa tanulsága, hogy külföldi IT-megbízásnál az érthető vállalás és a követhető elfogadás versenyelőny lehet. A munkanyelv fontos, de a tiszta felelősségi rend nélkül a jó nyelvtudás sem oldja meg a bizonytalan projektet.