Antes de modernizar, hay que mapear (de verdad)

El síntoma se repite: “Queremos modernizar este sistema, pero nadie se anima a tocarlo”. No es flojera. Es miedo operativo.

Cuando un sistema lleva años funcionando se vuelve “parte del aire”… hasta que algo falla. Y ahí aparece la pregunta que nadie puede contestar con seguridad: ¿qué hace exactamente, quién lo usa y qué se rompe si lo tocamos?

Lo que todos ven

• El sistema “viejo” se siente lento, poco amable o limitado.
• Hay trabajo manual alrededor: exportar a Excel, re-capturar datos, mandar correos para confirmar.
• Los nuevos ingresos (y el equipo comercial) lo sufren porque no entienden el flujo.
• IT recibe tickets tipo “no funciona” sin contexto y con urgencia.
• Cada mejora cuesta más de lo razonable, y siempre aparece un “pero” (una excepción, un cliente especial, un proceso crítico).

Desde negocio, la conclusión típica es: “Hay que cambiarlo ya”. Muchas veces es cierto… pero no se empieza cambiando.

Lo que realmente está pasando

En la mayoría de empresas, el problema no es “el sistema” en abstracto. Es que:

1. El sistema es un conjunto de acuerdos no escritos
   Lo que se ejecuta día a día no está documentado como proceso real, sino como costumbre: “así se hace”.

2. Hay dependencias escondidas
   Un módulo “simple” puede alimentar:

• facturación,
• inventario,
• comisiones,
• reportes a dirección,
• reclamos de clientes,
• integraciones con un CRM,
• o un proceso de calidad.

3. El dato manda, aunque nadie lo diga
   Cuando no está claro qué campos son fuente de verdad, se termina decidiendo con copias:

• un Excel para ventas,
• otro Excel para operaciones,
• un reporte “arreglado” para finanzas.

4. El conocimiento vive en personas, no en el sistema
   El “mapa” está en dos o tres personas: quien lo configuró, quien lo opera y quien apaga incendios. Si una se va, el riesgo se dispara.

Modernizar sin mapear es como remodelar un local sin saber dónde están los cables, las llaves de agua y el tablero.

Hacia dónde va esto

La buena noticia: documentar ya no tiene por qué volverse un proyecto eterno.

Cada vez más equipos están usando documentación asistida por IA para sistemas heredados:

• leer logs y eventos para inferir flujos reales,
• analizar bases de datos para entender entidades, campos y relaciones,
• revisar pantallas, formularios y reportes para reconstruir el “cómo se usa”,
• comparar lo “documentado” vs lo que realmente pasa en operación.

La IA acelera muchísimo, pero no sustituye lo que define el rumbo: criterio de negocio.

El punto no es producir un documento bonito. Es responder preguntas que mueven dinero y riesgo:

• ¿Qué proceso genera ingresos?
• ¿Qué parte impacta la experiencia del cliente?
• ¿Qué módulo toca facturación y no puede fallar?
• ¿Qué se puede automatizar primero sin romper nada?

Cómo lo trabajamos en Byte IT

Cuando alguien llega con “queremos modernizar”, solemos regresar con una pregunta simple: ¿ya tienen el mapa?

Mapear no es burocracia. Es ganar velocidad con control.

Aplicamos nuestro método: Escuchamos → Entendemos → Detectamos el problema real → Proponemos una solución con propósito → Construimos con la tecnología correcta → Medimos → Ajustamos → No soltamos hasta que funcione.

El mapeo aterriza en entregables que sirven para decidir y ejecutar:

1. Procesos reales (no los teóricos)

• Qué dispara el proceso (pedido, alta, reclamo, pago, cambio).
• Qué pasos existen y quién los hace.
• Qué excepciones pasan (y con qué frecuencia).
• Qué métricas importan (tiempo, retrabajo, errores, devoluciones).

2. Módulos + usuarios + responsabilidades

• Qué módulos existen (aunque no estén separados formalmente).
• Quién los usa y para qué.
• Qué dueños de proceso validan cambios.

3. Mapa de datos y “fuente de verdad”

• Campos críticos (cliente, precios, condiciones, stock, impuestos).
• Dónde se crean, dónde se transforman y dónde se consumen.
• Qué reportes dependen de qué tablas/campos.

4. Dependencias e integraciones

• APIs, archivos, macros, robots, correos automáticos.
• Sistemas satélite (CRM, contabilidad, WMS, e-commerce).
• Dependencias “artesanales” (personas que bajan/suben archivos a mano).

5. Riesgos y prioridades

• Qué se rompe si cambiamos X.
• Qué duele más si falla (operación, ventas, caja, cumplimiento).
• Qué se puede modernizar primero con impacto visible y riesgo bajo.

El resultado no es un “manual”. Es un mapa operativo: entendible para negocio e IT, con decisiones claras, responsables y puntos de control.

Caso práctico

Empresa distribuidora (B2B), 35 personas, operación intensa.

Situación

• Sistema heredado para pedidos e inventario.
• “Modernización” planeada: cambiar interfaz y conectar un CRM.
• Cero documentación. Solo “lo sabe Juan”, el analista que lleva 8 años.

Problema visible
Dirección comercial quería que el CRM mostrara disponibilidad y precios “en tiempo real”. Operaciones respondía: “eso es peligroso: los precios cambian por cliente y por lista, y el stock no es tan directo”.

Lo que apareció al mapear

• El “stock disponible” no era un campo: era una fórmula con 4 ajustes (reservas, tránsito, devoluciones, ventas pendientes).
• El precio final dependía de 3 tablas y una regla por canal (mayoreo vs. especiales).
• Había un Excel externo (actualizado cada mañana) que corregía precios para 20 cuentas grandes.
• El reporte de comisiones tomaba datos de un log histórico, no del pedido final.

Decisión que cambió el plan
En vez de conectar el CRM directo al sistema heredado “para todo”, se definió:

• una primera API solo para consulta (clientes, productos, stock calculado, precio calculado),
• una etapa 2 para “escritura” (crear pedido) con validaciones,
• y un plan para eliminar el Excel migrando esas reglas al catálogo.

Impacto medible (90 días)

• Menos retrabajo en pedidos por error de precio: de ~12% a ~4%.
• Tiempo de confirmación de pedido: de 2–4 horas a 30–60 minutos en cuentas clave.
• Menos discusiones internas: ventas y operaciones trabajaban con el mismo criterio de dato.

No modernizaron todo. Modernizaron lo que importaba primero, con mapa y control.

Lección de negocio

Si no puedes responder con claridad:

• qué hace el sistema,
• quién lo usa,
• qué datos mueve,
• y qué depende de él,

entonces no tienes un sistema: tienes un riesgo operativo con interfaz.

Mapear convierte la modernización en un plan ejecutable: prioridades claras, métricas, responsables y menos sorpresas. Evita el clásico escenario donde el proyecto avanza “en pantallas”, pero retrocede “en operación”.

Checklist final

Antes de modernizar, asegúrate de poder contestar (con evidencia, no con suposiciones):

1. Procesos: ¿Cuáles son los 5 procesos que más impactan ingresos, caja y experiencia?
2. Usuarios: ¿Quién usa qué parte del sistema y con qué objetivo?
3. Excepciones: ¿Cuáles son las excepciones frecuentes que hoy se resuelven “a mano”?
4. Datos críticos: ¿Qué campos son fuente de verdad para cliente, precio, stock y facturación?
5. Dependencias: ¿Qué integra (APIs, archivos, macros, reportes, robots, correos)?
6. Riesgos: ¿Qué cambios son de alto riesgo y cuáles son mejoras rápidas pero controladas?
7. Métricas: ¿Qué vas a medir para saber que mejoró la operación (tiempo, error, retrabajo, devoluciones, conversión)?
8. Dueños: ¿Quién aprueba cambios por proceso (negocio) y quién responde por la entrega (IT)?

FAQ (5 preguntas)

1) ¿Mapear no retrasa la modernización?
La acelera: evita rehacer, reduce sorpresas y permite partir el proyecto en etapas con riesgo controlado. Un mapeo bien hecho tiene alcance y entregables accionables.

2) ¿Qué tan profundo debe ser el mapeo?
Tan profundo como el riesgo y el impacto. Lo que toca facturación, precios, inventario o cumplimiento requiere más detalle que un módulo de consulta interna.

3) ¿Qué entregables deberían salir del mapeo?
Como mínimo: mapa de procesos reales, matriz módulo-usuario, mapa de datos (fuente de verdad), diagrama de dependencias/integraciones y una lista priorizada de riesgos y mejoras.

4) ¿Cómo ayuda la IA en documentación de sistemas heredados?
Acelera el análisis de estructuras de datos, patrones de uso, trazas y reglas repetidas. Pero necesita validación con operación: la IA encuentra patrones; el negocio define qué importa.

5) ¿Qué hago si “nadie sabe” cómo funciona porque el equipo cambió?
Se puede reconstruir con entrevistas, observación del trabajo real, revisión de BD/reportes, logs y pruebas controladas. La clave es el método y las prioridades: primero lo que mueve operación y dinero.

Modernizar es una decisión de negocio. Mapear es lo que la vuelve responsable, medible y ejecutable. Y deja el terreno listo para automatización, integración y agentes de IA sin romper la operación.