Ir al contenido
ESEnoque Sousa
Sistema en producción · Uso internoDatos operativos · Producción interna

Inteligencia de Service Desk y motor de SLA

Detalles del proyecto

Por qué fue creado

Los registros de atención llegaban mediante diferentes APIs y archivos con historiales de estado inconsistentes. Una aritmética simple de SLA no podía representar de forma confiable el horario laboral, los feriados, las pausas del solicitante, el tiempo del proveedor y los trabajos reabiertos.

Lo que construí

Diseñé la ingesta incremental, el modelo analítico y las reglas de SLA; después conecté las vistas resultantes con las rutinas diarias del Service Desk, los equipos de campo y el liderazgo operativo.

Restricciones y compromisos

+

Restricciones que dieron forma al sistema

  • 01El modelo debía conservar el historial de sincronización y exponer fallas de calidad en lugar de normalizarlas silenciosamente.
  • 02Los relojes de SLA cambiaban según la prioridad, los feriados nacionales, las pausas, la responsabilidad del proveedor y los tickets reabiertos.
  • 03Los usuarios operativos y ejecutivos necesitaban diferentes niveles de detalle a partir del mismo conjunto de datos confiable.

Compromisos de diseño

  • 01La sincronización incremental con historial duradero fue más compleja que las recargas completas, pero hizo explicables los cambios y las brechas.
  • 02DuckDB mantuvo consultas analíticas rápidas y una operación sencilla para un producto interno, sin adoptar prematuramente un almacén de datos distribuido.
  • 03Las exportaciones controladas priorizaron la trazabilidad frente a copias irrestrictas de hojas de cálculo desconectadas del modelo de origen.

Otras decisiones de arquitectura

  • La ingesta incremental de APIs y archivos normaliza más de 32.000 registros en un modelo analítico con historial de sincronización y controles de calidad.
  • El dominio de SLA contempla políticas por prioridad, horario laboral, feriados nacionales, pausas del solicitante, tiempo del proveedor y reaperturas.
  • FastAPI y DuckDB sirven paneles React con mapas de calor, comparación de períodos, colas operativas y exportaciones controladas.
  • Los informes ejecutivos y de campo recurrentes conectan el producto con las rutinas reales de Service Desk, monitoreo e incidentes críticos.

Valor para la operación

Más de 32.000 tickets se convirtieron en un modelo operativo con control de calidad que sirve SLA, backlog, carga, mapas de calor e informes recurrentes de liderazgo desde una única fuente de verdad.

Principio de ingeniería

Un panel gana confianza antes de ganar atención: las personas actúan sobre una métrica solo cuando se pueden explicar su reloj, sus exclusiones y el historial de la fuente.