Portfelli ratsionaliseerimine pärast ühinemisi ja omandamisi

Sihtettevõtte arveldussüsteem märgiti integratsiooni töövoo kolmandal nädalal üleliigseks. Omandajal oli oma arveldusplatvorm, ühendatud üksus ei vajaks kahte ja sihtettevõtte süsteem näis dubleerivat funktsionaalsust. See oli kavandatud kuue kuu möödudes pensionile jääma. Viiendal kuul avastas migratsioonimeeskond, et sihtettevõtte arveldussüsteem mitte ainult ei genereerinud arveid, vaid sisaldas neljakümne aasta pikkust jurisdiktsioonipõhist maksuarvutuse loogikat kuuekümne kolmes riigis, mis oli integreeritud COBOL-programmidesse, mida oli haldanud arendajate meeskond, kes kõik olid teisel kuul lahkumispaketid heaks kiitnud. Omandaja arveldusplatvorm haldas kaheksateist riiki. Pensionile jäämise otsus tühistati, arendajate meeskond tuli ümber ehitada erakorraliste lepinguhindadega ja sünergia ajakava pikendati neljateistkümne kuu võrra.

Ratsionaliseerimisotsus tehti selle põhjal, mida süsteem näiliselt tegi. See oleks pidanud tegema selle põhjal, mida süsteem tegelikult tegi. Need on igas rakenduste portfellis erinevad asjad ja kõige erinevamad on need portfellides, mis sisaldavad pärandsüsteeme, millel on aastakümnete pikkune kogunenud äriloogika, dokumenteerimata sõltuvused ja institutsionaalsed teadmised, mis ei eksisteeri kusagil mujal kui koodis.

Miks ühinemised ja omandamised loovad portfelli ratsionaliseerimise imperatiivi

Kahe ettevõtte ühendamisel olete kohe sunnitud mõlema poole rakendusi ratsionaliseerima, et luua ühtne ja konsolideeritud valdusühing. Sellises pingelises keskkonnas määrab süsteemide kiire ühendamise võime uue üksuse tõhusa toimimise kiiruse.

Ratsionaliseerimine ei ole valikuline. Kahel organisatsioonil, mis varem käitasid oma ERP-d, CRM-i, HRMS-i, arveldusplatvormi, aruandluskomplekti ja andmeladu, on nüüd kõike kaks. Paralleelsete süsteemide hooldamise, litsentsimise, infrastruktuuri, toe ja kahe eksemplari (mis lõpuks peaksid saama üheks) käitamise tegevuskulude kogusumma on peamine kulusünergiate põhjus, mis õigustas omandamishinda. Integratsiooni ajakavad on tehingumudelisse sisse kirjutatud. Sünergia realiseerimist jälgib juhatus. Ajakavast kinnipidamata jätmine ratsionaliseerimisel ei tähenda mitte ainult finantseesmärgi saavutamata jätmist, vaid seab kahtluse alla tehingu strateegilise loogika.

Enamik ettevõtteid kipub aja jooksul koguma suure infotehnoloogia rakenduste portfelli, eriti kui nad kasvavad ühinemiste ja omandamiste kaudu ning ei integreeri tegevusi ja varasid pärast iga tehingut täielikult. Terviklikult vaadates ei pruugi paljud neist rakendustest olla kooskõlas ettevõtte üldise ühinemis- ja omandamisstrateegiaga; need loodi konkreetse ajahetke lahendustena ega toeta tingimata tehingujärgseid, ettevõtte tasemel äri- ja organisatsioonilisi eesmärke.

Probleemi ulatus süveneb iga järgneva omandamisega. Organisatsioon, mis on kasvanud järjestikuste omandamiste kaudu ilma range ühinemisjärgse portfelli integreerimiseta, kannab iga tehingu akumuleerunud tehnilist võlga, mida ta pole täielikult seedinud. Keskmine suurettevõte haldab üle 370 SaaS-rakenduse. 25–30 protsenti neist litsentsidest on kasutamata või oluliselt alakasutatud. Organisatsioonid jätavad igal aastal hinnanguliselt 19.8 miljonit dollarit kasutamata litsentse. Lisage sellele pärandrakenduste kiht, COBOL-programmid, patenteeritud ERP-kohandused ja suurarvutite partiisüsteemid, mis SaaS-litsentsiauditites ei kajastu, ja portfell, millega ratsionaliseerimine peab tegelema, on oluliselt suurem, kui SaaS-i inventuur näitab.

Kolm lünka, mis põhjustavad ratsionaliseerimise ebaõnnestumisi

Ratsionaliseerimisotsused, mis toovad kaasa neljateistkümnekuulise ajakava pikenduse, ei ole teostuse vead. Need on teabevead. Ühinemisjärgsetes ratsionaliseerimisprogrammides esineb kolm konkreetset teabelünka:

Lünk 1: Väidetav eesmärk versus tegelik eesmärk

Rakenduse omanik kirjeldab, milleks süsteem on loodud. Pärast aastaid või aastakümneid kestnud kohandamist teeb süsteem oluliselt enamat. CRM, mis „haldab kliendisuhteid“, võib käivitada ka kvartalikomisjonitasude arvutamise, tegeleda suurimate kontode erandite töötlemisega ja säilitada teatud lepingutingimuste ainsa koopia vormingus, millest sõltub alljärgnev aruandlus. Midagi sellest ei ole rakenduse omaniku kirjelduses, sest midagi sellest ei olnud ka algsetes nõuetes. See kogus ühe lahenduse korraga, millest igaüks lahendas kohese probleemi ilma kellegi süsteemi eesmärgi kirjeldust värskendamata.

Gap 1 avastamise kulud pärast pensionile jäämist: asendussüsteemi peidetud funktsioonide taastamine, sageli hädaolukorra kuludega, samal ajal kui ettevõte tegutseb ilma nendeta või käsitsi lahenduste abil.

Lünk 2: Deklareerimata sõltuvused

Rakendus näib olevat iseseisev. Selle väljundist sõltuvad kaksteist muud süsteemi. Sõltuvust pole kunagi ametlikult dokumenteeritud, kuna see loodi mitteametliku andmevoo kaudu, mille arendaja lõi kolm aastat tagasi aruandlusprobleemi lahendamiseks. Rakenduse omanik ei tea sõltuvusest. Sõltuvate süsteemide omanikud teavad, et nad saavad andmeid, kuid eeldavad, et need pärinevad "arveldussüsteemist", teadmata, milline programm neid konkreetselt toodab.

Sõltuvused, mida inventuur kunagi ei loetlenud, üks rakendus näib olevat kasutuskõlbmatu, kuna keegi ei kaardistanud, mis sellest sõltus. Gap 2 avastamise hind pärast pensionile jäämist: kaksteist süsteemi lakkavad toimimast või lagunevad viisil, mis viitab sõltuvusele, mis oleks pidanud olema ratsionaliseerimisanalüüsis, aga mida seal polnud.

3. lünk: andmete migratsiooni ulatuse alahindamine

Andmemigratsiooni plaan hindab sihtsüsteemi skeemi praeguse dokumentatsiooni põhjal. Skeemil on nelikümmend seitse varianti, mis on kogunenud neljakümne aasta jooksul ärireeglite muudatuste käigus, millest kolm on dokumenteeritud ja nelikümmend neli on nähtavad ainult programmikoodis, mis andmeid loeb ja kirjutab. Andmemigratsiooni ulatust hinnatakse kolme dokumenteeritud variandi suhtes ja see viiakse lõpule ajakava kohaselt. Pärast migreerimist ebaõnnestuvad protsessid, mis tuginesid neljakümnele neljale dokumenteerimata variandile, tekitades valesid väljundeid, mida ei tuvastata enne, kui kvartaliaruanne või regulatiivne esildis lahknevuse paljastab.

3. lünga avastamise maksumus pärast migratsiooni: algpõhjuse analüüs, andmete parandamine, ümbertöötlemine ning reguleeritud tööstusharudes regulatiivne teavitamine ja parandusmeetmed.

Viis ratsionaliseerimisotsust

Iga kombineeritud portfoolio rakendus vastab ühele viiest ratsionaliseerimise tulemusest. Otsustusraamistik kehtib nii vanade kui ka kaasaegsete rakenduste kohta, kuigi otsuse tegemiseks vajalikud tõendid erinevad oluliselt:

otsus	Määratlus	Millal kandideerida	Nõutavad esmased tõendid
hoidma	Säilitada praegusel kujul, ühendatud üksuse hallatavana	Ainulaadne funktsionaalsus, millele teistes portfellides vastet pole, piisav kvaliteet	Ärifunktsioonide kaardistamine, sõltuvuste analüüs
Kindlustama	Ühenda mõlema portfoolio versiooni funktsionaalsus üheks säilinud eksemplariks	Mõlemad organisatsioonid täidavad samaväärseid funktsioone; üks juhtum on parem	Funktsionaalse kattuvuse analüüs, tunnuslünkade hindamine, migratsiooni keerukus
moderniseeritud	Säilita ärifunktsioon, muuda tehnilist teostust	Funktsioon on vajalik, kuid tehniline kvaliteet on pikaajaliseks säilitamiseks liiga halb	Koodi kvaliteedi mõõdikud, keerukuse hindamine, tehnilise võla hindamine
asendama	Rakenduse eemaldamine, asendamine kommerts- või pilvepõhise alternatiiviga	Funktsioon on kaup; standardtoode täidab seda piisavalt hästi	Alternatiivide turul kättesaadavus, kohandamise sügavuse hindamine
Pensionile jääda	Kasutuselt kõrvaldamine ilma asendamiseta	Funktsioon on tõeliselt üleliigne, ilma unikaalse loogika ja aktiivsete tarbijateta	Surnud koodi analüüs ja sõltuvuste kaardistamine, mis kinnitavad aktiivsete tarbijate nullimist

Otsus, mis näeb välja nagu pensionile jäämine, aga tegelikult on see alles: rakendus, millel pole aktiivseid kasutajaid, väike tehingute maht ja nähtavaid allkasutajaid, näib olevat pensionile jäämise kandidaat. Kui see sisaldab unikaalset äriloogikat, jurisdiktsioonilisi maksureegleid, regulatiivseid arvutusrutiine või lepinguliste kohustuste töötlemist, mida pole mujal korratud, tähendab selle pensionile jäämine selle loogika jäädavat kaotamist. See on arveldussüsteemi stsenaarium selle artikli algusest. Otsus tundub inventuuri põhjal ilmne; tõendite põhjal on see vale.

Konstruktsioonianalüüsi eeltingimus

Rakenduste ratsionaliseerimine ühinemiste ja omandamiste käigus on tehingumudelisse kuuluv säilitamise, migreerimise, konsolideerimise või kasutuselt kõrvaldamise otsus enne tehingu lõpuleviimist. Paralleellitsentsid, varjatud integratsioonid ja kasutuselt kõrvaldamise järjestamine on tegelikud kulud.

Nende otsuste täpne langetamine nõuab struktuurilisi tõendeid, mis ulatuvad kaugemale sellest, mida rakenduste omanikud saavad intervjuudes esitada, mida IT-varade haldussüsteemid salvestavad ja mida SaaS-litsentsi auditid näitavad. Pärandrakenduste kihi, COBOL-süsteemide, kohandatud partiiprogrammide, patenteeritud vahevara ja aastakümneid töötanud andmebaasipõhiste ärirakenduste puhul eksisteerivad struktuurilised tõendid ainult lähtekoodis.

Neli struktuurianalüüsi väljundit, mida ratsionaliseerimisotsuste tegemiseks vaja läheb:

Äriloogika inventuur. Milliseid reegleid rakendus kodeerib? Mitte omaniku antud funktsionaalset kirjeldust, vaid programmikoodis rakendatud spetsiifilisi arvutusi, tingimuslikke harusid, valideerimisreegleid ja teisendusloogikat. COBOL-programmide puhul tähendab see PROCEDURE DIVISION-i parsimist, et eraldada IF/EVALUATE-loogika, COMPUTE-laused ja ärireegleid rakendavad tingimuslikud töötlusteed. See inventuur on spetsifikatsioon, millele iga asendus- või konsolideeriv süsteem peab vastama.

Sisse- ja väljalülitatud olekus analüüs. Mitu muud rakendust, programmi või protsessi sõltub selle rakenduse väljunditest? Sisse- ja väljalülitatud olekus on peamine pensionile jäämise riski ennustaja: rakendus, millel pole sisse- ja väljalülitatud olekuid, saab ohutult pensionile jääda; rakendus, millel on viiskümmend sisse- ja väljalülitatud olekut, kannab endas riski, et pensionile jäämine rikub viiskümmend muud asja. Pärandkeskkondades hõlmab sisse- ja väljalülitamine lisaks otsesetele API-kõnedele ka andmevoo sõltuvusi, jagatud VSAM-failide tarbijaid, programmi käivitavaid JCL-töövooge ja allavoolu pakkprotsesse, mis loevad selle väljundandmekogumeid.

Surnud koodi protsent. Milline protsent rakenduse koodist on ligipääsmatu üheltki tootmisversioonilt? Surnud kood, mis on aastakümnete jooksul funktsioonide lisamise ja veaparanduste käigus kogunenud, suurendab rakenduse näilist keerukust ja moderniseerimise näilist maksumust. Surnud koodi tuvastamine ja ratsionaliseerimise ulatusest väljajätmine annab täpsema pildi sellest, mida tuleb tegelikult migreerida, konsolideerida või asendada.

Andmete migreerimise keerukus. Milline on iga rakenduse hallatava andmestiku kirjepaigutuse struktuur? Mitu REDEFINES varianti on olemas? Millised COMP-3 väljad vajavad täpsust säilitavat sihttüübi kaardistamist? Millised ärireeglid reguleerivad andmeid, millest rakenduse tarbijad sõltuvad? Vastused määravad, kas andmete migreerimine on otsekohene skeemi teisendamine või mitmekuuline andmete teisendamise programm.

100-päevane ajajoon: kui kiirus on vastuolus põhjalikkusega

100-päevane integratsiooniplaan on ühinemisjärgse teostuskiiruse valdkonna võrdlusnäitaja. Investorid, juhatuse liikmed ja juhtimiskonsultandid mõõdavad integratsiooni edu selle ajakava alusel. Surve demonstreerida varajast sünergia realiseerimist ja näidata turule, et tehing toimib, koormab kõiki töövooge, sealhulgas rakenduste ratsionaliseerimist.

Ajagraafiku surve ja analüüsi põhjalikkuse vaheline konflikt on see, kus ratsionaliseerimisprogrammid teevad oma kõige kallimaid vigu. Organisatsioon, mis ei suuda oma kombineeritud portfelli põhjalikku struktuurianalüüsi 100 päeva jooksul lõpule viia, seisab silmitsi valikuga: teha ratsionaliseerimisotsuseid mittetäieliku teabe põhjal või mitte ajakavast kinni pidada ja seista silmitsi küsimustega integratsiooni teostamise kohta.

Küpsete omandajate lahendus ei ole analüüsi kokkusurumine, vaid otsuste järjestamine:

1. laine (päevad 1–30): Ainult selged ja üheselt mõistetavad otsused. Rakendused, mis on selgelt üleliigsed ja millel puudub unikaalne loogika; rakendused, mis on selgelt säilitatavad ilma konsolideerimiskandidaatideta; rakendused, mis on ühe organisatsiooni tegevuskavas juba pensionile jäämiseks kavandatud. Need otsused ei vaja põhjalikku struktuurianalüüsi, kuna tulemuses pole kahtlust. Nende kiire tegemine näitab integratsiooni hoogu ilma ebatäieliku teabe põhjal valede otsuste tegemise riskita.

2. laine (päevad 31–90): Otsused, mis vajavad sihipärast analüüsi. Rakendused, mis tunduvad üleliigsed, kuid mille ratsionaliseerimise tulemus sõltub konkreetsetest struktuurilistest tõenditest: kas on olemas unikaalne äriloogika? Milline on sisse- ja väljalülitatud rakenduste arv? Kui keeruline on andmete migreerimine? Struktuurianalüüs tellitakse spetsiaalselt selle kategooria rakenduste jaoks, suunates ressursid otsustele, mille puhul analüüs muudab tulemust.

3. laine (91+ päeva): Otsused, mis nõuavad põhjalikku analüüsi. Rakendused, mille keerukus muudab 90-päevased ratsionaliseerimisotsused täiesti sobimatuks, aastakümnete jooksul kogunenud loogikaga pärandsüsteemid, mõlemat organisatsiooni teenindavad jagatud andmeplatvormid, missioonikriitilised partiiprogrammid, mille käitumist ei mõisteta täielikult. Need lükatakse selgesõnaliselt edasi dokumenteeritud põhjendusega, mitte ei kiirustata vale vastuseni.

See järjestamisviis ühildab ajajoone surve põhjalikkuse nõudega: varased lained näitavad hoogu; hilisemad lained kaitsevad katastroofiliste valede otsuste eest, mis põhjustavad neljateistkümnekuulisi ajajoone pikendusi.

Loovutamine: vastupidine probleem

Omandamised loovad vajaduse koondada kaks portfelli üheks. Müügid loovad pöördprobleemi: integreeritud tervikuna ehitatud portfell jaguneb kaheks sõltumatuks portfelliks, mis mõlemad saavad toimida ilma teiseta.

Loovutamise kontekstis alustab SpinCo oma uut elu sageli paisunud portfelliga, mis koosneb olemasolevatest rakendustest, mida kasutab ainult SpinCo, ja rakendustest, mida ta jagab ParentCo-ga, näiteks HR ja ERP. Samal ajal jääb ParentCo-le sageli luhtunud kulusid rakenduste eest, millest ta koos SpinCo-ga loobus.

Loovutamise ratsionaliseerimise väljakutse erineb põhimõtteliselt omandamise väljakutsest, sest kõigepealt tuleb vastata eraldatavuse küsimusele: kas see rakendus saab toimida iseseisvalt või on see integreeritud ülejäänud organisatsiooniga viisil, mis muudab puhta eraldamise ebapraktiliseks?

COBOL-programm, mis teenindab küll müüdud äriüksust, aga loeb jagatud suurarvuti andmebaasist, mis teenindab ka allesjäänud äriüksust, ei ole selgelt eraldatav. Eraldamisvõimalused on järgmised: andmebaasi replikatsioon (ülemineku ajal sünkroniseerimise säilitamise keerukus), müüdud programmi migreerimine uude andmebaasi eksemplari (andmete migreerimise keerukus ja käitumuslike erinevuste risk) või jagatud juurdepääsu korralduse jätkamine pärast eraldamist (kahe sõltumatu üksuse ühise andmeinfrastruktuuri haldamise keerukus).

Igal neist valikutest on erinevad kulud, riskid ja ajakava. Ühtegi neist ei saa hinnata ilma täpselt teadmata, kuidas programm jagatud andmebaasi kasutab, milliseid tabeleid, milliseid välju, millistes juurdepääsumustrites, millise mahu ja sagedusega. See on pärandkoodi struktuurianalüüs, mitte dokumentatsiooni ülevaade.

Pärandkood ühinemistes ja omandamistes: mõõde, millega keegi arvestab

SaaS-i ratsionaliseerimise probleem – milliseid rakendusi alles hoida, milliseid lepinguid lõpetada ja milliseid müüjaid koondada – lahendatakse hästi olemasolevate tööriistade ja raamistikega. Vananenud koodi ratsionaliseerimise probleemile puudub enamikus organisatsioonides samaväärne tööriistade tugi.

Kui nii omandaja kui ka sihtettevõte kasutavad oma põhitegevuse töötlemiseks suurarvuti COBOL-süsteeme, nõuab ratsionaliseerimisotsuse tegemine küsimustele vastamist, millele rakenduse omaniku intervjuud ja IT-varade haldussüsteemid ei suuda vastata:

Millised COBOL-programmid on iga organisatsiooni jaoks ainulaadsed? Omandaja suurarvutite portfell ja sihtettevõtte suurarvutite portfell võivad funktsioonilt kattuda (mõlemad haldavad kliendikontosid), kuid rakendamiselt erineda (mõlemal on aastakümnete pikkune ainulaadne ärireeglite kogunemine). Tegeliku funktsionaalse kattuvuse tuvastamiseks on vaja programmide analüüsi, mitte siltide lugemist.

Millised programmid on jagatud infrastruktuuriga ja millised äriüksuse-spetsiifilised? JCL-i utiliidiprogramm, mida kutsuvad nelikümmend programmi üle ühendatud organisatsiooni, on jagatud infrastruktuuriga. COBOL-arvutusrutiin, mida kutsuvad kolm ühte äriüksust teenindavat programmi, on äriüksuse-spetsiifiline. Ühendatud programmi inventuuri hõlmav ventilaatoripõhine analüüs loob selle klassifikatsiooni automaatselt.

kobol

      *> Target company's tax calculation -- 40 years of jurisdiction rules
      *> 63 countries, 847 tax rule conditions, embedded in this program
      *> Not documented anywhere except in this PROCEDURE DIVISION
       CALCULATE-TAX.
           EVALUATE WS-COUNTRY-CD
               WHEN 'US' PERFORM US-TAX-CALC
               WHEN 'UK' PERFORM UK-VAT-CALC
               WHEN 'DE' PERFORM GERMAN-MWST-CALC
               WHEN 'FR' PERFORM FRENCH-TVA-CALC
               *> ... 59 more WHEN clauses
               WHEN OTHER PERFORM DEFAULT-TAX-CALC
           END-EVALUATE.

See programm genereerib iga hallatava jurisdiktsiooni jaoks spetsiifilise auditeeritava väljundi. Selle kustutamiseks tuleb kas iga WHEN-klausel ja iga aluseks olev PERFORM-sihtmärk replikeerida asendussüsteemis või aktsepteerida, et asendus annab mõne jurisdiktsiooni jaoks erinevad väljundid. Kumbki tulemus pole rakenduse inventuurist nähtav. Mõlemad on nähtavad COBOL-i lähtekoodis.

Milline on iga rakenduse andmete migreerimise ulatus? Pärand-COBOL-rakendusega seotud andmed on määratletud FD-kirjetes ja koopiaraamatutes, mis võivad olla kogunud mitu REDEFINES-varianti, täpsusega arvestavat kaardistamist nõudvaid COMP-3 välju ja manustatud kehtivuspiiranguid, mis on jäädvustatud 88-tasemeliste tingimuste nimedesse. Gap 3 tõrke põhjustab andmete migreerimine, mille ulatus on määratud dokumentatsiooni, mitte tegeliku skeemi alusel.

Millised programmid sisaldavad surnud koodi, mille saab migreerimise ulatusest välja jätta? Pärandprogrammide surnud kood suurendab näilist moderniseerimise või migreerimise keerukust. Programmid, mille puhul on surnud koodi 40 protsenti, nõuavad 40 protsenti suurema hulga koodi analüüsimist ja migreerimist, kui reaalajas tootmine tegelikult nõuab. Surnud koodi tuvastamine enne migreerimise ulatuse lukustamist vähendab töömahu hinnanguid ja parandab ajakava täpsust.

Ühinemis- ja omandamisportfelli ratsionaliseerimise taotlusotsuse kontrollnimekiri

Iga ulatusse kuuluva rakenduse puhul on enne enesekindla ratsionaliseerimisotsuse tegemist vaja järgmisi tõendeid:

Äriloogika hindamine

• Kas rakenduse tegelikku funktsiooni on kontrollitud koodianalüüsi, mitte ainult omaniku intervjuu abil?
• Kas kõik koodi sisse põimitud ärireeglid on dokumenteeritud kujul, millele asendus peab vastama?
• COBOL-programmide puhul: kas kõik EVALUATE-harud, IF-tingimused ja COMPUTE-laused on inventuuritud?

Sõltuvuse hindamine

• Kas sissepuhkeala on struktuurilt mõõdetud (mitte rakenduse omaniku hinnangul)?
• Kas kõik andmevoo sõltuvused on loetletud JCL-i, faili ja andmebaasi tasandil?
• Kas on jälgitud dünaamiliste CALL-sõltuvusi, mitte ainult staatiliste kõnede graafi servi?

Andmete migratsiooni hindamine

• Kas FD kirjetest ja COPY liikmetest on eraldatud täielik kirje paigutus?
• Kas kõik REDEFINES variandid on tuvastatud ja nende eristavad tingimused dokumenteeritud?
• Kas kõik COMP-3 ja binaarväljad on kaardistatud täpsusega sobivate sihtmärkide tüüpidega?

Surnud koodi hindamine

• Kas surnud kood on tuvastatud ja migratsiooni ulatuse hinnangutest välja jäetud?
• Kas kasutusest kõrvaldamise otsuseid kinnitatakse surnud koodi analüüsiga (tootmise täitmisradadelt ei lisata uusi koode)?

Riskiklassifikatsioon

• Kas rakenduse kriitilisuse skoori on kontrollitud konstruktsioonianalüüsi tulemuste suhtes?
• Kas säilitamise, migreerimise või pensionile jäämise ajakava on kooskõlas sõltuvuste keerukusega?

Kuidas SMART TS XL Toetab ühinemis- ja omandamisportfelli ratsionaliseerimist

SMART TS XL pakub struktuurset tõendusmaterjali ratsionaliseerimisotsuste tegemiseks, mida ei saa ainuüksi dokumentatsiooni ja intervjuude põhjal õigesti teha.

Staatilise koodi analüüsi võimalus ekstraheerib äriloogika inventuuri COBOL-ist, JCL-ist, Java-st, Pythonist ja kõigist teistest keeltest mõlema organisatsiooni portfellides, luues tervikliku pildi sellest, mida iga rakendus tegelikult teeb, mitte ainult seda, mida selle silt ütleb. COBOL-programmide puhul, nagu ülaltoodud maksuarvutuse näites, loetleb see analüüs iga jurisdiktsiooni, iga reegli tingimuse ja iga arvutusharu, mida asendusprogramm peab rakendama samaväärsete tulemuste saamiseks.

Rakenduste sõltuvuste kaardistamine pakub jaotusanalüüsi, mis määrab pensionile jäämise riski ja konsolideerimise järjekorra. Mõlema organisatsiooni samaaegselt analüüsitud portfellide puhul näitab sõltuvuskaart, millised programmid on tõeliselt eraldiseisvad, millised on sügavalt integreeritud jagatud infrastruktuuri ja millised kannavad varjatud allavoolu sõltuvusi, millest Gap 2 tõrked koosnevad.

Mõjuanalüüsi võimalus muudab iga kavandatud ratsionaliseerimisotsuse enne selle elluviimist testitavaks: kui see programm pensionile läheb, millised teised programmid kaotavad sõltuvuse? Kui see andmestik migreeritakse, milliseid programme tuleb uuest asukohast lugemiseks värskendada? Iga kavandatud otsuse mõju ulatus on struktuurimudelist loetletav, teisendades riskihinnangutest pärinevad ratsionaliseerimisotsused määratletud ja ulatusega plaanideks.

Vananenud moderniseerimise analüüs annab tulemuseks keerukuse skoori ja surnud koodi tuvastamise, mis muudab töömahu hinnangud täpseks: keerukuse alumises kvartiilis olevad programmid, millel on kõrge surnud koodi protsent, on tugevad kandidaadid pensionile jäämiseks või moderniseerimiseks; keerukuse ülemises kvartiilis olevad programmid, millel on kõrge sissevooluprotsent, on säilitamise kandidaadid olenemata ilmsest koondamisest.

Ettevõtte otsinguvõimalus muudab kombineeritud portfelli päringutega hallatavaks kogu ratsionaliseerimisprogrammi vältel: leida sekunditega iga programm, mis pääseb juurde konkreetsele andmestikule, iga programm, mis rakendab konkreetset ärifunktsiooni, iga COBOL-programm, mille tsüklomaatiline keerukus ületab läve, mõlema organisatsiooni miljonites koodiridades kokku.

Organisatsioonide jaoks, mis tegelevad ratsionaliseerimisega ajalise surve all, SMART TS XLanalüüs tihendab struktuurianalüüsi ajajoont: kombineeritud portfelli täieliku sõltuvuskaardi, äriloogika inventuuri ja keerukuse skoori saab koostada päevade, mitte nädalate või kuude jooksul, mida nõuaks käsitsi koodi läbivaatamine. See tihendamine muudab 1. laine / 2. laine / 3. laine järjestamise lähenemisviisi elujõuliseks ning 2. laine rakenduste sihipärase struktuurianalüüsi saab lõpule viia ajajoone lubatud 90-päevase akna jooksul.

Sinu otsus on sama hea kui selle taga olevad tõendid

Portfelli ratsionaliseerimine pärast ühinemist toimub reaalse ajalise surve, reaalse finantsilise surve ja reaalse organisatsioonilise surve all, et näidata, et tehing toimib. Kõik need surved soodustavad kiiremat otsuste langetamist. Ükski neist ei muuda vale otsuse tegemise hinda.

Arveldussüsteem, mis oli kavandatud pensionile jääma ja seejärel hädaolukorras tagasi võeti, ei ole hoiatuslugu liiga aeglase liikumise kohta. See on hoiatuslugu liikumise kohta ilma tõenditeta, mis oleksid otsust muutnud. Struktuurianalüüs, mis paljastab süsteemi tegeliku toimimise, selle sisseehitatud äriloogika, varjatud sõltuvused ja andmete migreerimise keerukuse, ei muuda ratsionaliseerimist aeglasemaks. See muudab ratsionaliseerimise täpseks. Ja täpsus ühinemisjärgse integratsiooniprogrammi kontekstis, kus valed otsused põhjustavad kaheksateistkuulisi ajakava pikendusi ja üheksakohalisi kulude ületamisi, on ratsionaliseerimisotsuse kõige väärtuslikum omadus.

Edukas portfelli ratsionaliseerimine ei ole kiireim variant. Edukas on see, mis teab, mida ta ratsionaliseerib.