Usted está aquí:
Gestionar versiones con registros vinculados para servicios de TI
Este ejemplo muestra cómo un gestor de versiones asocia incidentes, problemas y solicitudes de cambio a versiones programadas y de emergencia, y realiza un seguimiento de ellos en el Calendario de servicio de TI.
Ediciones necesarias
| Disponible en: Lightning Experience |
| Disponible en: Ediciones Enterprise, Performance y Unlimited con Agentforce IT Service. |
John, un gestor de versiones de Cumulus Bank, crea un registro de versión con estos detalles clave.
| Campo | Valor de ejemplo |
|---|---|
| Nombre | Versión quincenal del 1 de septiembre |
| Tipo de versión | Mayor |
| Fecha de inicio planificada | 1 de septiembre de 2025, 9:00 AM |
| Fecha de finalización planificada | 14 de septiembre de 2025, 6:00 PM |
| Nivel de riesgo | Medio |
| Prioridad | Normal |
| Resumen de cierre | Todos los cambios planificados se implementaron correctamente. |
Durante el periodo de dos semanas, John asocia todas las solicitudes de cambio planificadas, problemas e incidentes relacionados vinculados a la versión. Por ejemplo, John agrega una asociación de solicitud de cambio con estos detalles clave:
| Campo | Valor de ejemplo |
|---|---|
| Número de solicitud de cambio | CHG-0004567 |
| Descripción | Actualización de esquema de base de datos |
| Fecha de inicio (Estimada) | 5 de septiembre de 2025, 10:00 AM |
| Fecha de finalización (Estimada) | 5 de septiembre de 2025, 2:00 PM |
| Tipo de relación | Vinculado a la versión |
Unos días después, el 16 de septiembre de 2025, después de que se cerrara la versión quincenal, un fallo de VPN importante interrumpe el acceso de toda la organización. El incidente se clasifica como crítico y se crea un registro de problema para identificar la causa raíz. A continuación se registra una solicitud de cambio para implementar la solución.
Debido a que esperar a la siguiente versión programada retrasaría la resolución, John crea una versión de emergencia con estos detalles y asocia el incidente principal como el origen de la versión.
| Campo | Valor de ejemplo |
|---|---|
| Número de incidente | INC-0005678 |
| Descripción | Corte de VPN que afecta a toda la organización |
| ¿Es incidente mayor? | Sí |
| Prioridad | Crítico |
| Tipo de relación | Origen de la versión |
| Campo | Valor de ejemplo |
|---|---|
| Nombre | Versión de emergencia para problema de red |
| Tipo de versión | Emergencia |
| Fecha de inicio planificada | 16 de septiembre de 2025, 9:00 AM |
| Fecha de finalización planificada | 16 de septiembre de 2025, 6:00 PM |
| Nivel de riesgo | Alto |
| Prioridad | Crítico |
| Resumen de cierre | Corte de VPN resuelto con implementación de soluciones urgentes. |
El campo Nivel de riesgo no tiene ninguna regla predefinida. Sin embargo, los administradores pueden definir el campo creando sus propias reglas de negocio. En Cumulus Bank, una regla de negocio establece automáticamente el nivel de riesgo como Alto cuando el tipo de versión es Emergencia y la prioridad es Crítico.
En el Calendario de servicio de TI, la versión quincenal del 1 de septiembre aparece como una entrada de dos semanas y la versión de emergencia aparece como una entrada de un día. El calendario ayuda a las partes interesadas de John y Cumulus Bank a confirmar que las versiones están programadas en el plazo correcto, y también ver las implementaciones programadas y no programadas en una sola vista.
