Cuando todos los procesos internos se declaran críticos, la organización acaba con alertas constantes, guardias difíciles de sostener y compromisos que nadie puede cumplir. El problema no es solo técnico: se diluye la prioridad real de una caída y se encarece la operación de aplicaciones, integraciones y datos que quizá admiten espera, reproceso o una alternativa manual.
La decisión útil no consiste en etiquetar un sistema como «importante». Consiste en acordar qué consecuencia de negocio es inaceptable, durante cuánto tiempo y bajo qué condiciones. A partir de ahí, algunos procesos requerirán un acuerdo de nivel de servicio (SLA); otros funcionarán mejor con una expectativa operativa, un objetivo interno revisable o simplemente buenas prácticas de soporte.
Este marco permite justificar prioridades ante producto, negocio y tecnología sin elegir cifras por intuición ni convertir cada petición en una obligación de disponibilidad permanente.
SLA, objetivo operativo y buena práctica: compromisos distintos
Un SLA es un compromiso explícito sobre un servicio definido. Normalmente establece alcance, horario, métricas, responsabilidades, exclusiones y un mecanismo de revisión o escalado. No equivale a prometer que nunca habrá incidencias: expresa qué nivel de funcionamiento se espera y cómo se gestionará el incumplimiento.
En operación interna, conviene distinguirlo de dos instrumentos más ligeros:
- Objetivo de nivel de servicio: una meta medible para orientar la operación, como completar una sincronización antes de una hora acordada. Puede revisarse sin tratar cada desviación como un incumplimiento contractual.
- Expectativa operativa: una norma de trabajo clara, pero menos rígida. Por ejemplo, revisar una cola de solicitudes en días laborables o publicar un informe al inicio de la jornada.
- Buena práctica: un procedimiento deseable, como monitorizar errores o documentar una recuperación manual. Es valioso, pero no debe presentarse como garantía si no hay capacidad, cobertura y responsables para sostenerlo.
La diferencia decisiva es la consecuencia. Si una interrupción bloquea ingresos, obligaciones operativas críticas o la atención a clientes y no existe una salida razonable, un SLA suele estar justificado. Si el equipo puede reprogramar la tarea, usar datos del día anterior o completar el trabajo manualmente, una expectativa operativa será a menudo más honesta y eficiente.
No asigne un SLA por la visibilidad del solicitante o por la antigüedad del sistema. Asígnelo por el daño verificable de no prestar el servicio dentro de una ventana concreta.
Las cinco preguntas para clasificar cada proceso
Antes de discutir porcentajes de disponibilidad o tiempos de respuesta, clasifique el proceso con las mismas preguntas para todos los equipos. La conversación deja de ser una negociación abstracta y se convierte en evaluación de riesgo.
- ¿Cuál es el impacto si no funciona? Describa el efecto en pedidos, operaciones, cumplimiento, usuarios o decisiones. Evite respuestas genéricas como «es muy importante». Identifique qué acción no puede realizarse y quién queda bloqueado.
- ¿Cuál es la ventana real de uso? Un portal usado para cursar pedidos durante todo el día no tiene la misma necesidad que una carga de datos nocturna. Defina días, franjas horarias, cierres y picos conocidos.
- ¿De qué depende? Liste aplicaciones, APIs, proveedores, credenciales, redes, datos de origen y equipos propietarios. Un compromiso solo puede cubrir aquello que el equipo puede observar y operar.
- ¿Existe una alternativa manual o degradada? Determine si se puede registrar información temporalmente, aceptar pedidos por otra vía, consultar una copia previa o reintentar una tarea. Valore también la capacidad real de esa alternativa, no solo su existencia teórica.
- ¿Qué pérdida de datos o retraso es tolerable? Distinga indisponibilidad de integridad. Puede que un proceso acepte dos horas de retraso, pero no una transacción duplicada, datos incompletos o la pérdida de cambios.
Documente las respuestas junto con un propietario de negocio y uno técnico. Si no hay acuerdo sobre el impacto o la tolerancia, todavía no hay base para establecer un nivel de servicio; hay una decisión de negocio pendiente.
Una matriz de criticidad útil para aplicaciones e integraciones
Una matriz sencilla evita que la clasificación dependa de quién eleva la petición. Puntúe cada dimensión como baja, media o alta: impacto, sensibilidad a la ventana de uso, ausencia de alternativa, riesgo de datos y complejidad de dependencias.
- Criticidad alta: impacto directo e inmediato, ventana estrecha o continua, sin alternativa viable y con riesgo significativo de pérdida o inconsistencia. Requiere SLA, monitorización, escalado definido y pruebas de recuperación.
- Criticidad media: el retraso afecta al trabajo o a decisiones relevantes, pero existe un modo degradado o un margen de recuperación. Requiere objetivos operativos medibles, seguimiento de errores y revisión periódica.
- Criticidad baja: el proceso mejora la eficiencia, pero puede esperar, reprocesarse o sustituirse temporalmente. Bastan una expectativa operativa, priorización en el backlog y soporte en horario acordado.
La categoría debe aplicarse al servicio concreto, no a toda la aplicación. Una misma plataforma puede contener un portal transaccional crítico, un informe de consulta diferible y una exportación mensual. Un único SLA global ocultaría estas diferencias y forzaría costes innecesarios.
Ejemplo de clasificación
Un portal de pedidos puede ser de criticidad alta si los usuarios no pueden cursarlos por otro canal y una interrupción frena la operación. La sincronización nocturna de catálogo podría ser media si puede reintentarse antes de la apertura o si el catálogo anterior permite operar temporalmente. Un informe interno de seguimiento puede ser bajo si se consulta una vez al día y sus datos pueden llegar con retraso.
Este ejemplo no determina una categoría universal. Si la sincronización alimenta precios obligatorios o si el informe activa una decisión regulada, la evaluación cambia. La clasificación depende de la consecuencia y la ventana, no del tipo de tecnología.
Qué debe incluir un SLA interno sostenible
Un SLA útil debe ser específico y operable. Prometer «alta disponibilidad» o «atención rápida» crea ambigüedad en el momento de una incidencia. En cambio, un documento breve puede definir con precisión qué se presta y cómo se mide.
- Alcance: proceso, interfaces, usuarios y resultado esperado. Indique qué componentes quedan fuera.
- Horario de servicio: franja de operación comprometida, calendario aplicable y ventanas de mantenimiento.
- Métricas: disponibilidad del proceso, plazo de detección, tiempo de primera respuesta, tiempo de restauración o retraso máximo admisible. Mida resultados, no solo actividad del equipo.
- Responsables: propietario de negocio, propietario técnico, equipo que atiende el incidente y responsables de cada dependencia.
- Exclusiones: datos de origen no recibidos, caídas de terceros, cambios no aprobados o uso fuera de capacidad prevista. No son excusas: delimitan el control real.
- Escalado: canal de aviso, severidades, personas que deciden medidas de contingencia y comunicación a afectados.
Evite copiar objetivos de proveedores o de otros productos. Un valor solo es defendible si responde a una necesidad de negocio y si la arquitectura, observabilidad y capacidad de respuesta permiten cumplirlo. Las prácticas de ingeniería de fiabilidad popularizadas por Google distinguen entre indicadores, objetivos y acuerdos precisamente para evitar que una aspiración se convierta en una promesa imposible.
Cómo fijar métricas sin elegir cifras arbitrarias
Empiece desde la necesidad, no desde un porcentaje. Pregunte: «¿Cuál es el último momento en que este resultado debe estar disponible para evitar el daño identificado?». Esa respuesta define un límite operativo. Después contraste el límite con los datos históricos, las dependencias y la capacidad de recuperación.
Para disponibilidad, mida la capacidad de completar la acción relevante, no solo que una página responda. Para una integración, puede ser más útil medir el porcentaje de ejecuciones completadas y el retraso de los registros que el estado de un servidor. Para recuperación, separe dos decisiones:
- Objetivo de tiempo de recuperación: cuánto puede durar la interrupción antes de restaurar el servicio o activar una alternativa.
- Objetivo de punto de recuperación: cuánta información se puede perder o quedar pendiente de reconciliación tras el incidente.
Defina además un presupuesto de error operativo: el margen de incumplimiento que puede tolerarse durante un periodo antes de priorizar fiabilidad sobre nuevas mejoras. Si el margen se agota repetidamente, no basta con endurecer el SLA; hay que revisar diseño, dependencia externa, automatización, capacidad de soporte o incluso la necesidad del proceso.
Dependencias, cambios y señales para revisar el compromiso
El error más frecuente es comprometer un resultado extremo a extremo cuando varias partes no están bajo el mismo control. Si una API externa, un equipo de datos o un proveedor de comunicaciones participa en el flujo, documente la dependencia y acuerde su propio objetivo. Si no existe ese acuerdo, formule el compromiso de forma condicionada: qué hará el equipo cuando reciba datos válidos o cuando el tercero restablezca el servicio.
Revise cada clasificación cuando aparezca alguna de estas señales:
- El proceso empieza a utilizarse en horarios nuevos o por más equipos.
- Desaparece la alternativa manual o deja de ser viable por volumen.
- Aumentan los errores repetidos, los reprocesos o las intervenciones manuales.
- Se añaden integraciones, cambios de datos o nuevos puntos de fallo.
- Una incidencia revela que el impacto real fue mayor o menor que el documentado.
Establezca una revisión periódica y también una revisión posterior a incidencias relevantes. La salida no tiene por qué ser endurecer el compromiso: puede consistir en reducir alcance, crear un modo degradado, mejorar una alerta, separar un servicio crítico de una tarea diferible o rebajar un SLA que ya no responde al uso real.
Checklist para tomar y mantener la decisión
- Describa el resultado de negocio que entrega el proceso.
- Defina impacto, ventana de uso, alternativa, dependencias y tolerancia a pérdida o retraso.
- Clasifique el proceso por criticidad, no la aplicación completa.
- Asigne SLA solo a los resultados cuyo incumplimiento tenga un daño no aceptable.
- Para el resto, defina un objetivo operativo o una expectativa de soporte clara.
- Compruebe que las métricas se pueden observar y que hay responsables para actuar.
- Documente exclusiones y contingencias antes de que ocurra una incidencia.
- Revise el compromiso ante cambios de uso, dependencia o impacto.
La madurez no consiste en tener más SLA. Consiste en que cada compromiso refleje una necesidad real, pueda medirse y tenga una respuesta operativa viable. Esa disciplina protege tanto a quienes dependen del servicio como a los equipos que deben mantenerlo.