IT Consulting

Modernización de sistemas: cómo decidir qué actualizar primero

  • date-icon02 Sep, 2026
  • time-icon12 min
Modernización de sistemas: cómo decidir qué actualizar primero

Que una plataforma sea antigua no significa que sea lo primero que hay que cambiar. Si funciona bien, es estable y cumple con los requisitos de Solvencia II, puede esperar. Lo urgente puede ser ese proceso de suscripción más reciente que depende de correos, hojas de cálculo y decisiones que nadie sabe de dónde vienen.
La clave para priorizar la modernización de los sistema no es la edad del sistema, sino el riesgo que supone mantenerlo tal como está.

Para los directores de sistemas de información (CIO) y los responsables de aplicaciones empresariales, el verdadero reto no es elaborar una lista de sistemas obsoletos. La mayoría de las organizaciones ya tienen una. El reto es elegir las medidas de modernización que reduzcan una limitación empresarial importante, al tiempo que se conservan los controles, los cálculos y los conocimientos institucionales que aún funcionan.

Comience con el flujo de trabajo, no con el inventario de aplicaciones.

Un inventario de aplicaciones es necesario, pero por sí solo no es una herramienta de priorización eficaz. Un módulo de administración de políticas con diez años de antigüedad puede ser estable y estar bien comprendido. Un portal con tres años de antigüedad puede estar causando reintroducción de datos, retrasos en las aprobaciones y registros de auditoría incompletos a diario. La prioridad de la modernización se deriva del flujo de trabajo que admite el sistema y del costo de su fallo.

En el sector de los seguros, pensemos en la suscripción de pólizas comerciales. Un flujo de trabajo típico puede consistir en extraer del correo electrónico los documentos enviados por el corredor, validar los campos obligatorios, remitir las excepciones a un suscriptor, obtener la aprobación de la dirección, generar las condiciones y conservar el registro de la decisión. Si el personal tiene que estar saltando entre un repositorio de documentos, una hoja de cálculo de precios, un sistema de pólizas antiguo y el correo electrónico para completar una solicitud, el problema no es solo la deuda técnica. Se trata del tiempo de tramitación, la selección inconsistente de riesgos y la falta de fundamentos sólidos que justifiquen por qué se aprobó una solicitud.

Analiza ese flujo de trabajo en el punto donde realmente se atasca. Mide el tiempo de espera en cola y el de tramitación, la tasa de reelaboración, el volumen de excepciones y el porcentaje de solicitudes que requieren una aprobación fuera del sistema. Una iniciativa de modernización que reduzca el plazo de tramitación de la suscripción de cinco a dos días podría merecer prioridad frente a una sustitución completa de la plataforma que apenas aporte mejoras cuantificables durante el primer año.

El mismo principio se aplica al mantenimiento, reparación y revisión (MRO) en aviación. Un sistema de ejecución de mantenimiento puede estar anticuado pero ser fiable, mientras que los técnicos pierden horas porque las fichas de trabajo, la disponibilidad de piezas y las instrucciones de ingeniería no están sincronizadas. Según la Parte 145 de la EASA, la cuestión no es solo la facilidad de uso. La organización debe llevar registros de mantenimiento controlados y demostrar que el trabajo se ha realizado, se ha dado de alta y es trazable según el proceso aprobado. Modernizar el flujo de trabajo de las fichas de trabajo y las excepciones puede aportar un valor más inmediato que sustituir toda la infraestructura de mantenimiento.

Cuatro criterios para priorizar tu modernización

Un modelo útil de priorización evalúa cada iniciativa candidata desde cuatro perspectivas. La puntuación debe basarse en datos contrastados y ser revisada conjuntamente por los equipos de TI, operaciones, riesgos y el responsable del sistema.

  • Impacto operativo: ¿El sistema limita el rendimiento, genera trabajo manual que se podría evitar o provoca roces entre clientes y empleados? Usa indicadores como el tiempo de tramitación de las reclamaciones, la resolución a la primera, la productividad de los técnicos o la tasa de abandono.
  • Exposición en materia de control y cumplimiento: ¿El proceso actual genera pruebas completas y recuperables? ¿Puede garantizar la separación de funciones, las normas de conservación, el consentimiento, la validación o los controles de acceso exigidos por la HIPAA, GxP, PCI DSS o el RGPD?
  • Viabilidad del cambio: ¿Están documentadas las interfaces? ¿Es adecuada la calidad de los datos? ¿Se puede separar el flujo de trabajo de la plataforma central, o un cambio requeriría una sustitución de alto riesgo?
  • Dependencia estratégica: ¿Este trabajo permitirá otras mejoras, como un producto de datos regulado, un nuevo canal de autoservicio o un modelo de aprobación estandarizado?

La puntuación no pretende dar una precisión falsa. Obliga a tener una conversación más profunda: ¿qué problema supone un riesgo real y cuál solo es visible porque los usuarios se quejan de él con más frecuencia?

Un sistema con muchas dificultades operativas y un alto riesgo de incumplimiento normativo suele situarse entre las primeras posiciones de la hoja de ruta. Un sistema con muchas dificultades pero poca viabilidad puede que necesite primero una fase de análisis y corrección de datos. Un sistema con pocas dificultades, pero con una gran dependencia estratégica, puede justificar una inversión en arquitectura, sobre todo si frena un programa más amplio. La respuesta depende del calendario empresarial, de los plazos normativos y de la cantidad de cambios controlados que la organización pueda asumir.

Prioriza la modernización de los sistemas heredados en el ámbito adecuado

El error más común en la modernización es asumir que todo problema con un sistema heredado requiere sustituirlo por completo. En muchos casos, la solución está en modernizar los flujos de trabajo que rodean al sistema central, no el sistema en sí.

Imagina un equipo de operaciones sanitarias que usa un sistema antiguo de programación y derivaciones. Sustituirlo puede suponer años de riesgos de migración, recapacitación y validación. Pero el proceso de recepción de derivaciones se podría modernizar primero mediante una aplicación diseñada específicamente para ello, que valide los datos al introducirlos, derive las excepciones de autorización y vuelva a introducir los registros aprobados en el sistema central. Si hay información sanitaria protegida de por medio, el diseño debe aplicar desde el principio los controles de acceso mínimo necesario, registro de auditoría y retención que exige la HIPAA.

Aquí es donde Salesforce puede resultar una solución práctica. Salesforce Health Cloud o Financial Services Cloud pueden coordinar los flujos de trabajo relacionados con las relaciones, los casos, la recepción de solicitudes y las aprobaciones cuando la organización necesita una gestión del trabajo configurable y una experiencia de usuario clara. La plataforma no debe considerarse un sustituto de todos los sistemas centrales especializados. Puede servir como capa operativa en torno a uno de ellos, siempre que queden claros quién se encarga de la integración, la residencia de los datos, los controles de identidad y las reglas sobre el registro de referencia.

Para una empresa de fabricación, el patrón equivalente podría ser un flujo de trabajo de ejecución personalizado entre un ERP heredado y los sistemas de la planta de producción. A menudo, la prioridad no es recrear la funcionalidad del ERP, sino reducir el tiempo que se tarda en resolver un incumplimiento, recopilar pruebas de calidad y dar luz verde a una orden de producción. Cuando se aplican las normas GxP, los requisitos, las pruebas, los registros electrónicos y el control de cambios deben integrarse en el plan de entrega desde el principio, en lugar de documentarse después de la implementación.

Separa la corrección de datos de la modernización de la interfaz

Una interfaz bien diseñada puede reducir el tiempo de formación y los errores al introducir datos, pero no puede arreglar unos datos maestros poco fiables. Del mismo modo, un lago de datos no mejora el funcionamiento si los usuarios de primera línea siguen dependiendo de hojas de cálculo no oficiales para hacer su trabajo.

Considéralas como líneas de trabajo independientes pero coordinadas. La modernización de las interfaces se centra en la adopción y la ejecución. La corrección de datos aborda las definiciones, la propiedad, las normas de calidad, el linaje y la conciliación. La modernización de la integración aborda cómo los sistemas intercambian información, se recuperan de los fallos y muestran el estado a los equipos de soporte.

Por ejemplo, una consola de casos de Salesforce Service Cloud puede ofrecer a los gestores de siniestros una visión coherente de las comunicaciones con los reclamantes, las tareas y el estado de las escalaciones. Pero por sí sola no resolverá los registros duplicados de las partes ni los identificadores de pólizas contradictorios. Antes de ampliar la consola, define las reglas de coincidencia, la lógica de prevalencia y la fuente responsable de cada campo crítico. Si no, los usuarios perderán la confianza enseguida y volverán a los canales alternativos.

La misma disciplina es importante para la IA. La IA puede ayudar a clasificar los documentos que llegan, resumir las notas de los peritos o identificar información que probablemente falte en una solicitud. No debe anteponerse al flujo de trabajo ni a los controles de datos de los que depende. En una operación de siniestros regulada, un modelo que influya en la clasificación inicial o en las recomendaciones necesita tener documentados su propósito, la procedencia de los datos de entrada, los umbrales de revisión humana, la supervisión y una vía clara de escalado. Según la Ley de IA de la UE, la clasificación de riesgos y las obligaciones de gobernanza dependen del caso de uso. Una demostración genérica del modelo no es un plan de implementación.

Trata el descubrimiento como parte del proyecto

Algunos candidatos a la modernización no pueden evaluarse de forma responsable basándose únicamente en diagramas de arquitectura y entrevistas con las partes interesadas. Una fase de análisis breve y específica puede revelar procesos por lotes no documentados, conciliaciones manuales, soluciones alternativas locales o dependencias de informes regulatorios que modifiquen la decisión.

La fase de descubrimiento debería generar resultados operativos, no una presentación de diapositivas que se limite a reformular el problema. En el caso de un flujo de trabajo de reclamaciones, eso significa un mapa del proceso en su estado actual, un inventario de interfaces, una evaluación de los datos a nivel de campo, una matriz de aprobaciones, las deficiencias de control y una referencia cuantificada para el tiempo de ciclo y el trabajo de corrección. En el caso de una implementación de Salesforce, también debería identificar qué elementos deben configurarse, qué requiere un desarrollo a medida y qué debe permanecer en el sistema de registro.

Este trabajo ofrece a los ejecutivos una opción válida entre la modernización por fases, la sustitución de flujos de trabajo, la consolidación de plataformas o dejar tal cual un sistema estable. A veces, dejarlo tal cual es la decisión correcta. Si un sistema cumple con la normativa, es fácil de mantener y no limita ningún flujo de trabajo prioritario, quizá sea mejor invertir ese capital en otra cosa.

Elabora una hoja de ruta que ofrezca resultados tangibles desde el principio

La primera versión debería demostrar algo más que la conectividad técnica. Debería demostrar que un flujo de trabajo concreto funciona ahora mejor en condiciones reales de funcionamiento. Define el indicador antes de empezar a desarrollar: menos intervenciones manuales por derivación, menos atrasos en las excepciones, una tramitación más rápida de las aprobaciones o un mayor porcentaje de reclamaciones con un registro de decisión completo.

La adopción forma parte de esa medida. Una capa de UX/UI bien diseñada puede reducir el número de pantallas por las que tienes que navegar, mostrar la información necesaria en el momento de tomar una decisión y evitar que se envíen datos incorrectos antes de que entren en la cola. Pero la adopción no se puede imponer solo con el diseño de la interfaz. Incluye formación adaptada a cada puesto, informes de los supervisores y un proceso para gestionar las excepciones que el nuevo flujo de trabajo aún no cubra.

La hoja de ruta de modernización se gana la confianza cuando cada fase hace que las operaciones sean más controlables que antes. Elige aquellas tareas en las que coincidan una limitación cuantificable del flujo de trabajo, una deficiencia de control conocida y un límite técnico viable. Eso es tecnología con un propósito: no se trata de sustituir los sistemas heredados por el simple hecho de hacerlo, sino de mejorar las decisiones y los registros de los que depende el negocio cada día.