Toda implementación de ITSM tiene un momento, normalmente unas seis semanas después de la puesta en marcha, en el que el responsable del servicio de asistencia envía el primer informe trimestral de SLA al CIO y nota en silencio que las cifras están mal. No por mucho: un punto porcentual aquí, un incumplimiento fuera de lugar allá, pero mal. El patrón es siempre el mismo: una incidencia abierta a las 16:55 del viernes anterior a Kurban Bayramı, marcada como incumplida el lunes por la mañana, cuando en realidad ningún técnico estuvo de guardia. La política de SLA decía "de 9 a 5, de lunes a viernes", el calendario decía que el Ramazan Bayramı caía en miércoles, y en algún punto entre esos dos hechos un ticket se coló por las grietas.
El calendario de SLA ingenuo —el que trae por defecto casi todo ITSM— es lo que provoca esto. Es la fuente más común de informes de SLA poco fiables, y tiene solución. Este artículo recorre el modelo de calendario que usamos y recomendamos, y las cuatro categorías de complicación que cualquier calendario en producción tiene que manejar.
El valor por defecto ingenuo: "de 9 a 5, de lunes a viernes"
La mayoría de las herramientas de ITSM, de fábrica, ofrecen un calendario de SLA de horario laboral con este aspecto:
- De lunes a viernes, de 09:00 a 17:00.
- Fines de semana excluidos.
- Una lista corta de "días festivos" que alguien tiene que acordarse de actualizar cada diciembre.
Esto está bien para una empresa pequeña donde todo el equipo de TI vive en la misma ciudad, trabaja el mismo horario y toma los mismos días festivos. No está bien en ningún otro caso. En el mundo real, al menos cuatro categorías de complicación rompen este modelo en el primer año:
- Días festivos que se desplazan: la mayoría de los festivos religiosos turcos se basan en el calendario lunar y se adelantan entre 10 y 11 días cada año.
- Modelos de turnos: un NOC 24/7 no respeta ningún "horario laboral".
- Ausencias de técnicos: el reloj del SLA sigue corriendo, esté o no el técnico asignado en su puesto.
- Operaciones multirregión: Estambul abre a las 09:00 hora Europe/Istanbul; Londres abre a las 09:00 hora Europe/London; al ticket P1 no le importa.
Vamos con cada una por separado.
1. Los días festivos turcos no son fechas fijas
El calendario oficial de festivos turcos tiene dos tipos de días:
- Festivos civiles fijos. Año Nuevo (1 de enero), Día de la Soberanía Nacional y del Niño (23 de abril), Día del Trabajo y la Solidaridad (1 de mayo), Conmemoración de Atatürk, Día de la Juventud y el Deporte (19 de mayo), Día de la Democracia y la Unidad Nacional (15 de julio), Día de la Victoria (30 de agosto), Día de la República (29 de octubre). Son reglas de fecha simples.
- Festivos religiosos móviles. El Ramazan Bayramı (3,5 días) y el Kurban Bayramı (4,5 días) se fijan según el calendario lunar hégira y se desplazan cada año gregoriano. En 2026 el Ramazan Bayramı va del 20 de marzo (medio día) al 23 de marzo; en 2027 empieza alrededor del 10 de marzo. El Kurban Bayramı de 2026 va del 27 de mayo (medio día) al 31 de mayo; en 2027 alrededor del 17 de mayo.
La regla del medio día importa. El Consejo de Ministros suele declarar el día laborable anterior a un bayram como medio día festivo oficial (arefe), en el que las oficinas públicas cierran a las 13:00. Los servicios de asistencia del sector privado varían: algunos siguen el medio día del gobierno, otros observan jornada completa, otros cierran por completo. Sea cual sea la política que siga su organización, el calendario de SLA tiene que codificarla explícitamente. Un medio día no es "la mitad del horario laboral"; es una ventana concreta que empieza a la hora de apertura habitual y termina a las 13:00.
Además de esto, la Presidencia turca ocasionalmente declara un festivo ad hoc: el día después de una victoria futbolística nacional, un día de luto de emergencia, o un puente entre un festivo fijo y un fin de semana. Estos no pueden precargarse en ningún calendario. El modelo de calendario de SLA debe permitir insertar un festivo puntual con 24 horas de aviso, sin tener que recalcular el historial.
Cualquier calendario de SLA que requiera que un ingeniero redespliegue código para añadir un día festivo fallará en su primer año de funcionamiento. El calendario tiene que ser datos, no configuración.
2. Los modelos de turnos no son "horario laboral"
Un centro de operaciones de red 24/7 no tiene horario laboral. Tiene turnos. El calendario de SLA de un servicio 24/7 debería ser completamente distinto del de un servicio de lunes a viernes. Y en la mayoría de las organizaciones reales, ambos coexisten: el NOC 24/7 gestiona incidencias de infraestructura P1 mientras que un servicio de 09 a 18 gestiona solicitudes L1. No se puede usar un único calendario para ambos.
Los tres patrones de turno que solemos modelar:
- Turno de día estándar. De lunes a viernes, de 09:00 a 18:00, con una ventana de almuerzo de una hora que no pausa el reloj del SLA (los técnicos se solapan durante el almuerzo a propósito).
- Día de horario extendido. De domingo a jueves (para servicios del sector financiero cuya actividad sigue una semana de domingo a jueves), de 07:00 a 21:00.
- Rotación las 24 horas. Tres turnos 24/7 con relevos a las 08:00, 16:00 y 00:00. El reloj del SLA corre de forma continua; el relevo es invisible para el cliente.
El modelo de calendario correcto se asocia a la política de SLA, no al servicio de asistencia en su conjunto. Una incidencia de infraestructura P1 se mide contra el calendario 24/7; una solicitud P4 de "por favor añádanme al buzón de grupo" se mide contra el calendario de 09 a 18. Misma organización, dos calendarios, enrutamiento ticket por ticket.
3. Ausencias de técnicos — el debate que nadie quiere tener
Aquí está la pregunta que tarde o temprano aparecerá en una reunión de revisión de SLA: un ticket P2 se asignó a Ayşe el viernes por la tarde. Ayşe tomó el lunes siguiente como día libre por vacaciones. El reloj del SLA siguió corriendo. Lo resolvió el martes por la mañana, cuatro horas laborables después de su vuelta, y el informe dice que incumplió. ¿Es justo?
Dos escuelas de pensamiento:
- La perspectiva del cliente. El cliente no sabe ni le importa que Ayşe estuviera de vacaciones. El SLA promete una respuesta en X horas laborables; la respuesta llegó tarde; el SLA se incumplió. La causa raíz: el enrutamiento debería haber movido el ticket fuera de Ayşe cuando se solicitaron las vacaciones.
- La perspectiva del equipo. Si la ausencia del técnico no pausa el SLA, los servicios de asistencia con alta utilización de vacaciones parecen artificialmente peores que los que desincentivan tomarlas. Ese es un incentivo perverso.
Nuestra recomendación, y el modelo que construimos por defecto:
- La ausencia del técnico no pausa el SLA del ticket asignado.
- En su lugar, el sistema de calendario dispara una reasignación cuando la ausencia de un técnico empieza con tickets activos en su cola.
- El ticket reasignado conserva su SLA original y su reloj original.
- El responsable recibe una advertencia en el momento de solicitar la ausencia si el técnico tiene tickets cuyo objetivo de SLA cae dentro del periodo de ausencia.
Esto fuerza el comportamiento correcto: la planificación de ausencias es responsabilidad de gestión, y el informe de SLA refleja la experiencia del cliente, no la disposición interna de personal. El incentivo del equipo se preserva porque los tickets se mueven, no porque se pause el reloj.
4. Horas silenciosas por usuario
Un concepto aparte pero relacionado: algunas organizaciones quieren prometer al cliente "su ticket tendrá respuesta en cuatro horas laborables" y, al mismo tiempo, prometer al técnico "no recibirás notificaciones push entre las 22:00 y las 07:00, aunque el calendario de SLA esté corriendo". El ITSM moderno tiene que modelar ambas cosas por separado.
La distinción:
- Calendario de SLA = la promesa del negocio al cliente. Gobierna cuándo corre el reloj.
- Calendario de notificaciones por usuario = la preferencia personal de push/correo del técnico. Gobierna si suena el teléfono.
Estos entrarán en conflicto. Una incidencia P1 abierta a las 03:00 en un calendario 24/7 es un incumplimiento genuino si nadie la atiende. Si todos los técnicos de guardia tienen las notificaciones silenciadas, el ticket espera hasta las 07:00 y el reloj de cuatro horas del cliente expira. La respuesta no es fusionar ambos conceptos; es modelar la rotación de guardia como un calendario distinto que anula las horas silenciosas personales durante la ventana de guardia.
5. Multirregión y zonas horarias
Una organización con oficinas en Estambul, Ankara y Londres no tiene un único día laborable: tiene tres que se solapan. Si el calendario de SLA se almacena en la hora local del servidor, las transiciones de horario de verano romperán silenciosamente los informes dos veces al año. Si se almacena en UTC, el horario laboral parecerá desplazarse para los usuarios en zonas distintas a menos que la interfaz lo maneje con cuidado.
Nuestra regla: todas las entradas del calendario se almacenan en UTC, y cada calendario lleva su propia zona horaria de visualización. El cálculo del SLA corre contra UTC; la interfaz se renderiza contra la zona horaria del calendario. Los usuarios en una zona horaria distinta siguen viendo la hora de apertura correcta para el calendario que están consultando.
Un P1 levantado a las 08:55 hora Europe/Istanbul contra un calendario de Estambul está dentro del horario laboral. El mismo ticket, si se levanta a las 08:55 hora Europe/London contra el calendario de Londres, todavía no está dentro del horario laboral (Londres abre a las 09:00 GMT = 11:00 hora Europe/Istanbul en invierno, 12:00 en verano). El enrutamiento es lo que decide qué calendario se aplica.
6. Ventanas de cambio de emergencia
La gestión de cambios añade una complicación más. Un cambio de emergencia en un sistema de producción puede requerir que el servicio de asistencia pause el SLA de cualquier ticket cuya resolución dependa de ese sistema. Este es el único caso legítimo de suspensión de SLA iniciada por un responsable.
La regla que implementamos:
- Un cambio de emergencia es un objeto de primera clase con una ventana de inicio y fin.
- Cualquier ticket marcado como depende de CI X, donde CI X se ve afectado por el cambio, tiene su reloj de SLA pausado durante la duración de la ventana de cambio.
- La pausa se registra con el ID del cambio, de modo que el rastro de auditoría muestre exactamente qué ticket se pausó por qué cambio.
- Cuando el cambio se cierra, todos los tickets pausados se reanudan automáticamente.
Esto no es una forma de ocultar incumplimientos. Es una forma de modelar el hecho de que la resolución fue genuinamente imposible durante un corte controlado.
Uniéndolo todo
El modelo de calendario completo, a nivel de entidades, tiene este aspecto:
| Entidad | Propósito | Ejemplo |
|---|---|---|
| WorkCalendar | La promesa del negocio. Se asocia a las políticas de SLA. | "Estambul 09-18", "NOC 24/7", "Londres 09-17" |
| WorkCalendarWeek | Ventana semanal recurrente por calendario. | Lunes-Viernes, 09:00-18:00 Europe/Istanbul |
| WorkCalendarHoliday | Excepción de día completo o medio día. Se aplica una vez. | 10-03-2027 Ramazan Bayramı Día 1 (cierre total) |
| WorkCalendarOverride | Regla ad hoc insertada con poco preaviso. | 14-11-2026 puente, cerrado |
| OnCallRotation | Quién está localizable por turno; anula las horas silenciosas personales. | Ayşe noche del lunes, Mehmet noche del martes, ... |
| UserSilentHours | Preferencia personal de notificaciones. | Bora: sin push 22:00-07:00 salvo si está de guardia |
| SlaPauseWindow | Pausa explícita provocada por un cambio de emergencia o una transición de estado. | CI-4728 cambio #331: pausa 19-09-2026 20:00 a 22:00 |
Estas son preocupaciones separadas, y se relacionan de forma predecible. El cálculo del SLA lee WorkCalendar más WorkCalendarHoliday más WorkCalendarOverride más SlaPauseWindow. La capa de notificaciones lee OnCallRotation más UserSilentHours. Los informes pueden segmentarse por calendario, por motivo de pausa o por causa de incumplimiento, porque cada dato se almacena, no se infiere.
Por qué esto importa para los informes
Un calendario bien diseñado responde a la pregunta que siempre surge en la segunda o tercera revisión trimestral: ¿por qué incumplió el ticket #4728? La respuesta tiene que ser algo más que "porque sí". Idealmente, al abrir el ticket se muestra el panel de SLA, y ese panel muestra exactamente qué calendario se aplicó, qué ventanas estaban abiertas, qué pausas ocurrieron y cuántos minutos laborables transcurrieron antes de la respuesta. Si la pausa fue provocada por un cambio, el ID del cambio queda enlazado. Si el técnico estaba de baja y el ticket se reasignó, la reasignación aparece en la línea de tiempo.
El objetivo de modelar esto correctamente no es el perfeccionismo. Es que los informes de SLA se examinan con lupa. Cuando el CIO pregunta por qué bajó el porcentaje de cumplimiento P2, el equipo de operaciones tiene una respuesta defendible, con los tickets, calendarios y pausas concretos que provocaron el cambio, o no la tiene, y el informe de SLA se convierte en objeto de duda en lugar de en una herramienta.
La implementación de LinaDesk, brevemente
LinaDesk modela cada una de las entidades de la tabla anterior como agregados de primera clase del Dominio. WorkCalendar es el ancla; WorkCalendarHoliday y WorkCalendarOverride son registros hijos; SlaPolicy referencia un WorkCalendarId. El cálculo del SLA es una función pura de las transiciones de estado de un ticket y las entidades de calendario visibles en cada transición. Como las pausas se almacenan como registros explícitos, reproducir el cálculo del SLA para cualquier ticket histórico produce hoy la misma respuesta que el día en que se cerró, que es lo que quieren los equipos de auditoría, y que no es cierto en los sistemas de ITSM que recalculan contra el calendario actual.
El ticket del Ramazan Bayramı del inicio de este artículo, en este modelo, no es un incumplimiento. El ticket se abre a las 16:55 del último día laborable antes del Bayram. El WorkCalendarHoliday de los cuatro días del Bayram marca el calendario como cerrado. El reloj del SLA solo cuenta los cinco minutos laborables que quedan antes de las 17:00 ese viernes, y luego se reanuda a las 09:00 del primer día laborable después del Bayram. La ventana de respuesta sobrevive.
Vea el modelo de calendario en la demo
El panel de demo de LinaDesk tiene tres calendarios preconfigurados, un día festivo a mitad de Bayram y una ventana de pausa por cambio de emergencia deliberada, así puede ver cómo maneja cada caso el informe de SLA.
Abrir el panel de demo