Transición de AMS y línea base del parque de aplicaciones
Caso de uso ilustrativo, no un caso de éxito.
Asumir aplicaciones que no construimos: inventariar el parque, acordar alcance y severidades, transferir el conocimiento y establecer la línea base del servicio antes de operarlo.
El problema
Las aplicaciones funcionan, pero las personas que las entendían ya no están o el proveedor actual se marcha. La documentación es parcial, las personalizaciones no están documentadas y nadie puede decir qué integraciones son críticas. El soporte no puede mejorarse hasta que primero se entienda.
Cómo funciona hoy
Un nuevo equipo de soporte hereda una cola de tickets y una unidad compartida. La transferencia de conocimiento ocurre en unas pocas llamadas con el equipo saliente. Las definiciones de severidad, el horario de servicio y las rutas de escalado se asumen a partir del contrato antiguo. Los primeros meses se dedican a redescubrir el parque de aplicaciones a través de incidencias.
Vea el escenario
Flujo de trabajo ilustrativo. Subtitulado.
Transcripción
- Las aplicaciones funcionan, pero las personas que las entendían se han ido. La documentación es parcial, las personalizaciones no están documentadas y nadie sabe qué integraciones son críticas.
- Inventariamos las aplicaciones, acordamos alcance y horario del soporte, documentamos procedimientos y lagunas, y fijamos la línea base inicial del servicio.
- Nada cambia en producción durante el descubrimiento. El responsable aprueba las definiciones antes de iniciar el servicio; los hallazgos alimentan un backlog de mejoras que él prioriza.
- Medido en cobertura del parque e incidencias por componentes desconocidos. Caso de uso ilustrativo. Hablemos del suyo.
Flujo de trabajo propuesto
- Inventariar el parque de aplicaciones: módulos, integraciones, personalizaciones, agentes y los entornos en los que se ejecutan, con evidencia obtenida de los sistemas y no de la memoria
- Acordar por escrito el alcance, las definiciones de severidad, el horario de servicio y las responsabilidades de escalado al proveedor antes de atender ningún ticket
- Transferir el conocimiento a runbooks y a una base de conocimiento aprobada, con las lagunas listadas en lugar de ocultas
- Fijar la línea base del servicio: volúmenes actuales de incidencias, tiempos de resolución, cadencia de versiones y riesgos conocidos
- Operar según las definiciones acordadas, registrar los hallazgos y proponer elementos de mejora para que el responsable los priorice
Dónde mantiene el control una persona
- El responsable aprueba el alcance, las severidades, el horario y las responsabilidades de escalado antes de que comience el servicio
- No se realiza ningún cambio en producción durante el descubrimiento; los hallazgos se registran, no se corrigen sobre la marcha
- El backlog de mejoras lo prioriza el responsable, no el equipo de soporte
La asignación a plataformas indica los entornos en los que evaluar esta idea. La implementación real depende de la configuración, las licencias, las API, los datos y los permisos. Los beneficios se expresan de forma cualitativa; las afirmaciones numéricas requieren una línea base documentada.