El Sistema de Gestión de Conocimiento del Servicio (SKMS) es un conjunto de herramientas, información y datos. El SKMS contiene al Sistema de Gestión de la Configuración-CMS y este último a su vez puede tener una o varias Base de Datos de la Gestión de la Configuración-CMDB. Como se aprecia en la gráfica, una CMDB contiene la información de todos los Ítem de Configuración CI de un entorno TI y la relación o dependencia entre ellos, almacena datos físicos y lógicos fundamentales para el proceso de Gestión de la configuración de ITIL. Mientras una CMDB almacena todos los datos de los CI, el Sistema de Gestión de la Configuración actúa como interfaz para gestionarlos, mediante el uso de herramientas para la recopilación, almacenamiento, actualización, análisis y presentación de todo el conocimiento que un proveedor de servicios de TI necesita.
El Sistema de Gestión de Conocimiento del servicio es mucho más amplio de lo que nos imaginamos. En el se encuentra toda la información para la toma de decisiones de un proveedor de servicios TI, entre otras cosas se encuentra el portafolio de servicios, información estratégica y financiera, políticas y planes, acuerdos de servicios y mucha información generada en la operación del día a día como la gestión de incidentes, problemas, cambios, despliegues y demás…
Ahora bien, para que profundicemos un poco mas…El dueño del proceso es el encargado que el proceso cumpla con las expectativas y funcione de acuerdo a las necesidades de la organización, otras responsabilidades del Propietario del Proceso incluyen la supervisión de la calidad general del proceso, diseño y mejoramiento continuo del proceso y sus mediciones. ¡ITIL no es una camisa de fuerza! en algunas organizaciones el rol de Dueño del Proceso se fusiona con el rol de Gestor del Proceso, dependiendo del tamaño de la organización y la necesidad. Algunos ejemplos de Dueño del Proceso son: Dueño del Proceso de Gestión de Incidentes, Solicitudes, Problemas, Eventos y Acceso. Normalmente, el rol de Dueño del Proceso lo asume una persona de alto rango del área de TI.
Adicional, el dueño del servicio es responsable de un servicio específico dentro de una organización, independientemente de los componentes tecnológicos, procesos o de las personas. También tiene la obligación de cumplir con los SLA, por sus siglas en inglés Acuerdo de Nivel de Servicio. El dueño del servicio a menudo es el líder de un equipo de especialistas técnicos de un área de TI.
Operational Level Agreement (OLA), define los bienes o servicios que serán prestados y las responsabilidades de ambas partes. Por ejemplo, podría existir un OLA entre el Proveedor de Servicios de TI y el departamento de compras para obtener hardware en plazos acordados, otro ejemplo puede ser, entre el Service Desk y un Grupo de soporte para ofrecer Resolución de incidencias en los plazos establecidos.
Service Level Agreement (SLA), describe el Servicio de TI, documenta las metas de Niveles de Servicio y define las responsabilidades del Proveedor de Servicios de TI y del Cliente. A través de herramientas de gestión de servicios y con el análisis de las métricas definidas en los acuerdos de niveles de servicio, se establece el grado de cumplimiento del proveedor, normalmente se mide con base al número de casos registrados, frente a la solución dentro de los tiempos establecidos en el acuerdo. Hay que tener en cuenta que esto va más allá del número de casos, se miden también otros aspectos como por ejemplo tiempos de resolución de incidentes, latencia y disponibilidad en canales de comunicaciones y en general cualquier otro aspecto que afecte la experiencia del usuario. Dado que los usuarios tienen expectativas frente al uso de un servicio SIEMPRE hay un acuerdo de nivel de servicio ya sea explícito o implícito. La importancia de que sea explícito es que le permite a los usuarios aterrizar sus expectativas a al departamento de TI entender como será medido su desempeño.
Comité Asesor de Cambios, Solicitud de Cambio y flujo del proceso en ITIL
El Comité Asesor de Cambios o Change Advisory Board, CAB en inglés, está formado principalmente por representantes de las diferentes áreas de TI. Pueden hacer parte del comité consultores externos, representantes de los usuarios y proveedores de Software o Hardware, entre otros. Son funciones del Comité Asesor de Cambios, analizar, evaluar, priorizar, autorizar o rechazar e incluir cambios en el calendario de cambios. Los cambios deben ser analizados desde el punto de vista de negocio y técnico, e interpretar su impacto y riesgo en la disponibilidad de los servicios.
El Comité Asesor de Cambios de Emergencia autoriza o rechaza una solicitud de cambio urgente. Se recurre a este proceso cuando los procedimientos habituales de Gestión de Cambios no son aplicables, dada la acción inmediata requerida en casos de emergencia. Aunque a veces los cambios realizados con procedimientos de emergencias son el resultado de una deficiente planificación de la operación, estos son inevitables. Una afectación masiva de usuarios por causa de un incidente en una aplicación o servicio crítico de la organización, motivan al Gestor de Cambios a convocar una reunión urgente para analizar la solución o mitigación. Cabe anotar que le hecho que una solicitud sea categorizada como urgente simplemente le confiere una mayor prioridad, más no cambia los pasos del proceso, es decir Un cambio urgente no excluye su documentación y requisitos esenciales de control.
Una solicitud de cambio (Request for Change) o RFC por sus sigla en inglés incluye detalles del Cambio propuesto, riesgos e impactos en los servicios, recursos a utilizar, un plan de back out o plan de regreso a la versión anterior, prioridades (Muy alta-cambios urgente, Alta, Normal y Baja). Adicional a esto…Un Cambio tiene un Propietario del Cambio, que en muchos casos es también el que inicia el RFC. Normalmente, actúan como Propietarios de Cambio los propietarios de roles de la Gestión de Servicios de TI, por ejemplo el Gestor de Problemas o Gestor de la Capacidad o la Dirección de TI. Existen tres tipos de cambios, cambio estándar, de emergencia y normal, que veremos en detalle en la fase de Transición del Servicio.
La solicitud de cambio se realiza dentro del proceso de Gestión de Cambios de la fase de Transición del Servicio. Las actividades relacionadas al proceso de RFC son: Crear y registrar el RFC, revisar el RFC por parte del Comité Asesor de Cambios, el Comité Asesor diagnóstica, evalúa y autoriza la solicitud de cambio, planea las actualizaciones o despliegues con el Gestor de Cambios, con el apoyo del equipo ejecutor u operativo se ejecuta el cambio, posteriormente se revisa por parte del dueño del cambio los resultados para su respectiva aceptación y cierre.