COBOL-modernizációs szolgáltatást vásárolni nem hasonlít semmilyen más szoftveres beszerzésre. A kérdéses rendszer harminc vagy negyven éve fut, a jelenlegi munkatársak közül senki nem érti teljesen, és a hiba következményeit nem elmaradt sprintekben, hanem elmaradt hatósági jelentésekben mérik. Közben az asztalán fekvő ajánlatok mind ugyanazt az eredményt ígérik, vadul eltérő árakon.
Ez az útmutató végigveszi, mit tartalmaz valójában egy komoly megbízás, miben különböznek egymástól a szállítói típusok, és mely kérdések választják el a bizonyítékokra épülő ajánlatot az optimizmusra épülőtől. Abból indul ki, hogy Önnek kell majd megvédenie a döntést utólag.
Mit keressen: egy hiteles COBOL-modernizációs ajánlat tartalmazza a felmérést, a célarchitektúra tervezését, az adatmigrációt, a konverziót vagy a rehostingot, az összehasonlításon alapuló tesztprogramot, a párhuzamos üzemet, az éles átállás tervezését és a tudásátadást. Ha egy ajánlat csak a kódkonverziót árazza, az nem programterv, hanem annak legolcsóbb negyede.
Mit tartalmaznak valójában a COBOL-modernizációs szolgáltatások
Kérjen ajánlatot három szállítótól, és három különböző hatókör-definíciót fog kapni. A legjobb, amit tehet, hogy még az árak összevetése előtt egységesíti ezt a listát, mert az az ajánlat, amelyik kihagyja a munka felét, az összefoglaló oldalon mindig jobban fog mutatni.
A felmérés és elemzés jön először. A szállító feldolgozza a teljes állományt, felépíti a függőségi és adateredet-térképeket, azonosítja a holt kódot, és leltárt készít a programokról, copybookokról, jobfolyamatokról és adatbázisobjektumokról. Ennek a fázisnak jeleznie kell azokat a szerkezeteket is, amelyek a költséget hajtják: Assembler-modulok, szokatlan tranzakciós minták, variáns rekordszerkezetek és mindaz, amit a fordító évtizedek óta elnéz.
A célarchitektúra következik. Valakinek el kell döntenie, mi lesz a rendszerből: rehostolt COBOL-terhelés, modern nyelvre konvertált kódbázis, szolgáltatások halmaza, vagy ezek időben ütemezett kombinációja. Ez a döntés a konverzió megkezdése elé tartozik, és látható érveléssel dokumentálni kell, nem pusztán kijelenteni.
Az adatmigráció kiterjed a sématervezésre, a kinyerésre, a konverzióra és az egyeztetésre. A nagygépes adatformátumok olyan jelentést hordoznak, amelyet egy relációs séma nem tud közvetlenül kifejezni, ezért ez a munka elemző jellegű, nem gépies.
A kódkonverzió vagy rehosting az a rész, amelyre mindenki figyel, és jellemzően a teljes ráfordítás kisebbik felét teszi ki. A nagygépes migrációs eszközök sokat átvállalnak belőle, de távolról sem mindent, és éppen az dönti el a többi fázis terhét, hogy hol húzódik ez a határ.
A fázisok, amelyeket a megrendelők a leggyakrabban kihúznak
A tesztelés és összehasonlítás viszi el a pénzt. Egy rendes program olyan keretet épít, amely a régi és az új rendszert azonos bemenetekkel futtatja és mezőnként veti össze a kimeneteket, majd addig dolgozza fel az eltéréseket, amíg mindegyik javításra vagy formális elfogadásra nem kerül. Ez önmagában is szoftverprojekt, és így is kell árazni.
A párhuzamos üzem és az éles átállás azt jelenti, hogy mindkét rendszert meghatározott ideig valós termelési mennyiséggel üzemeltetik, majd tesztelt visszaállási tervvel váltanak. Azok a programok, amelyek időnyerés céljából kihagyják ezt a lépést, rossz okból kerülnek be az esettanulmányokba.
A tudásátadás és támogatás zárja a megbízást. Az Ön csapatának a szállító nélkül is üzemeltetnie és módosítania kell tudni az eredményt. Ha ez nem kifejezett, átvételi kritériumokkal ellátott szállítandó, akkor nem modernizációt vásárolt, hanem függőséget.
A három szállítótípus és erősségeik
A piac három csoportra oszlik, amelyek valóban eltérő erősségekkel bírnak, és a helyes választás inkább az Ön állományától függ, mint bármilyen rangsortól.
Az eszközgyártók és partnereik automatizált konverzióval vagy rehosting-platformmal állnak elő. Technológiájuk általában érett, konverziós átbocsátóképességük valóban lenyűgöző. A megfontolandó pont az érdekek illeszkedése: üzleti érdekük az, hogy a termékük által elvégzett munka aránya minél nagyobb legyen, ami nem mindig esik egybe egy olyan kódbázissal, amelyet Ön szívesen karban fog tartani. Ráadásul a termelési környezetét a saját futtatókörnyezetükhöz kötik, és ezt a függőséget érdemes beárazni.
A globális rendszerintegrátorok méretet, programirányítást és több éves erőfeszítés lefedéséhez elegendő kapacitást hoznak. Ha az állomány több üzletágban milliós nagyságrendű sorokat jelent, ez a kapacitás számít, és kevesen tudják biztosítani. A cserébe fizetett ár a költségszerkezet, valamint a távolság az ajánlatot megíró és a munkát ténylegesen elvégző emberek között. Kérdezze meg kifejezetten, kik alkotják a csapatot, hol dolgoznak, és milyen tapasztalattal.
A szakosodott mérnöki cégek kisebbek, végig tapasztalt emberekkel dolgoznak, és rendszerint eszközsemlegesek, mert nincs saját eladni való termékük. Néhány százezer soros állományokhoz, ütemezett programokhoz és olyan helyzetekhez illenek, ahol a nehézséget az üzleti logika jelenti, nem a mennyiség. Kétszáz fős programot nem tudnak lefedni, és ezt meg is kell mondaniuk.
Nincs egyetemesen helyes válasz. Egy adott állományra van helyes válasz, és minden szállító, aki azt állítja, hogy a modellje minden helyzethez illik, hasznos dolgot árul el arról, hogyan értékesít.
Kérdések, amelyek leleplezik a gyenge ajánlatot
A beszerzési kérdőívek ritkán hozzák felszínre a lényeget. Ezek a kérdések igen.
„Konvertálják a legrosszabb modulunkat, és mutassák meg az eredményt." Válassza azt a programot, amelyet mindenki kerül, lehetőleg olyat, amely Assemblert hív és többszintű variáns rekordot használ. Kérje a generált kódot, ne annak összefoglalóját. Az a szállító, aki bízik a megközelítésében, ezt egy rögzített, szerény felmérési díjért megteszi. A vonakodás önmagában is válasz.
„Hogyan kezelik a decimális aritmetikát és a rendezési sorrendet?" A tömörített decimális mezők és a nagygép rendezési sorrendje egyaránt olyan eltéréseket okoznak, amelyek csak a pénzügyi eredményekben és a kimutatások sorrendjében jelennek meg. A válaszoknak konkrétnak és technikainak kell lenniük. A homályosság itt nehéz felhasználói átvételi szakaszt vetít előre.
„Pontosan mi van a teszthatókörben, és ki írja az összehasonlító keretet?" Nevesített szállítandót, ráfordításbecslést és arra vonatkozó tisztázást keres, hogy ki adja a termelést hűen leképező adatokat. Ha a tesztelést a fejlesztés százalékában írják le, a szállító találgat.
„Mi történik azokkal az eltérésekkel, amelyeket nem tudnak megmagyarázni?" Minden program talál olyan kimeneteket, amelyek eltérnek, és senki nem tud számot adni róluk. A jó szállítók üzleti jóváhagyással működő szűrési folyamatot írnak le. Aki azt mondja, hogy ez nála nem fordul elő, az vagy soha nem fejezett be programot, vagy nem őszinte.
„Kié lesz a keletkező forráskód, és el tudunk menni?" A válasznak az kell lennie, hogy minden korlátozás nélkül az Öné, és a további üzemeltetéshez nem kell futtatási licenc. Ha a válasz bármely része egy zárt réteg folyamatos licencelését érinti, tisztázza pontosan, mi történik a termelési rendszerével, ha abbahagyja a fizetést.
„Mutassanak egy programot, amely rosszul sült el, és azt, min változtattak utána." Minden szervezetnek, amely néhánynál többet csinált ezekből, van ilyen esete. A válaszból kiderül, hogy mérnökökkel beszél-e vagy egy értékesítési funkcióval.
Hogyan árazzák a COBOL-modernizációs szolgáltatásokat
Az árazási modellek eltérnek, és mindegyik másképp osztja el a kockázatot. Ennek az elosztásnak a megértése többet ér, mint a címlapon szereplő szám.
Az idő- és anyagalapú elszámolás a legőszintébb modell valódi ismeretlenekkel járó munkára, és a legkényelmetlenebb egy igazgatóság számára. A felméréshez illik, amelyet szinte mindig külön és elsőként érdemes beszerezni, éppen azért, hogy a többi bizonyíték alapján legyen árazható, ne feltételezés alapján.
A modulonkénti vagy ezer soronkénti fix ár a konverziós munkánál bevett, és ésszerű, ha a felmérés már tisztázta, mi van a modulokban. Olvassa el figyelmesen a kizárásokat. Ezek az árak rendszerint egy meghatározott bonyolultsági sávba eső kódot feltételeznek, és minden azon kívüli tétel külön árazódik, itt lakik a szórás.
Az eredményalapú árazás, ahol a fizetés az elfogadott funkcionális egyenértékűséghez kötött, jól hangolja össze az érdekeket, de ahhoz elég pontos átvételi kritériumokat kíván, hogy vita esetén dönteni lehessen. Ezeket a kritériumokat rendesen kidolgozni megéri a ráfordítást.
Legyen szkeptikus a felmérés előtt megadott, a teljes programra vonatkozó kötött árral szemben. Ez nem a magabiztosság jele. Vagy elég tartalékkal kalkulálták a legrosszabb esetre, és akkor olyan kockázatért fizet, amely talán be sem következik, vagy optimistán kalkulálták, és változtatási igények formájában fog visszatérni, amint felszínre kerülnek a nehéz modulok. Egyik sem jó vásár.
Ami a kedvezményeket illeti, ez a piac nem igazán így működik. Az érdemi csökkentés a hatókör szűkítéséből, a program ütemezéséből, hogy a későbbi fázisok hasznot húzzanak az elsőből tanultakból, vagy annak a kódnak a kivezetéséből fakad, amelyről a felmérés kimutatja, hogy már nincs használatban. Az a szállító, aki a hatókör változtatása nélkül jelentősen csökkenti az árát, épp azt közölte, hogy az első szám önkényes volt. A COBOL-migráció költségeiről és ütemezéséről szóló útmutatónk bontja le, hová megy valójában a büdzsé.
Szerződéses feltételek, amelyekhez ragaszkodni érdemes
Néhány kikötés többet tesz az eredmény védelméért, mint bármennyi irányítási réteg.
Ragaszkodjon minden átadott forráskód, séma, szkript és tesztvagyon tehermentes tulajdonjogához, beleértve az összehasonlító keretet is. Az a keret olyan eszköz, amelyet évekig újra fog használni.
Az átvételt bizonyított funkcionális egyenértékűségként határozza meg megállapodott adathalmazokon, ne kódátadásként. A „a konverzió kész" és a „a kimenetek egyeznek" közötti különbség maga a teljes projekt.
Követeljen szakaszos felépítést valódi kilépési pontokkal. Az a program, amely felmérésre, pilotra, ütemezett konverzióra és éles átállásra bomlik, lehetővé teszi, hogy bármelyik fázis után értékes eredménnyel a kezében álljon meg. Egyetlen monolitikus megbízás nem.
Nevezze meg a kulcsembereket a szerződésben, és tegyen bele helyettesítési kikötést. A bemutatkozó csapat és az érkező csapat közötti szakadék a piac leggyakoribb panasza.
Végül tegye a tudásátadást saját átvételi kritériumokkal rendelkező szállítandóvá, amelyet az bizonyít, hogy csapata segítség nélkül végrehajt egy valódi módosítást. Különben diasorozattá válik, amelyet az utolsó héten adnak át.
Beszéljen mérnökökkel, ne viszonteladókkal
A Mecanik független mérnöki cégként dolgozik COBOL-modernizációs és COBOL-migrációs programokon. Nem értékesítünk tovább konverziós platformot, így az eszközökre vonatkozó ajánlásunk azt tükrözi, mire van szüksége a kódbázisának, nem azt, amire licencünk van.
Felméréssel és a legnehezebb modulján végzett, fizetett pilottal kezdünk, mert ez a valódi kódján alapuló becslést ad, nem iparági átlagot. Innen tudunk konvertálni, rehostolni, vagy azt mondani, hogy jelenleg egyik sem indokolt, ami időnként a helyes válasz. A COBOL-migrációs szolgáltatás oldalaink részletesebben mutatják be a fázisokat, a mainframe-modernizációs stratégiáról szóló útmutatónk pedig az újraírás, az átalakítás és a platformváltás közötti, ezt megelőző döntést járja körül.
Mondja el nagyjából, mekkora az állomány, és mi kényszeríti ki az időzítést, és megmondjuk, hogyan néz ki egy reális program.
Kapcsolódó olvasnivaló: COBOL-Java migráció - Vállalati útmutató (UK) , COBOL-C# migráció: UK vállalati útmutató 2026 , COBOL-Python migráció és COBOL-Go migráció: útmutató UK vállalatoknak .
Gyakran ismételt kérdések
Mit tartalmaznak a COBOL-modernizációs szolgáltatások? Egy teljes megbízás lefedi a felmérést és elemzést, a célarchitektúra tervezését, az adatmigrációt, a kódkonverziót vagy rehostingot, az összehasonlításon alapuló tesztprogramot, a párhuzamos üzemet, az éles átállás tervezését és a tudásátadást. Az olyan ajánlatok, amelyek csak a kódkonverziót árazzák, a tényleges munka kisebbik felét fedik le.
Ki végez COBOL-ról modern nyelvre migrációt? Három csoport: az eszközgyártók és bevezetési partnereik, a globális rendszerintegrátorok, valamint a független, szakosodott mérnöki cégek. Az eszközgyártók érett automatizálást kínálnak, az integrátorok méretet a nagyon nagy állományokhoz, a szakosodott cégek pedig tapasztalt mérnököket és eszközfüggetlenséget a közepes méretű programokhoz.
Hogyan árazzák a COBOL-modernizációs projekteket? Bevett modell az idő- és anyagalapú elszámolás, a modulonkénti vagy ezer soronkénti fix ár, valamint a funkcionális egyenértékűséghez kötött eredményalapú árazás. A felmérést külön és elsőként érdemes beszerezni, hogy a többi bizonyíték alapján legyen árazható, ne feltételezésből.
Elfogadjak fix árat a felmérés előtt? Általában nem. Az elemzés nélkül megadott fix ár vagy olyan tartalékkal van megtömve, amelyre talán nincs is szükség, vagy optimista, és változtatási igények formájában tér vissza. Először a felmérést vásárolja meg, majd annak eredményei alapján kérjen kötött árat a következő fázisokra.
Hogyan ellenőrizhetem, hogy egy szállító elbír a kódbázisommal? Kérje meg, hogy a felmérés során konvertálja a legnehezebb modulját, és mutassa meg a generált eredményt. Válasszon olyat, amely Assembler-hívásokat, variáns rekordszerkezeteket és tömörített decimális aritmetikát tartalmaz. Amit előállít, és hogy milyen készséggel vállalja, többet mond bármelyik referenciabeszélgetésnél.
Hozzászólások