02. Diagnóstico de raíz
Antes de actuar, entender de verdad.
Analizo la situación técnica y operativa completa para separar síntomas, deuda, causas y decisiones pendientes.
01. Cuándo tiene sentido
Poner un parche rápido puede salir muy caro.
Una web lenta puede esconder una arquitectura defectuosa. Un proceso manual puede existir porque los datos no son fiables. Un proyecto bloqueado puede ser un problema de responsabilidad, no de desarrollo. El diagnóstico evita invertir sobre una explicación incompleta.
No hace falta saber la causa ni llegar con una solución previamente elegida.
Sistemas, datos, procesos, personas y proveedores se revisan según su relación con el problema.
Cada opción explicada con impacto, riesgo, dependencia, esfuerzo y renuncias.
El diagnóstico puede cerrar con una decisión o convertirse directamente en dirección de la mejora.
Señales. El problema ya está afectando a la operación
No hace falta que la empresa conozca la solución. Estas situaciones suelen indicar que ya existe una decisión tecnológica u operativa pendiente.
El mismo fallo vuelve con otra forma.
Se cierran incidencias, pero reaparecen síntomas porque nadie ha conectado los patrones ni cuestionado la explicación inicial.
Hay propuestas, pero no una decisión.
Mantener, migrar, integrar o reconstruir parecen opciones posibles y dirección no dispone de una comparación independiente.
Cada área describe un problema distinto.
Tecnología, operación, comercial y proveedores ven fragmentos válidos, pero no existe un mapa común de causa e impacto.
El coste está normalizado y no medido.
Retrabajo, espera, errores, pérdida de confianza o dependencia de una persona ya forman parte del día a día.
02. Principio de intervención
No doy por válida la primera explicación ni convierto una auditoría en una colección de fallos. Investigo hasta poder conectar causa, impacto y decisión.
03. Alcance y entregables
Del síntoma a una decisión defendible.
El alcance se define después de entender la situación. Lo que no cambia es que cada fase produce una decisión, un artefacto o una mejora comprobable.
Mapa de evidencia
La información relevante reunida y contrastada para que la lectura no dependa de recuerdos, intuiciones o versiones aisladas.
- Logs y datos
- Flujos reales
- Arquitectura
- Entrevistas
Diagnóstico causal
Separación entre síntomas, incidencias puntuales, deuda acumulada y causas estructurales con su impacto asociado.
- Hallazgos
- Causas
- Dependencias
- Impacto
Escenarios de decisión
Alternativas viables comparadas desde continuidad, riesgo, coste de oportunidad, capacidad interna y evolución futura.
- Mantener
- Corregir
- Sustituir
- Reconstruir
Plan de actuación
Urgencias, mejoras estructurales, responsables, secuencia y criterios para ejecutar sin perder el contexto recuperado.
- Prioridades
- Quick wins
- Roadmap
- Criterios de éxito
04. Secuencia de trabajo
De la incertidumbre a una operación controlable.
La secuencia se adapta al contexto, pero mantiene una lógica: comprender antes de comprometer, decidir antes de dispersar y comprobar antes de dar por terminado.
Definir qué decisión debe desbloquearse.
Acordamos qué duele, a quién afecta, qué hipótesis existen y qué decisión debería poder tomar la empresa al finalizar.
Observar sistema y operación.
Reviso arquitectura, datos, rendimiento, seguridad, procesos, personas y proveedores según el caso. Contrasto documentación con el trabajo real.
Relacionar los hallazgos.
Separo incidencias puntuales, deuda acumulada y causas estructurales. Valoro impacto, urgencia, dependencia y coste de no actuar.
Construir una salida viable.
Presento alternativas, renuncias, prioridades y una ruta de actuación. Si continúa el proyecto, el diagnóstico se convierte directamente en dirección de la ejecución.
05. Control de la intervención
Medir lo que demuestra que el trabajo está cambiando algo.
No convierto una herramienta ni una entrega en resultado. Los indicadores se eligen según el problema y se comparan con el punto de partida.
Frecuencia y patrón de fallos
Cuándo ocurre, en qué condiciones, cuántas áreas afecta y qué relación guarda con cambios, carga o dependencias.
Coste operativo observable
Tiempo de espera, retrabajo, pasos manuales, correcciones y personas necesarias para sostener el estado actual.
Riesgo y exposición
Datos comprometidos, puntos únicos de fallo, dependencia de proveedores y consecuencias de una interrupción o mala decisión.
Capacidad de decisión
Hipótesis confirmadas o descartadas, alternativas comparables y número de decisiones que dejan de estar bloqueadas.
Evidencia
- Logs
- Lighthouse
- Datos
- Flujos reales
Análisis
- Arquitectura
- Rendimiento
- Seguridad
- Dependencias
Decisión
- Escenarios
- Riesgos
- Impacto
- Hoja de ruta
06. Evidencia relacionada
Experiencia aplicada, explicada con contexto.
Casos que muestran capacidades relacionadas con esta intervención. Sin cifras fuera de contexto ni resultados que no pueda defender.
Arte21
Una auditoría reveló problemas de rendimiento, estabilidad, seguridad, datos y arquitectura; el diagnóstico permitió decidir qué debía reconstruirse.
Dirección de Tecnología e InnovaciónVer caso completoKiuro Hub
Herramienta que combina señales técnicas y contexto de negocio para producir una primera lectura útil antes de una intervención humana completa.
Diseño y desarrollo del sistemaVer caso completo07. Criterio de éxito
Qué debe haber cambiado al terminar.
El problema deja de depender de opiniones y cuenta con una explicación sustentada y compartida.
Dirección puede comparar alternativas y decidir entendiendo riesgos, dependencias y renuncias.
Las urgencias quedan separadas de las mejoras estructurales y ordenadas por impacto.
El siguiente equipo recibe contexto, prioridades y criterios suficientes para actuar sin repetir la investigación.
Lo que esta intervención no pretende ser.
- No es una auditoría automática ni una lista genérica de buenas prácticas.
- No garantiza encontrar una causa única cuando el problema combina varias dependencias.
- No sustituye pruebas especializadas legales, financieras o de ciberseguridad forense cuando sean necesarias.
- No termina en una recomendación cerrada antes de escuchar a las personas que operan el sistema.
08. Preguntas antes de empezar
Lo que conviene aclarar antes de trabajar juntos.
01¿Qué acceso necesitas?+
Solo el necesario para responder la pregunta acordada: documentación, métricas, sistemas, proveedores y conversaciones con las personas implicadas. El acceso se amplía por evidencia, no por rutina.
02¿Recibiremos un informe técnico?+
Sí habrá evidencia y documentación, pero la entrega principal es una lectura utilizable por dirección: causas, impacto, alternativas, prioridades y criterios de decisión. El detalle técnico queda disponible para quien deba ejecutar.
03¿Puedes diagnosticar un proyecto, no solo un sistema?+
Sí. Un proyecto puede estar bloqueado por arquitectura, alcance, proveedores, gobierno, capacidad del equipo o decisiones pendientes. La lectura incluye tanto la tecnología como la forma en que se está dirigiendo.
04¿Tienes que ejecutar después la solución?+
No. Puedo entregar el diagnóstico a un equipo interno o a otro proveedor. Si continúo, el contexto recuperado se convierte en dirección y ejecución sin reiniciar el análisis.
09. Siguiente paso
El resultado no es un informe para archivar. Es una base para decidir y continuar.
No necesitas llegar con una solución definida. Cuéntame qué está ocurriendo, qué impacto tiene y qué decisión no consigues cerrar.
Cuéntame tu situación