Achiziția de servicii de modernizare COBOL nu seamănă cu niciun alt fel de achiziție de lucrări software. Sistemul în cauză rulează de treizeci sau patruzeci de ani, nimeni dintre angajații actuali nu îl înțelege complet, iar consecințele unei greșeli se măsoară în raportări de reglementare ratate, nu în sprinturi pierdute. Între timp, propunerile de pe birou promit toate același rezultat, la prețuri extrem de diferite.

Ghidul acesta arată ce conține de fapt un angajament serios, prin ce diferă categoriile de furnizori și ce întrebări despart o ofertă construită pe dovezi de una construită pe optimism. Pornește de la ipoteza că dumneavoastră veți fi persoana care va trebui să apere decizia ulterior.

Ce trebuie să căutați: o propunere credibilă de modernizare COBOL include descoperirea, proiectarea arhitecturii țintă, migrarea datelor, conversia sau rehostingul, un program de testare bazat pe comparație, o rulare în paralel, planificarea trecerii în producție și transferul de cunoștințe. Dacă o ofertă cotează doar conversia codului, nu este un plan de program, ci sfertul lui cel mai ieftin.

Ce includ de fapt serviciile de modernizare COBOL

Cereți o propunere de la trei furnizori și veți primi trei definiții diferite ale ariei de acoperire. Uniformizarea acelei liste înainte de a compara prețurile este cel mai util lucru pe care îl puteți face, pentru că o ofertă care omite jumătate din muncă va arăta întotdeauna mai bine pe pagina de sinteză.

Descoperirea și analiza vin primele. Furnizorul parcurge întregul parc aplicativ, construiește hărțile de dependențe și de proveniență a datelor, identifică codul mort și produce un inventar de programe, copybook-uri, lanțuri de joburi și obiecte de bază de date. Faza aceasta trebuie să semnaleze și construcțiile care determină costul: module Assembler, tipare tranzacționale neobișnuite, structuri de înregistrare variante și tot ce compilatorul tolerează de decenii.

Arhitectura țintă urmează. Cineva trebuie să decidă ce devine sistemul: o sarcină COBOL rehostată, o bază de cod convertită într-un limbaj modern, un set de servicii sau o combinație eșalonată în timp. Decizia aceasta stă înaintea începerii conversiei și trebuie documentată cu raționamentul la vedere, nu doar afirmată.

Migrarea datelor acoperă proiectarea schemei, extragerea, conversia și reconcilierea. Formatele de date de pe mainframe poartă un înțeles pe care o schemă relațională nu îl poate exprima direct, așa că munca este analitică, nu mecanică.

Conversia codului sau rehostingul este partea pe care toată lumea o privește și reprezintă de regulă o minoritate din efortul total. Uneltele de migrare a mainframe-ului preiau mult din ea, dar nu tot, iar locul exact în care trece limita determină efortul din celelalte faze.

Fazele pe care cumpărătorii le taie cel mai des

Testarea și comparația sunt locul unde se duc banii. Un program serios construiește un banc care rulează sistemul vechi și cel nou pe intrări identice și compară ieșirile câmp cu câmp, apoi tratează fiecare diferență până când este fie corectată, fie acceptată formal. Este un proiect software în sine și trebuie cotat ca atare.

Rularea în paralel și trecerea în producție înseamnă operarea ambelor sisteme pe o perioadă definită, cu volume reale de producție, iar apoi comutarea cu un plan de revenire testat. Programele care sar peste etapa aceasta ca să câștige timp sunt cele care ajung în studii de caz din motive greșite.

Transferul de cunoștințe și suportul încheie angajamentul. Echipa dumneavoastră trebuie să poată opera și modifica rezultatul fără furnizor. Dacă acest lucru nu este un livrabil explicit, cu criterii de acceptanță, nu ați cumpărat o modernizare, ci o dependență.

Cele trei tipuri de furnizori și punctele forte ale fiecăruia

Piața se împarte în trei grupuri cu puncte forte cu adevărat diferite, iar alegerea potrivită depinde mai mult de parcul dumneavoastră decât de vreun clasament.

Producătorii de unelte și partenerii lor vin cu conversie automată sau cu o platformă de rehosting. Tehnologia lor este de obicei matură, iar debitul de conversie chiar impresionant. Aspectul de cântărit este alinierea intereselor: interesul lor comercial este să maximizeze proporția de muncă realizată de produsul propriu, ceea ce nu coincide întotdeauna cu o bază de cod pe care o veți întreține cu plăcere. În plus, vă leagă producția de mediul lor de execuție, iar dependența aceasta merită cotată.

Integratorii globali de sisteme aduc anvergură, guvernanță de program și capacitatea de a acoperi un efort de mai mulți ani. Dacă parcul înseamnă milioane de linii răspândite pe mai multe direcții de business, capacitatea aceasta contează și puțini alții o pot furniza. Compensația se plătește în structura de costuri și în distanța dintre oamenii care au scris propunerea și cei care vor face treaba. Întrebați explicit cine formează echipa, unde se află acei oameni și ce experiență au.

Firmele de inginerie specializate sunt mai mici, lucrează cu oameni seniori de la un capăt la altul și sunt de regulă neutre față de unelte, pentru că nu au un produs de vândut. Se potrivesc parcurilor de câteva sute de mii de linii, programelor eșalonate și situațiilor în care greutatea stă în logica de business, nu în volum. Nu pot acoperi un program de două sute de oameni și ar trebui să spună asta.

Nu există un răspuns universal corect. Există un răspuns corect pentru un parc anume, iar orice furnizor care pretinde că modelul lui se potrivește oricărei situații vă spune ceva util despre felul în care vinde.

Întrebările care demască o ofertă slabă

Chestionarele de achiziție scot rar la suprafață ceea ce contează. Întrebările acestea, da.

„Convertiți cel mai prost modul al nostru și arătați-ne rezultatul." Alegeți programul pe care toată lumea îl ocolește, ideal unul care apelează Assembler și folosește o înregistrare variantă pe mai multe niveluri. Cereți să vedeți codul generat, nu un rezumat al lui. Un furnizor convins de abordarea lui va face asta pentru un onorariu de analiză fix și modest. Ezitarea este ea însăși un răspuns.

„Cum tratați aritmetica zecimală și ordinea de sortare?" Câmpurile zecimale împachetate și secvența de colaționare a mainframe-ului produc amândouă diferențe care apar doar în rezultatele financiare și în ordinea rapoartelor. Răspunsurile trebuie să fie concrete și tehnice. Vagul aici prevestește o fază dificilă de acceptanță de către utilizatori.

„Ce anume intră în aria de testare și cine scrie bancul de comparație?" Căutați un livrabil cu nume, o estimare de efort și claritate privind cine furnizează date reprezentative pentru producție. Dacă testarea este descrisă ca un procent din construcție, furnizorul ghicește.

„Ce se întâmplă cu diferențele pe care nu le puteți explica?" Orice program găsește ieșiri care diferă fără ca cineva să le poată justifica. Furnizorii buni descriu un proces de triere cu aprobare din partea businessului. Cei care spun că așa ceva nu se întâmplă fie nu au dus niciodată un program până la capăt, fie nu sunt sinceri.

„Cine deține codul sursă rezultat și putem pleca?" Răspunsul ar trebui să fie că totul vă aparține fără sarcini și că nu este nevoie de nicio licență de execuție pentru a continua operarea. Dacă vreo parte a răspunsului implică licențierea continuă a unui strat proprietar, lămuriți exact ce se întâmplă cu sistemul de producție dacă încetați să plătiți.

„Arătați-ne un program care a mers prost și ce ați schimbat după." Orice organizație care a făcut mai mult de câteva astfel de proiecte are un asemenea caz. Răspunsul vă spune dacă vorbiți cu ingineri sau cu o funcție de vânzări.

Cum se tarifează serviciile de modernizare COBOL

Modelele de preț diferă, iar fiecare distribuie riscul altfel. Înțelegerea acelei distribuții contează mai mult decât cifra de pe copertă.

Regia este modelul cel mai onest pentru o muncă cu necunoscute reale și cel mai inconfortabil pentru un consiliu de administrație. Se potrivește descoperirii, care ar trebui aproape întotdeauna achiziționată separat și prima, tocmai pentru ca restul să poată fi cotat pe dovezi, nu pe presupuneri.

Prețul fix pe modul sau pe mia de linii este obișnuit pentru conversie și rezonabil odată ce descoperirea a stabilit ce conțin modulele. Citiți cu atenție excluderile. Prețurile acestea presupun de obicei cod aflat într-o bandă de complexitate definită, iar tot ce iese din ea se recotează individual, și acolo locuiește varianța.

Prețul legat de rezultat, în care plata depinde de echivalența funcțională acceptată, aliniază bine interesele, dar cere criterii de acceptanță suficient de precise pentru a putea tranșa un dezacord. Definirea corectă a acelor criterii merită efortul.

Fiți sceptici față de un preț ferm pentru întregul program, cotat înainte de descoperire. Nu este o dovadă de încredere. Ori este calculat cu suficientă rezervă cât să acopere cel mai rău scenariu, și atunci plătiți pentru un risc care s-ar putea să nu se materializeze, ori este calculat optimist și va reveni sub formă de cereri de modificare de îndată ce ies la iveală modulele dificile. Niciuna dintre variante nu este o afacere bună.

Cât despre discounturi, piața aceasta nu funcționează chiar așa. Reducerile semnificative vin din îngustarea ariei, din eșalonarea programului astfel încât fazele următoare să profite de ce a învățat prima, sau din retragerea codului pe care descoperirea îl arată nefolosit. Un furnizor care își taie prețul substanțial fără să schimbe aria v-a spus tocmai că prima cifră era arbitrară. Ghidul nostru de costuri și termene pentru migrarea COBOL descompune unde se duce bugetul cu adevărat.

Clauze contractuale pe care merită să insistați

Câteva clauze protejează rezultatul mai bine decât orice cantitate de guvernanță.

Insistați asupra proprietății depline și negrevate asupra întregului cod sursă livrat, a schemelor, a scripturilor și a activelor de testare, inclusiv bancul de comparație. Bancul acela este un activ pe care îl veți folosi ani la rând.

Definiți acceptanța drept echivalență funcțională demonstrată pe seturi de date convenite, nu drept livrare de cod. Distincția dintre „conversia este completă" și „ieșirile coincid" este întregul proiect.

Cereți o structură pe etape, cu puncte reale de ieșire. Un program împărțit în descoperire, pilot, conversie eșalonată și trecere în producție vă permite să vă opriți după oricare fază cu ceva de valoare în mână. Un angajament monolitic unic nu vă permite asta.

Nominalizați oamenii-cheie în contract și includeți o clauză privind înlocuirea. Diferența dintre echipa care a prezentat și echipa care ajunge efectiv este cea mai frecventă nemulțumire de pe piața aceasta.

În fine, faceți din transferul de cunoștințe un livrabil cu propriile criterii de acceptanță, dovedit prin faptul că echipa dumneavoastră execută o modificare reală fără ajutor. Altfel devine un set de slide-uri livrat în ultima săptămână.

Vorbiți cu ingineri, nu cu revânzători

Mecanik lucrează la programe de modernizare COBOL și de migrare COBOL ca firmă de inginerie independentă. Nu revindem o platformă de conversie, așa că recomandarea noastră privind uneltele reflectă ce are nevoie codul dumneavoastră, nu ce licențiem noi.

Începem cu descoperirea și cu un pilot plătit pe cel mai dificil modul al dumneavoastră, pentru că asta produce o estimare ancorată în codul real, nu într-o medie de industrie. De acolo putem converti, putem rehosta sau vă putem spune că deocamdată niciuna dintre variante nu se justifică, ceea ce uneori este răspunsul corect. Paginile noastre despre serviciul de migrare COBOL detaliază fazele, iar ghidul nostru despre strategia de modernizare a mainframe-ului tratează decizia dintre rescriere, refactorizare și schimbare de platformă, care vine înainte.

Spuneți-ne aproximativ cât de mare este parcul și ce forțează calendarul, iar noi vă spunem cum arată un program realist.

De citit și: Migrare din COBOL în Java - Ghid enterprise UK , Migrare COBOL la C#: ghid enterprise UK 2026 , Migrarea COBOL la Python și Migrare de la COBOL la Go: ghid pentru companii UK .

Întrebări frecvente

Ce includ serviciile de modernizare COBOL? Un angajament complet acoperă descoperirea și analiza, proiectarea arhitecturii țintă, migrarea datelor, conversia codului sau rehostingul, un program de testare bazat pe comparație, rularea în paralel, planificarea trecerii în producție și transferul de cunoștințe. Propunerile care cotează doar conversia codului acoperă o minoritate din munca reală.

Cine face migrarea din COBOL către limbaje moderne? O fac trei grupuri: producătorii de unelte împreună cu partenerii lor de implementare, integratorii globali de sisteme și firmele de inginerie specializate independente. Producătorii oferă automatizare matură, integratorii oferă anvergură pentru parcuri foarte mari, iar specialiștii oferă ingineri seniori și neutralitate față de unelte pentru programe medii.

Cum se tarifează proiectele de modernizare COBOL? Modelele obișnuite sunt regia, prețul fix pe modul sau pe mia de linii și prețul legat de rezultat, ancorat în echivalența funcțională. Descoperirea ar trebui achiziționată separat și prima, astfel încât restul să poată fi cotat pe dovezi, nu pe presupuneri.

Să accept un preț ferm înainte de descoperire? De regulă nu. Un preț ferm cotat fără analiză este fie umflat cu o rezervă de care s-ar putea să nu aveți nevoie, fie optimist și sortit să revină ca cereri de modificare. Cumpărați întâi descoperirea, apoi folosiți concluziile ei pentru a obține prețuri ferme pe fazele următoare.

Cum verific dacă un furnizor face față codului meu? Cereți-i să convertească cel mai dificil modul în faza de analiză și să vă arate codul generat. Alegeți ceva care conține apeluri Assembler, structuri de înregistrare variante și aritmetică zecimală împachetată. Ce produce, și cât de repede acceptă, vă spune mai mult decât orice discuție cu o referință.