AS-IS y TO-BE: el mapa que toda modernización de aplicaciones necesita
El Departamento de Consultoría de Barona explica cómo el análisis AS-IS/TO-BE permite entender el estado actual de las aplicaciones y diseñar la transformación correcta.
Cada vez que una empresa nos llama para "modernizar sus aplicaciones", la primera pregunta que hacemos es siempre la misma: ¿saben exactamente qué tienen hoy?
La respuesta, en la mayoría de los casos, es un silencio incómodo seguido de "más o menos". Y ese "más o menos" es exactamente el problema que el análisis AS-IS y TO-BE está diseñado para resolver.
¿Qué significa AS-IS y TO-BE?
Son dos fotografías del mismo sistema tomadas en momentos diferentes:
-
AS-IS (como es): La descripción precisa y objetiva del estado actual — cómo funcionan los procesos hoy, qué aplicaciones los soportan, qué integraciones existen, qué datos fluyen entre sistemas y dónde están los cuellos de botella.
-
TO-BE (como debería ser): El diseño del estado futuro deseado — cómo deberían funcionar los procesos después de la transformación, qué tecnologías los habilitarán y qué capacidades nuevas tendrá la organización.
La brecha entre AS-IS y TO-BE es el proyecto de transformación.
Por qué el AS-IS es más difícil de lo que parece
En teoría, documentar el estado actual suena simple. En la práctica, es el trabajo más complejo y más valioso de todo el proceso.
Las organizaciones acumulan años de decisiones técnicas, workarounds, integraciones informales y conocimiento tácito que vive en la cabeza de dos o tres personas clave. Cuando esas personas no están disponibles — o peor, cuando ya no están en la empresa — el conocimiento desaparece.
En proyectos reales hemos encontrado:
- Aplicaciones que nadie sabe para qué sirven pero que nadie se atreve a apagar porque "algo podría romperse".
- Integraciones punto a punto entre sistemas que no están documentadas en ningún lugar — solo funcionan porque alguien las configuró hace ocho años.
- Bases de datos duplicadas con la misma información en tres sistemas diferentes, sin que ninguno sea la fuente de verdad.
- Procesos manuales que compensan limitaciones de las aplicaciones y que se han vuelto tan habituales que nadie los cuestiona.
La metodología de levantamiento AS-IS
Un levantamiento AS-IS riguroso tiene cuatro componentes:
1. Inventario de aplicaciones
El primer paso es saber exactamente qué aplicaciones existen. Esto incluye:
- Aplicaciones de negocio (ERP, CRM, sistemas propietarios)
- Aplicaciones de infraestructura (Active Directory, Exchange, servidores de archivos)
- Aplicaciones departamentales (hojas de cálculo críticas, bases de datos Access, aplicaciones desarrolladas internamente)
- Aplicaciones en la nube (SaaS) y sus integraciones con sistemas on-premises
Para cada aplicación documentamos: versión, proveedor, fecha de implementación, usuarios activos, criticidad para el negocio y estado de soporte del fabricante.
2. Mapeo de procesos de negocio
Las aplicaciones no existen en el vacío — soportan procesos. Para cada proceso crítico documentamos:
- Quién lo ejecuta y con qué frecuencia
- Qué aplicaciones intervienen y en qué orden
- Qué datos entran y qué datos salen
- Dónde hay pasos manuales que podrían automatizarse
- Dónde hay reprocesos o validaciones duplicadas
Esta fase requiere entrevistas con los usuarios reales del proceso, no solo con el equipo de TI. Los usuarios de negocio conocen los workarounds que TI no sabe que existen.
3. Análisis de integraciones
El mapa de integraciones es frecuentemente la parte más sorprendente del AS-IS. Documentamos:
- Qué sistemas se comunican entre sí
- Cómo se comunican (API, archivos planos, base de datos compartida, integración manual)
- Con qué frecuencia y qué datos intercambian
- Qué pasa cuando una integración falla
Un diagrama de integraciones bien hecho revela dependencias ocultas que pueden convertirse en riesgos críticos durante la migración.
4. Identificación de pain points
El AS-IS no es solo descriptivo — también es diagnóstico. Para cada proceso y aplicación identificamos:
- Tiempos de respuesta inaceptables
- Errores frecuentes y sus causas raíz
- Limitaciones funcionales que obligan a workarounds
- Riesgos de seguridad o cumplimiento
- Costos ocultos (licencias, mantenimiento, tiempo de administración)
Diseñando el TO-BE: el arte de lo posible
Con el AS-IS documentado, el diseño del TO-BE puede ser riguroso en lugar de especulativo.
El TO-BE no es simplemente "lo mismo pero en la nube". Es una oportunidad para repensar los procesos desde cero, aprovechando las capacidades que las tecnologías modernas habilitan.
Principios que guían el diseño TO-BE
Eliminar antes de migrar: Si un proceso tiene pasos innecesarios, eliminarlos antes de automatizarlos. Automatizar un proceso ineficiente solo lo hace ineficiente más rápido.
Consolidar antes de integrar: Si tres sistemas tienen la misma información, el TO-BE debería tener una sola fuente de verdad, no tres sistemas integrados.
Estándar antes de personalizado: Las plataformas modernas como Microsoft 365 y Azure tienen funcionalidades estándar que cubren el 80% de los casos de uso. La personalización debería ser la excepción, no la regla.
Datos primero: El diseño del modelo de datos del TO-BE es más importante que la elección de la tecnología. Una buena arquitectura de datos puede sobrevivir múltiples cambios tecnológicos.
El TO-BE en capas
Diseñamos el TO-BE en tres capas:
- Capa de procesos: Cómo deberían fluir los procesos de negocio en el estado futuro.
- Capa de aplicaciones: Qué aplicaciones soportarán esos procesos y cómo se integrarán.
- Capa de infraestructura: Sobre qué plataforma correrán esas aplicaciones (Azure, M365, on-premises, híbrido).
La brecha: el plan de transformación
La diferencia entre AS-IS y TO-BE define el trabajo de transformación. Pero no todo puede hacerse a la vez.
Priorizamos la transformación según tres criterios:
- Impacto en el negocio: ¿Qué cambio genera más valor para la organización?
- Complejidad técnica: ¿Qué tan difícil es implementar el cambio?
- Riesgo operacional: ¿Qué tan crítico es el sistema que se va a modificar?
El resultado es una hoja de ruta de transformación con iniciativas ordenadas por prioridad, con dependencias claras y con criterios de éxito medibles para cada fase.
Un ejemplo real: de silos a plataforma integrada
En un proyecto reciente para una empresa de distribución, el AS-IS reveló:
- ERP on-premises con 12 años de antigüedad, sin soporte del fabricante
- CRM en Excel compartido por 15 vendedores (con versiones diferentes en cada computadora)
- Facturación electrónica integrada manualmente — alguien copiaba datos del ERP al sistema de facturación todos los días
- Reportes gerenciales que tardaban 3 días en prepararse
El TO-BE diseñado incluyó:
- Migración del ERP a la versión cloud del mismo proveedor
- Implementación de Dynamics 365 Sales como CRM unificado
- Integración automática ERP-facturación vía API
- Power BI conectado directamente al ERP para reportes en tiempo real
El resultado: reportes disponibles en minutos, cero trabajo manual de integración y una sola fuente de verdad para toda la información comercial.
Conclusión
El análisis AS-IS/TO-BE no es un ejercicio burocrático — es la diferencia entre una transformación exitosa y un proyecto que termina a medias, con sistemas nuevos que replican los problemas de los sistemas viejos.
Invertir tiempo en entender profundamente el estado actual antes de diseñar el futuro es lo que permite que las transformaciones lleguen a buen puerto. En Barona Enterprise, este análisis es siempre el primer paso de cualquier proyecto de modernización, sin excepción.
