ITIL: Change Management

Estamos ante uno de los procesos mas famosos de ITIL. Change Management es junto Incident Management los procesos mas difundidos e implementados (no siempre bien) en las áreas de Tecnología Informática.

Ahora veamos de que trata Change Management...

CM es el proceso responsable de controlar el ciclo de vida de todos los cambios (para ver que es un cambio leer la entrada anterior).

¿Porque necesitamos controlar los cambios? En un mundo ideal para TI seriamos felices si tuviéramos toda nuestra infraestructura, aplicaciones y arquitectura estabilizada 100% y sin cambios. Lamentablemente esto no es real, continuamente la gente del negocio necesita de cambios de TI para poder desarrollar nuevos negocios, cumplir con nuevos requerimientos legales o satisfacer necesidades del cliente.
Como los cambios existen, necesitamos controlarlos, ¿cuales son los que son realmente necesarios? ¿cuales son lo que producen beneficio? ¿como controlo que un cambio no afecte la estabilidad de todo el ecosistema de IT?

Por eso necesitamos de Change Management...

Muchas veces que en las organizaciones que Change Management tiene un alcance muy extendido incluyendo implementación y seguimiento de los cambios.
En ITIL el enfoque de Change Management es de AUTORIZACIÓN, lograr que todo cambios que se vaya a implementar este autorizado. Para implementación, seguimiento y evaluación hay otros procesos.
El enfoque extendido muchas veces hace que los procesos de CM se conviertan en muy burocráticos, por ese motivo es desaconsejable tener semejante nivel de acoplamiento.

Un buen proceso de CM garantiza que se siguen una serie de pasos determinados para cada tipo de cambio. (mas adelante hablaremos de los tipos de cambio). Básicamente tendremos estos pasos:

1. Solicitar un cambio
• Registrar el cambio con toda la información necesaria
2. Revisar la solicitud
• Revisar si la solicitud esta completa y es coherente
3. Evaluar y realizar una análisis de impacto del cambio
• Identificar quien lo solicita, la razón, que beneficios trae, cuales son los riesgos, que recursos necesita para implementar, quien es responsable de implementar, cual es la relación con otros cambios
4. Autorizarlo
• Conseguir el nivel de autorización adecuado para cada cambio
5. Coordinar la implementación del cambio
• Calendarizar el cambio, exigir back-out plans (la implementación es responsabilidad de otro proceso)
6. Revisar la implementación del cambio y cerrar la solicitud.
• Una vez realizado se verifica si el cambio fue satisfactorio y se cierra o reabre según el caso

El proceso de Change Management sugerido por ITIL, tiene como alcance los servicios de IT. Dentro de una organización existe otros procesos de CM que tienen que estar correctamente integrados, como por ejemplo: Change Management de Proyectos basados en PMBOK o PRINCE2, Change Management Organizacional, entre otros.

Próximamente seguiremos hablando de CM.

ITIL: ¿Qué es un cambio?

Me ha pasado de ir a muchas organizaciones que tienen problemas en la implementación de un proceso de Change Management debido a la falta de definición de que es un cambio...

Recurramos a la definición que nos da ITIL sobre lo que es un cambio:

"Alta, Baja o Modificación de cualquier cosa que pudiera afectar un servicio de IT"

De la definición podemos inferir que cualquier cosa que afecta un servicio de IT tiene que ser gestionada y cualquier cosa que tiene que ser gestionada, en ITIL se define como un configuration item (CI).

Entonces podemos decir que el alcance de Change Management son todos los configuration item (CIs).

Parece que pateamos la pelota para adelante....ahora que es un CI?
"Un CI es cualquier componente o activo de un Servicio de IT."

• Servicio IT es un CI?
• SI. Podemos decir que la definición de un CI es recursiva. Como analogía: Un auto es un CI, que se compone de  ruedas, que son CI, que se componen de llantas que es un CI, etc.... Un Servicio de IT es como el auto. "Un componente compuesto de componentes".
• Componente Hardware?
• SI. Seria como una rueda en el ejemplo anterior.
• Componente Software?
• SI. Una aplicación, Sistema Operativo, herramientas, componentes de aplicaciones, etc.
• Componentes Virtuales?
• SI. Servidores Virtuales, Storage Virtual, Clouds son un activos de un servicio.
• Edificio u Oficina o Sector o Locación?
• SI. Las facilities donde ser brinda un servicio son CI. Pensemos, ¿no nos interesa saber donde se brinda un servicio?
• Personas?
• SI. Nuevamente, ¿no nos interesa saber quienes son las personas asociadas al servicio, que lo brindan o que lo consumen?
• Documentación asociada al servicio?
• SI. Diagramas de arquitectura, SLAs, Manuales de usuario, Contratos, Métricas, Documentación de proceso, etc. 
• Estrategia de Negocio?
• NO. Usualmente la estrategia de negocio, cambios organizacionales, etc, no son tomados como CIs.

Como primera recomendación uno puede decir que primero se definan cuales son los servicios de IT, después se descomponga cada servicio granularmente en cada componente y luego cada componente queda bajo control de Change Management.

Ejemplo:

• Servicio de Correo Electrónico
• Webmail
• Servidor de aplicaciones Apache
• Maquina Virtual 1
• Virtualizador A
• Servidor Rackeable I
• Microprocesador #

Así sucesivamente podemos ir descomponiendo un servicio en componentes y ver cuales son los que si sufren un ABM, afecta al servicio. (Afectar al servicio es que tengan un impacto, no que produzcan una interrupción).

Por este motivo me parece muy saludable implementar Change Management junto con Service Asset & Configuration Management.... pero la verdad es que pocas veces pasa....Es mas, la mayoria de las empresas empiezan a implementar Change Management antes de pensar en servicios...

Otro punto importante que me gustaría destacar, es que normalmente se piensa que Change Management solo aplica cuando un servicio esta operativo, pero el verdadero alcance del proceso es mas amplio, el diseño de un servicio también debería estar alcanzado por Change Management (Requerimientos funcionales, Recursos previstos, Capacidades, Herramientas, Arquitectura tecnológica, procesos, métodos de medición, métricas, etc).

Ahora bien, la primera reflexión que suelo recibir, es que el alcance de Change Management es muy amplio, que es impracticable, tengo que pedir permiso hasta para reiniciar un servidor, que necesito un batallon de gente desarrollando las actividades de Change....

Por suerte existe la clasificación de los cambios, pero eso lo veremos mas adelante!

ITIL: Request Fulfillment

Es común que en las organizaciones no se diferencien incidentes de solicitudes de servicio. Esto tiene sentido para organizaciones con escaso volumen de generación de incidentes o bien que no cuenten con un catalogo de servicios de TI amplio, por lo tanto reciban poco volumen de solicitudes de servicio.

Request Fulfillment es un proceso sugerido por ITIL para tratar las Solicitudes de Servicio de los usuarios, diferenciándolo del proceso de Incident Management.

Una solicitud de servicio es un pedido formal de un usuario para que le provean un servicio. Ejemplos de solicitudes de servicios hay muchos, un usuario puede pedir un consejo, puede pedir información de como se realiza una tarea, puede pedir la instalación de software, puede pedir que le provean un consumible, puede pedir una notebook para otro usuario, puede pedir resetear la contraseña, puede pedir que le muden la computadora de lugar, y asi puede pedir tantas cosas como le dicte su imaginación :-)  .....(siempre y cuando no haya un catalogo de servicios que ponga una cota).

Como principal diferencia con un incidente, vemos que en una solicitud de servicio no hay una interrupción o degradación del mismo (porque esta solicitando un servicio nuevo!!!), y sobre todo, cumplir con una solicitud de servicio puede planificarse (no hay que salir corriendo a cumplirla porque no peligra la continuidad de un servicio).

Tipicamente el proceso de Request Fulfillmen sigue estos pasos:

1. Solicitud

El punto de entrada de este proceso suele ser el Service Desk, pero últimamente se esta siguiendo un enfoque de "Sírvase Ud. mismo". Es decir que la implementación de Request Fulfillment suele ser mas exitosa cuando se apoya en herramientas de Self Service. La idea es contar con un portal donde se encuentren listados los servicios que brinda el área de TI, donde este bien claro que es cada servicio, como se solicita, cuales son las condiciones, etc. Entonces el usuario ingresa al portal y selecciona el servicio que quiere solicitar, algunos pueden ser cumplimentados en el momento y otros requieren escalamiento o autorización.

Este enfoque aumenta la productividad del Service Desk, que no debe estar atendiendo estas solicitudes, aumenta la productividad del usuario, que puede ver cumplimentado el servicio en el momento, reduce la burocracia en la solicitud de servicio reduciendo el costo por ejemplo en horas hombre, incrementa el control sobre lo servicios solicitados dado que tenemos una única fuente de ingreso de solicitudes de servicio. 

2. Autorización

Muchas veces las solicitudes de servicio requieren autorización. Es común que usuarios soliciten la instalación de software en sus computadoras, si el software es licenciado, dado que el numero de licencias suele ser restringido, para que el usuario pueda utilizar el programa en cuestión, tiene que tener autorización. 

3. Cumplimiento

Dependiendo de la solicitud, la misma puede ser auto-cumplida, cumplida por el SD, o escalada a otro grupo. Igualmente, al igual que incidentes el SD debe mantener informado a los usuarios sobre el progreso de su solicitud

4. Cierre

Al igual que los incidentes, las solicitudes de servicio, se registran, se priorizan, se categorizan, también pueden ser escaladas y una vez cumplimentadas cerradas. El ownership de las solicitudes debe permanecer siempre en el SD.

A tener en cuenta para contar con un saludable proceso de Request Fulfillment

-Definir y documentar claramente todos los tipos de solicitudes que son manejadas por el proceso 

-Establecer una herramienta de self service para agilizar el cumplimiento de solicitudes

-Dejar bien en claro en que consiste el servicio que se esta solicitando, con el SLA asociado, requisitos de autorización, etc (hay que tener un buen Service Catalog)

Para finalizar, me parece importante decir que las solicitudes de servicio, suelen ser no muy difíciles de cumplimentar pero causan un alto impacto en la satisfacción de los usuarios. Es decir que bien implementado es un Quick Win en cualquier proyecto de ITIL

ITIL: Demand Management

En los últimos años las áreas de TI de las empresas invirtieron tiempo y esfuerzo en implementar un proceso de Demand Management.

Generalmente la visión que tienen las empresas de este proceso es la de administrar eficientemente la entrega de soluciones y el desarrollo de las mismas, haciendo hincapié en el cuándo, como y cuanto. El objetivo se centra en recibir requerimientos del negocio y cumplirlos en tiempo y costo.

En este proceso hacemos las actividades de priorizar requerimientos, planificarlos y asignarles recursos basándonos en qué beneficios y valor aporta para el negocio. (esto ocurre en el mejor de los casos).

Ahora bien esta visión que hay en las organizaciones sobre el proceso de Demand Management,es la visión que tiene ITIL de este proceso?

Cuando en las empresas recorren los procesos de ITIL, piensan que el proceso de Demand Management involucra todas las actividades descritas anteriormente.... pero no es así...

Demand Management para ITIL se encarga de predecir y regular el comportamiento de los clientes en el uso de un servicio.

Ejemplo, si en nuestra empresa vendemos productos a través de la web, y se decide sacar una promoción con descuentos para el día domingo, seguramente se incrementara la cantidad de clientes comprando productos, impactando en las transacciones que recibirá nuestro servidor (web server, bd, conexión internet, etc).(Mucha gente interpreta que estas actividades son parte del Capacity Management, y puede ser que tengan razón)

¿Que actividades hacemos dentro de Demand Management según ITIL?

-Analizamos los perfiles de usuarios, para saber quienes usan nuestro servicios, cuando los usan, como los usan, porque los usan

-Analizamos patrones de comportamiento del negocio 

-Influimos en los usuarios sobre como y cuando usar un servicio.

Como ven dentro de este proceso, no recibimos requerimientos, no los priorizamos y no los estimamos.

Ahora, donde hacemos Requirement Management dentro de ITIL?

Lo veremos mas adelante!!! :-P

ITIL: Funciones vs. Procesos

Bienvenidos a unos de los clásicos de ITIL, Funciones vs. Procesos.

En realidad podríamos tener esta discusión en varios frameworks de IT. COBIT, TOGAF y CMMI aportan a la confusión.

En el post anterior mostramos que en ITIL un proceso debía cumplir 4 características:  ser medible, producir un resultado, satisfacer expectativas de un stakeholder y responder a un evento especifico. Luego mostramos con un ejemplo como Incident Management cumplía con las 4 características... Hicimos trampa.

Hubiera sido mas valiente tratar de cumplir las 4 características con Capacity, Availability, Configuration, Financial, etc.

Ejemplo:
• Es Medible? Puedo medir cuantos Capacities se hicieron correctamente? 
• Produce un resultado especifico? finalizamos con un Availabity resuelto?
• Los resultados son orientado a un cliente o stakeholder? cuales serian los resultados que espera un stakeholder de Financial?
• Responde a un evento especifico? como inicia Availability?

Este es uno de los elementos de ITIL que aporta a la confusión.

A mi me parece mejor quedarnos con esta idea.
• Los procesos en ITIL son actividades para cumplir un objetivo de negocio (puede ser que estas actividades no sean secuenciales, no responde un evento especifico, pero tienen sentido que estén agrupadas)
• Las funciones en ITIL ejecutan las actividades relacionadas con uno o mas procesos 

Cualquier duda les dejo estos papers como referencia:
http://www.ismportal.nl/nl/system/files/Functions%20and%20Processes-sec.pdf
http://www.bptrends.com/publicationfiles/10-04-2011-ART-Ongoing%20Confusion%20of%20Process%20and%20Function-Betz-Final.pdf

ITIL: Un mundo de procesos

Dentro de la gran biblioteca de información que nos provee ITIL, uno de los aspectos mas importantes son los procesos.

Si leemos los libros de ITIL, vamos a encontrar que muchas veces se brindan diferentes definiciones para hablar de procesos. (Esta es una de las principales críticas que se le hacen a ITIL).

Pero vamos a quedarnos con la definición mas simple que es extraída del glosario:

"Los procesos son un conjunto de actividades diseñadas para lograr un objetivo específico."

En esta definición no hay ninguna diferencia con las definiciones que nos brindan otras metodologías o  frameworks o modelos o o o ...

Ahora bien...¿Esta definición nos basta para identificar un proceso?
Mmmm....mas de uno podría decir que una función cumple con la definición....

Por eso ITIL nos dice que un proceso tiene siempre las siguientes 4 características:

• Es Medible, tenemos que ser capaces de medir un proceso (costo, calidad, duración, productividad
• Producen un Resultado Especifico, un proceso tiene razón de existir, porque genera un resultado. 
• Los resultados son orientados a un cliente o stakeholder, desarrollamos un proceso para que cumpla las expectativas de un cliente ya sea interno o externo, y los resultados que generamos son de interés para ese cliente.
• Responde a un evento especifico, siempre necesitamos un trigger para que comience el proceso.

Apliquemos las características de un proceso al proceso mas famoso de ITIL: Incident Management

• Es Medible? Puedo medir incidentes mal priorizados, el costo promedio por incidente, el tiempo utilizado en resolver un incidente, la cantidad de incidentes resueltos dentro de un determinado SLA, etc.
• Produce un resultado especificao? Como principal salida del proceso tenemos incidentes resueltos y puedo contarlos! 
• Los resultados son orientado a un cliente o stakeholder? Las usuarios de TI tienen como expectativa sea mas facil solucionar los incovenientes que tiene a diario utilizando los sistemas. O sea que si les ocurre un inconveniente, el mismo se resuelto y ellos puedan continuar usando los servicios.
• Responde a un evento especifico? Usuario llamando a Service Desk porque tiene un inconveniente, o mandando un correo, da inicio al proceso de Incident Management.

Bien ahora que sabemos que es un proceso... 
¿Cuales son los Procesos de ITIL 2011? Los vamos a ordenar de acuerdo a la fase del ciclo de vida de un servicio al que pertenecen:

• Service Strategy
• Strategy Management for IT Services
• Service Portfolio Management
• Demand Management
• Financial Management for IT Services
• Business Relationship Management

• Service Design
• Design Coordination
• Service Catalogue Management
• Service Level Management
• Capacity Management
• Availability Management
• IT Service Continuity Management
• Information Security Management
• Supplier Management

• Service Transition
• Change Management
• Change Evaluation
• Transition Planning and Support
• Release and Deployment Management
• Service Validation and Testing
• Service Asset and Configuration Management
• Knowledge Management

• Service Operation
• Event Management
• Incident Management
• Request Fulfilment
• Access Management
• Problem Management

• Continuos Service Improvement
• The 7 Step Improvement Process

Lo que nos da un total de 26 procesos!!!

Como decimos al inicio.... ITIL es un mundo de procesos.

ITIL: ¿Qué son las Funciones?

Mas de una vez me ha pasado, que alguien me pregunto si podía dar un ejemplo practico de lo que es una función para ITIL

En ITIL todo gira alrededor de Service management (Gestión de servicios - siempre que pueda trataré de usar los términos en ingles dado que algunas traducciones en español suena muuuuyyy raras)
Service Management  se define como un conjunto de capacidades de la organización especializadas en proveer valor a los clientes, claro esta,  en forma de servicios. Estas capacidades se logran a través de funciones y procesos (en otra oportunidad hablaremos de procesos).

Para ITIL una función es una unidad organizativa responsable de actividades y resultados. Las funciones son el modo mas común en que las organizaciones estructuran sus "áreas o sectores".
ITIL identifica 4 funciones SERVICE DESK, APPLICATION MANAGEMENT, TECHNICAL MANAGEMENT, IT OPERATIONS MANAGEMENT aunque esta última generalmente se divide IT OPERATIONS CONTROL Y FACILITIES MANAGEMENT o sea que tendríamos 5 funciones.

¿Ahora bien, donde vemos estas funciones en las áreas de TI?

• El Service Desk suele ser el mas común y lo encontramos todo junto en una única área.(Nombres posibles: Mesa de Ayuda, Centro de Atención Usuarios, Total Desk, Escritorio de servicios -traducción muy española que encontré que usaban en una empresa de ese país.)
• Technical Management, en una empresa grande se reparte generalmente por especializaciones: Base de Datos, Ambientes Linux, Ambientes Windows, Middleware, Redes y Comunicaciones, Servidores, etc.
• Application Management, también en una empresa grande se divide por las aplicaciones que presta servicios: ERP, CRM, Aplicaciones Financieras, Gestión de aplicaciones de producción, Aplicaciones  Web, etc.
• IT Operations Control, generalmente son los chicos del NOC! Son los que hacen todas las operaciones rutinarias, ejecutan jobs, procesos, realizan backups, restores, etc.
• Facilities Management, los dueños de la infraestructura del Data Center y  si la organización tiene de los Recovery Sites. Son los que instalan los servers en los racks, controlan las ups, las conexiones de red, los aires acondicionados, etc.

Como vemos, las funciones las vemos a diario en las áreas de TI de todas las organizaciones, muchas veces se confunden con procesos porque ciertas áreas de TI organizan su estructura en procesos (Incident Management, Release Management,etc).

Mas adelante hablaremos de las diferencias entre funciones y procesos.