La respuesta breve
El Health Check es un diagnóstico basado en evidencias con una duración de dos a seis semanas, que culmina en tres entregables: una lista de hallazgos clasificados por severidad, un plan de "Quick Wins" a 30 días y una hoja de ruta para inversiones profundas. Lo que lo hace valioso no es la amplitud del escaneo, sino la evidencia adjunta a cada hallazgo —un número, un log o una grabación de pantalla—, ya que sin ella la discusión se convierte de nuevo en un debate de opiniones.
Los siete ejes de revisión
| Eje | Qué se revisa en la práctica | Fuente de la evidencia |
|---|---|---|
| Proceso y Adopción | ¿El proceso documentado es el proceso ejecutado? | Historial de inicio de sesión, uso de campos, observación de usuarios |
| Modelo de Datos | Objetos redundantes, campos sin uso, relaciones duplicadas | Uso de campos, Metadata API, consultas de muestreo |
| Automatizaciones | Solapamientos entre Flows, Triggers y Process Builder antiguo | Metadatos, Logs de depuración, análisis del orden de ejecución |
| Permisos y Seguridad | Perfiles sobrecargados, Reglas de Compartición contradictorias, acceso excesivo | Security Health Check, asignaciones de Permission Sets |
| Integraciones | Límites de API, fallos recurrentes, manejo de errores | Monitoreo de Eventos, logs de Middleware |
| Rendimiento | Tiempos de carga, consultas pesadas, Batch atascado | Lightning Usage App, Apex Jobs |
| Costo y Licencias | Licencias no utilizadas, Almacenamiento, servicios duplicados | Informe de licencias, factura vs. uso real |
Cómo se califica la severidad
Una calificación arbitraria hace que el informe carezca de valor. La metodología efectiva es la siguiente: cada hallazgo recibe dos puntuaciones del 1 al 5 — impacto (qué sucede al negocio si no se aborda) y frecuencia (cuántas veces al mes se manifiesta). El producto de estas puntuaciones determina la prioridad, no una estimación de cuán "feo" sea el código. Un hallazgo con una puntuación de 20 o más se aborda de inmediato; entre 12 y 19 se incluye en el próximo trimestre; por debajo de 12 se registra y no se aborda, a menos que su corrección sea económica mientras se realiza otro trabajo.
La distinción más importante en el informe es entre síntoma y raíz. "Los usuarios no completan el campo de razón de pérdida" es un síntoma; la raíz podría ser que el campo no es obligatorio, que los valores no son relevantes para el área, o que nadie revisa el informe basado en él. Corregir solo el síntoma —haciendo el campo obligatorio— genera datos deficientes en lugar de datos ausentes.
Qué se obtiene al finalizar
Un entregable adecuado incluye un documento de hallazgos con evidencia para cada línea, una matriz de severidad, un plan a 30 días donde cada elemento es ejecutable sin cambios arquitectónicos, y una hoja de ruta para uno o dos trimestres con estimaciones de esfuerzo aproximadas. Además, se requiere un Registro de Decisiones de tres a cinco determinaciones que la organización debe tomar —por ejemplo, si consolidar dos unidades de negocio en una sola Org—, ya que sin ellas la hoja de ruta carecería de fundamento.
Una ampliación sobre la decisión posterior al diagnóstico se encuentra en Reescribir frente a Refactorizar y en Priorización de la deuda técnica.
Riesgos comunes y acciones preventivas
El primer riesgo es un informe que se interpreta como una lista de acusaciones. Si los hallazgos se formulan como críticas a un equipo interno, la organización se pone a la defensiva y no corrige. Una formulación correcta se centra en la situación y el costo de la inacción, no en responsabilidades históricas.
El segundo riesgo es una revisión que termina sin un responsable asignado. Cada hallazgo debe tener el nombre de una persona y una fecha límite, de lo contrario, el informe se une a una carpeta que nadie abre. El tercer riesgo es una amplitud excesiva: un diagnóstico que intenta cubrir siete ejes con total profundidad en dos semanas genera una imagen superficial de todos ellos. Es preferible elegir tres ejes para profundizar y marcar el resto para la siguiente ronda.
Cómo se mide el éxito
Un Health Check es exitoso si, en un plazo de 60 días, se ha ejecutado al menos el 70% de los elementos del plan de 30 días, si la dirección ha aprobado un presupuesto para al menos una inversión profunda, y si dos indicadores operativos —por ejemplo, el índice de fallos de integración o el tiempo de carga de una pantalla clave— han mejorado de forma medible respecto a la base establecida al inicio del diagnóstico.
El siguiente paso
Antes de solicitar una revisión, es recomendable preparar tres elementos: una lista de los procesos de negocio críticos, acceso de lectura a los logs y metadatos, y los nombres de tres usuarios reales cuyo trabajo pueda ser observado. Estos tres puntos acortan el diagnóstico en aproximadamente una semana y mejoran significativamente la calidad de los hallazgos.