5.1.1. Riesgo y conformidad & 5.1.2. Cambios

5.1.1. Riesgo y conformidad.

Riesgo se define como la incertidumbre del resultado, ya sea positivo o negativo. La gestión de riesgos requiere la identificación y el control de la exposición al riesgo, lo que puede tener un impacto en el logro de una organización de los objetivos empresariales.

La gestión del riesgo es un aspecto fundamental de la Gestión del Servicio. Los servicios reducen los riesgos para el negocio del cliente, pero también generan riesgos para los proveedores de servicios. Los clientes pueden compensar a los proveedores de servicios por estos riesgos de diversas maneras, pero fundamentalmente con el pago de los servicios (algo que no es posible con proveedores del tipo I).

Riesgos para los proveedores de servicios

Los riesgos para los proveedores de servicios surgen cuando la incertidumbre del negocio del cliente se combina con incertidumbres en sus operaciones. Estos riesgos tienen un efecto negativo a lo largo de las distintas fases del Ciclo de vida. Es conveniente que los riesgos se comuniquen en términos financieros, ya que se pueden usar como indicadores en lugar de medidas.

Transferencia de Riesgo                          

No solo está el reducir los riesgos para el negocio, sino también la transferencia de riesgo para el prestador de servicios. 

ITIL distingue los siguientes tipos de riesgos:

·      Riesgos de contrato (un contrato contiene acuerdos formales y legalmente vinculantes entre clientes y proveedores de servicios): Los riesgos de que el proveedor de servicios haga imposible el cumplimiento de acuerdos contractuales son riesgos estratégicos, ya que no sólo suponen una amenaza para la producción sino que también deterioran la confianza de cara al futuro. El efecto de los riesgos de contrato y los peligros subyacentes se puede extender a más de una función del proceso. El cliente no hace distinciones entre las diversas fuentes de riesgo. Una gestión eficaz de los riesgos exige una buena coordinación durante todo el Ciclo de vida.

·      Riesgos de diseño: Los clientes esperan que los servicios tengan un efecto concreto sobre el rendimiento de los activos, que desde su punto de vista es una funcionalidad. Siempre existe el riesgo de que los servicios den resultados no deseados. Este riesgo de rendimiento suele ser resultado de un diseño deficiente.

·      Riesgos operativos: Todas las organizaciones deben hacer frente a riesgos operativos. Desde el punto de vista de la Gestión del Servicio se distinguen dos tipos: los riesgos para las unidades de negocio y los riesgos para las unidades de servicio.

·      Riesgos de mercado: Una buena Gestión del Servicio contribuye a reducir los riesgos competitivos a través del aumento de la escala y el alcance de la demanda de un Catálogo de Servicios. Otra posibilidad consiste en modificar los contenidos del Catálogo de Servicios para ofrecer a los clientes la profundidad y flexibilidad que desean. Los riesgos de mercado se pueden reducir mediante: 

§  Diferenciación: Desde el punto de vista del cliente, los activos escasos y complementarios son los más interesantes. Los proveedores de servicios se pueden concentrar en ofrecer los activos importantes que otros no han proporcionado. Los mercados sin servicio o con servicio insuficiente son los que presentan las mejores oportunidades.

§  Consolidación: La consolidación de la demanda reduce los riesgos financieros para los proveedores de servicios, así como los riesgos financieros para el cliente.

§  ITIL se centra en brindar servicios de alta calidad para lograr la máximo satisfacción del cliente a un costo manejable. Para ello, parte de un enfoque estratégico basado en el triángulo procesos-personas-tecnología. En otras palabras: determina la forma de ejecutar procesos estándar ayudados de la tecnología para lograr la satisfacción de las personas, usuarios de los servicios de TI.

§  Manejo del riesgo:

§  De igual manera, dichos esfuerzos de TI se deben realizar con el mínimo riesgo posible que la organización determine. Así, se logra minimizar las posibilidades de que algo salga mal en la implantación de soluciones con proyectos TI.

5.1.2. Cambios.

Gestor de Cambio. Administra los cambios y los documentos que autorizan todos los cambios en la infraestructura de TI y sus componentes (los ítems de la configuración), a fin de mantener una cantidad mínima de defectos de interrupción sobre el funcionamiento y la operación. En el caso de más de profundos cambios, que implica la Junta Consultiva de Cambio (CAB).

·      Junta Consultiva de Cambios (CAB). Un grupo de personas que asesora al Gerente de Cambio en la Evaluación, priorización y programación de cambios. Este comité está formado únicamente por representantes de todas las áreas dentro del Proveedor de Servicios de TI, los negocios, y terceros, como proveedores.

·      Propietario del Cambio. La persona que respalda un cambio y la negociación de un presupuesto para su aplicación. Normalmente los cambios son propiedad de Servicio de Gestión de funciones (por ejemplo, el problema o la capacidad Manager) o miembros de la administración de TI.

·      Cambio de Emergencia Junta Consultiva (ECAB). Un subconjunto de la Junta Consultiva de Cambio que tomar decisiones acerca de emergencia de alto impacto cambios. Composición de la ECAB podrá decidirse en el momento en una reunión se le llama, y depende de la naturaleza de la emergencia el cambio.

Aprobación y Planificación del cambio.

La planificación es esencial para una buena gestión del cambio.

Los sistemas de gestión de la información son muy susceptibles a los cambios de configuración por las sofisticadas interrelaciones entre todos los CIs involucrados. Un cambio aparentemente menor puede provocar una reacción en cadena con resultados catastróficos. Es imprescindible, como mínimo, disponer siempre de planes de back-out que permitan la recuperación de la última configuración estable antes del cambio. Pero esto obviamente no es suficiente.

Para su aprobación, el cambio se debe evaluar minuciosamente:

¿Cuáles son los beneficios esperados del cambio propuesto?

¿Justifican esos beneficios los costes asociados al proceso de cambio?

¿Cuáles son los riesgos asociados?

¿Disponemos de los recursos necesarios para llevar a cabo el cambio con garantías de éxito?

¿Puede demorarse el cambio?

¿Cuál será el impacto general sobre la infraestructura y la calidad de los servicios TI?

¿Puede el cambio afectar los niveles establecidos de seguridad TI?

En el caso de cambios que tengan un alto impacto, debe también consultarse a la dirección pues pueden entrar en consideración aspectos de carácter estratégico y de política general de la organización.

Una vez aprobado el cambio (en caso contrario se seguiría el proceso ya descrito para el caso de no aceptación) debe evaluarse si éste ha de ser implementado aisladamente o dentro de un "paquete de cambios", que formalmente equivaldrían a un solo cambio. Esto tiene algunas ventajas:

·      Se optimizan los recursos necesarios.

·      Se evitan posibles incompatibilidades entre diferentes cambios.

·      Sólo se necesita un plan de back-out.

·      Se simplifica el proceso de actualización de la CMDB y la revisión post-implementación.