O plan de modernización está listo, o orzamento aceptado de xeito preliminar. O provedor fai a primeira pregunta: «Onde está a documentación do sistema?». Resulta que hai unha wiki actualizada por última vez hai cinco anos, uns esquemas «nalgún lugar do disco de rede» e un código que fai el mesmo de documentación. O prezo sobe un terzo. Porque o provedor non pon prezo ao traballo, senón á incerteza.
Este texto describe unha práctica que retira esa incerteza da mesa: antes de que ninguén toque o código dunha aplicación vella, reconstrúese o coñecemento sobre ela. Ata hai pouco, esa etapa significaba semanas de traballo dun analista e case ninguén se decidía por ela. Hoxe a IA fai a maior parte desa análise en días laborables. E iso cambia a orde de todo o proxecto.
Primeiro o mapa, despois o código
Modernizar un sistema sen documentación actual lembra reformar un edificio sen o plano das instalacións. Pódese, pero cada parede que se pica é unha lotería: pode que detrás non haxa nada, ou pode que haxa un tubo do que depende medio andar. Nas aplicacións, ese tubo adoita ser unha integración co almacén que só lembraba o autor do código, ou unha exportación nocturna da que a contabilidade tira en silencio.
Por iso a orde sensata é a contraria á intuitiva. Non se comeza escribindo código novo, nin sequera polo orzamento. Comézase polo mapa.
Que extrae a IA do código, da base e dos logs
As ferramentas modernas de análise saben ler tres fontes de verdade sobre o sistema: o código fonte, a estrutura da base de datos e os logs do funcionamento en produción. Do seu cruzamento nace un mapa do sistema que abrangue catro capas.
A primeira son os módulos: de que se compón o sistema e de que responde cada fragmento, descrito nunha linguaxe comprensible tamén para persoas de fóra das TI. A segunda son os fluxos de datos: por onde entran os datos, que lles pasa polo camiño, onde aterran. A terceira son as integracións, é dicir, todos os puntos nos que a aplicación fala con outros sistemas: contabilidade, almacén, tenda, socios. Son elas as que máis a miúdo rompen cos cambios.
A cuarta capa é a menos obvia: o código morto. A análise dos logs mostra que funcións non foron chamadas desde hai anos e en que táboas ninguén escribe desde 2019. Nos sistemas máis vellos, ese lastre é a miúdo unha parte considerable do total. Cada liña que non hai que trasladar é un aforro real no proxecto.
Que cambia o mapa na decisión «reescribir ou modernizar»
Sobre a propia decisión escribimos á parte, no texto sobre os catro criterios: un marco de decisión. O mapa do sistema dálles a eses criterios datos duros. Sen el, a débeda tecnolóxica avalíase a ollo e o risco, a base de anécdotas. Con el vese branco sobre negro: que módulos levan valor de negocio, cales están mortos, onde se agochan as integracións que elevan o risco de cada cambio.
Os resultados sorprenden nas dúas direccións. Ás veces un sistema que «hai que reescribir de cero» resulta estar san en tres cuartas partes e abonda con substituír dous módulos. Ás veces é ao revés: a aplicación parece inocente e o mapa revela unha ducia de conexións non documentadas que fan a modernización parcial máis cara ca a reescritura. Nos dous casos, a decisión tómase sobre datos, non sobre emocións. E o provedor que recibe un mapa en vez dun enigma pon prezo ao traballo, non ao risco.
Na nosa opinión, a reconstrución do mapa debería ser unha etapa separada e primeira do contrato de modernización, coa súa propia aceptación. Aínda que despois desa etapa decidas que a modernización a fai outro, ou que non a fas en absoluto, a documentación queda na empresa e segue traballando.
Como verificar o que xerou a IA
A documentación xerada automaticamente non é un oráculo. Hai que comprobala. O método máis eficaz é simple: unha revisión coa persoa que mellor coñece o sistema, a miúdo a única na empresa. A diferenza fronte ao enfoque clásico está no papel desa persoa. Non lle pides que escriba o seu coñecemento, cousa que ninguén quere facer e que se arrastra durante meses. Pídeslle unha recensión dunha descrición xa feita, e sinalar «isto cadra, isto non» vai moitas veces máis rápido ca escribir de cero.
Unha boa práctica é percorrer algúns dos procesos máis importantes de principio a fin: pedido, factura, reclamación. Se o mapa describe correctamente os fluxos críticos e os detalles comprobados por mostraxe, pódeselle confiar nas demais áreas. Iso faise nun día.
O que a IA non reconstruirá
Aquí, unha advertencia honesta: o código di que fai o sistema, pero non di para que. Unha excepción estraña no cálculo dun desconto pode ser un erro, ou pode ser un acordo comercial de 2016 que aínda rexe para un cliente grande. Iso non o resolverá ningunha análise de código. As intencións de negocio de hai unha década reconstrúense con entrevistas: conversas curtas coa xente de vendas, contabilidade e operacións, xa co mapa na man. O mapa suxire que preguntar, pero as respostas téñenas as persoas.
Un tema á parte é tamén o contorno da aplicación: servidores, rede, copias de seguridade. Sobre a documentación desa capa escribimos no texto sobre a auditoría da documentación da infraestrutura.
En ESKOM AI conducimos a etapa de mapeo cun equipo de axentes de IA especializados baixo a supervisión de enxeñeiros experimentados: a análise dun sistema empresarial típico leva días laborables, e o resultado é unha documentación lexible para a dirección e para o equipo técnico. Se despois dela se toma a decisión de modernizar, os traballos seguintes transcorren nun proceso automatizado de produción de software cun alcance completo de probas — unitarias, de integración, E2E, de interface, de seguridade e de rendemento.
Por onde comezar na túa empresa
Escolle un sistema: aquel cuxa modernización levas máis tempo aprazando ou o que máis medo che dá tocar. Encarga a reconstrución do seu mapa como unha etapa independente e pequena, antes de pedirlle a ninguén un orzamento para a remodelación. Nunha consulta gratuíta aconsellarémosche como planificar esa etapa e que esperar dela.
Concerta unha consulta gratuíta a través do formulario de contacto →