Por: Víctor San Miguel, Gerente de Transformación e Innovación Digital, GodCorp.
Modernizar implica entender el portafolio, priorizar necesidades e integrar aplicaciones para responder al negocio y habilitar nuevas capacidades.
Ejes de análisis
- El mapa de aplicaciones precede a la hoja de ruta
- La priorización conecta tecnología y negocio
- Inventariar antes de transformar
Modernizar aplicaciones no significa reemplazar todo aquello que lleva varios años operando. Tampoco debería responder únicamente a la aparición de nuevas tecnologías. La primera decisión consiste en determinar qué necesita realmente el negocio y qué problemas del portafolio actual requieren un cambio estructural.
Actualizar y modernizar son decisiones distintas. La actualización forma parte del ciclo normal de una aplicación: instalar parches, incorporar funcionalidades o mantener vigentes sus componentes. La modernización implica intervenir aspectos de fondo cuando la arquitectura, la plataforma o la forma en que opera una aplicación ya no responden adecuadamente a las necesidades de la organización.
La experiencia muestra que una aplicación puede seguir operativa y, sin embargo, requerir un cambio estructural. Un sistema de producción desarrollado en Visual Basic operaba en un entorno con numerosos puntos remotos conectados mediante enlaces radiales. Las dificultades de conectividad afectaban directamente la experiencia de los usuarios. En lugar de continuar haciendo ajustes sobre la misma solución o reforzar la infraestructura,, se optó por cambiar la plataforma y pasar de una aplicación de escritorio a un desarrollo web. La modernización permitió contar con un entorno más estable, rápido y seguro, que posteriormente sirvió como base para una plataforma empresarial.
La decisión, por tanto, no debería partir de la antigüedad de una aplicación, sino de la distancia que existe entre lo que esa aplicación ofrece y lo que el negocio necesita.
El mapa de aplicaciones precede a la hoja de ruta
Una práctica que hemos aplicado es construir un mapa de aplicaciones. Más que una lista de sistemas, debe permitir entender qué procesos soporta cada aplicación, cómo se relaciona con las demás, qué integraciones existen y cuánto la utilizan realmente los usuarios.
El nivel de uso puede revelar problemas que no son evidentes desde TI. Una aplicación puede estar disponible y técnicamente operativa, pero cubrir apenas una parte de las necesidades del usuario. Si este utiliza el sistema para obtener información, la descarga a Excel y completa allí la mayor parte del proceso, existe una señal que merece atención. Hay que preguntarse cuánto valor está aportando realmente esa aplicación. …
El mapa permite identificar este tipo de situaciones y, al mismo tiempo, encontrar aplicaciones que podrían integrarse, funcionalidades duplicadas o sistemas que deberían formar parte de una plataforma más amplia. También ofrece una visión de las dependencias entre aplicaciones, procesos e integraciones.
Por eso, el mapa de aplicaciones esuna herramienta para construir una hoja de ruta. A partir de esa visión se puede determinar dónde actualizar, dónde modernizar y qué iniciativas pueden resolverse rápidamente frente a otras que requieren mayor tiempo, inversión y recursos.
Cuando varias aplicaciones requieren intervención y los recursos son limitados, es necesario establecer criterios de priorización.
La seguridad debe considerarse de manera transversal. Una aplicación puede responder perfectamente desde el punto de vista funcional y, sin embargo, operar sobre una tecnología que ya no recibe soporte ni actualizaciones de seguridad. En ese caso, mantenerla representa un riesgo independientemente de las funcionalidades que todavía pueda ofrecer.
Después debe analizarse la criticidad para el negocio y la deuda técnica acumulada. Esta última muchas veces surge de la presión por responder rápidamente a requerimientos sin resolver adecuadamente los aspectos estructurales. Resolver una necesidad inmediata de esta manera puede terminar generando mayores costos y complejidad posteriormente.
La experiencia del usuario también debe formar parte de la evaluación. Una aplicación con un diseño adecuado facilita la adopción y mejora la eficiencia de los procesos que soporta. El mantenimiento, por su parte, debe entenderse como parte del ciclo de vida de cualquier solución, tanto adquirida como desarrollada internamente.
La priorización conecta tecnología y negocio
Uno de los desafíos habituales es que todas las áreas consideran urgentes sus requerimientos. Cuando la capacidad de desarrollo, presupuesto y tiempo son limitados, Tecnología no debería asumir por sí sola la decisión sobre qué iniciativa ejecutar primero.
Una práctica que ha funcionado es llevar el portafolio a una instancia de gobierno en la que participen las áreas de negocio y la dirección de la organización. Allí se pueden contrastar las prioridades del negocio con la complejidad técnica, el esfuerzo requerido y la capacidad disponible.
Tecnología aporta información necesaria para tomar esa decisión: qué puede ejecutarse internamente, qué requerirá apoyo externo, cuánto esfuerzo demandará y qué dependencias existen. De esta manera, la priorización deja de responder únicamente a quién solicita primero o quién considera más urgente su proyecto.
La decisión entre desarrollar una aplicación o adquirir una solución disponible en el mercado depende, entre otros factores, de qué tan particular sea la necesidad que se quiere resolver.
En el sector agrícola, por ejemplo, una nómina incorpora variables operativas que no necesariamente están contempladas en una solución administrativa convencional. Cuando los requerimientos están estrechamente relacionados con las particularidades del negocio y las alternativas disponibles no responden adecuadamente, el desarrollo puede ser una opción.
En cambio, para capacidades ampliamente cubiertas por el mercado, como un ERP, existen distintas alternativas que pueden evaluarse antes de considerar un desarrollo propio.
En ambos casos hay una condición que considero necesaria: la capacidad de integración. Adquirir una aplicación que después funciona de manera aislada puede trasladar el problema hacia los usuarios, que terminan descargando información de un sistema para cargarla en otro. Además de generar tareas manuales, este tipo de operación puede introducir riesgos de seguridad.
La integración debe analizarse desde el momento en que se evalúa una nueva solución y no después de haberla incorporado al portafolio.
Inventariar antes de transformar
Cuando una organización tiene numerosas aplicaciones con varios años de operación, empezaría por un inventario completo. Ese levantamiento debería permitir ponderar cada aplicación según la criticidad para el negocio, el nivel de automatización que aporta, su utilización, la deuda técnica y las relaciones que mantiene con otros componentes del entorno.
Este ejercicio suele mostrar situaciones que han permanecido ocultas durante años: aplicaciones que realizan funciones similares, sistemas que se mantienen para resolver una pequeña necesidad o soluciones cuyo aporte ya no justifica su permanencia.
Con esa información se puede construir una hoja de ruta y dimensionar lo que significará ejecutarla: esfuerzo, tiempo, inversión, personas involucradas y períodos de operación en paralelo. La modernización tampoco compromete únicamente a los equipos de TI. Los usuarios deben participar en las pruebas y validar que las nuevas soluciones respondan a la operación antes de pasar a producción.
Modernizar una aplicación sobre procesos que no están claros puede trasladar los mismos problemas a una plataforma más nueva. Por eso, antes de acelerar cambios tecnológicos o incorporar capacidades como inteligencia artificial, conviene revisar los procesos, identificar los puntos de dolor y establecer hacia dónde quiere avanzar la organización.
