Necesito una Unidad de Intervención Inmediata

Frecuentemente cuando se ponen en marcha nuevos servicios, incidimos sobre cientos de usuarios que deben adquirir rápidamente nuevos conocimientos y adaptarse a nuevas maneras de trabajar. Es en este momento cuando necesitamos poner foco en una Gestión del Cambio precisa y especializada que nos ayude a conseguir poner a todas estas personas en marcha rápidamente.

El problema

Cuando hacemos este tipo de despliegues, se produce un rápido aumento de las necesidades de soporte: gran cantidad de usuarios necesitan apoyo en un corto espacio de tiempo. Los equipos de soporte se ven fuertemente afectados por esta situación, que además deben combinar con dar apoyo a las necesidades cotidianas del negocio.

La gestión del cambio debe proporcionar una base de conocimientos, materiales de formación y procedimientos que sean comprensibles, que se mantengan actualizados y que sobre todo puedan ser consultados de manera fácil por los usuarios afectados.

La solución

El empleo de soluciones especializadas y temporales, que puedan montarse, usarse y desmontarse fácilmente y en modalidad de pago por uso. Soluciones que no interfieran con los entornos corporativos y que proporcionen la flexibilidad y el acceso global que requieren los usuarios.

La Propuesta de G2

El próximo Jueves 7 de Mayo de 2020 haremos un webinar explicando cómo montamos una de estas plataformas express para habilitar una Unidad de Intervención Inmediata. 

Inscríbete aquí:  https://atlassian.gedos.es/inscripcion-webinar/ 

El Service Desk como Unidad de Intervención Inmediata

Llevo en el sector de las TIC unos 33 años y desarrollando proyectos unos 28. Aún así, mis participaciones en proyectos de software más intensas se han dado durante los últimos 10 años, temporada en la que desde G2 hemos hecho una suave deriva dentro de la gestión de servicios a la gestión completa del ciclo de vida del servicio, cosa que me ha permitido participar en los equipos de desarrollo aportando visiones de Lean, de Agile y de DevOps.

Durante estos años, una de las lecciones más importantes que he aprendido es que no hay DONE sin Materialización del Valor. Es decir, que por mucho que los equipos de desarrollo piensen que han finalizado un paquete de funcionalidades, hasta que no están en manos de usuario y siendo utilizadas, no son más que promesas incumplidas de un valor futuro.

Ya escribía sobre esto aquí

http://www.gobiernotic.es/2009/12/el-ultimo-del-ano-y-va-sobre-valor.html

y aquí

http://www.gobiernotic.es/2010/05/la-evolucion-cuantica.html

Ya más maduro, sobre el año 2013 reflexionaba sobre la problemática que nos presentaba el hecho de acelerar el flujo utilizando técnicas de automatización y el cuello de botella se trasladaba a otro sitio: el usuario, la última frontera.

http://www.gobiernotic.es/2013/06/el-punto-debil-de-devops.html

Así que llegamos a la conclusión de que una de las fases que más pueden influir en la materialización del valor generado por un proyecto es la de la Gestión del Cambio: poner en manos de los usuarios la nueva aplicación y conseguir desplegar lo antes posible y sobre el número de usuarios adecuados, el conocimiento, la práctica y los nuevos circuitos que harán que la promesa de valor se convierta en realidad.

¿De qué serviría un nuevo sistema para canalizar las oportunidades de venta que llegan por los diferentes canales si los comerciales no lo saben usar o lo usan mal?

¿De qué serviría el precioso sistema de seguimiento de indicadores si los que deben tomar decisiones en base a esos indicadores no lo saben usar o aquellos que alimentan los datos lo hacen mal o a deshora?

¿Cómo diablos vamos a conseguir poner a todas esas personas en teletrabajo si cuando les damos las herramientas técnicas no saben usarlas?

Así, pues, se nos hace fundamental ayudar a los equipos en esta etapa de Gestión del Cambio, y tradicionalmente las empresas ponen foco en una serie de acciones: 

• generación de materiales de formación
• formación a usuarios clave
• formación a formadores
• formación al equipo de soporte
• documentación de las preguntas más frecuentes

Pero...  ¿A qué se parece la realidad cuando te enfrentas a desplegar una solución para cientos o miles de usuarios? 

Pues lo primero que te pasa es que la aproximación de formar a usuarios claves o formación de formadores es quizás un poco lejana al usuario final. 

Tardas demasiado en llegar a ellos y con personas que en realidad son “proxies” del conocimiento: muy buena tiene que ser la formación a formadores (teórica y práctica) para que ellos puedan transmitir de manera fluida todo lo que se supone que debe saber el usuario final. Y muy buenos tienen que ser los materiales de formación, no podemos aspirar a que ellos generen sus propios materiales.

Lo segundo es que habrá situaciones que hayan quedado fuera de la formación y que durante las sesiones de formación a usuario final aparezcan en forma de preguntas que el recién estrenado profesor no sea capaz de resolver. ¿Tenemos un canal para poner en contacto al profesor con el equipo de desarrollo para que le resuelvan la duda de un día para otro? ¿Tenemos una manera de documentar este conocimiento modificando rápidamente el material de formación o de consulta?

En tercer lugar, los recién formados alumnos comienzan a trabajar con el nuevo sistema y lógicamente tienen dudas, encuentran cosas que no saben hacer o peor aún, encuentran errores. Esto, que en condiciones normales significaría una pequeña porción del trabajo habitual del Centro de Soporte, se puede convertir rápidamente en una avalancha de llamadas para las que, por si fuera poco, el técnico de soporte debe invertir mucho más tiempo en resolver porque a) no tiene la práctica y la formación habitual (es un producto nuevo) y b) necesita dar formación al usuario, dando una respuesta que al tiempo de resolver su problema, sea pedagógica para facilitar la incorporación del usuario en la nueva solución.

Para terminar de rizar el rizo, nos vamos a encontrar con que si el Centro de Soporte está colapsado atendiendo este tipo de interacciones, ¿cómo vamos a atender los contactos habituales, los que se refieren a otro tipo de servicios que incluso podrían ser más prioritarios? ¿Cómo atenderemos el Business as Usual?

En definitiva, vemos que para una situación más o menos excepcional como es el roll-out de un proyecto que tiene afectación a un elevado número de usuarios en un breve espacio de tiempo, debemos buscar soluciones adecuadas y excepcionales, huyendo de la solución tradicional de “lo pasaremos a través de soporte ” y construyendo una solución adecuada a esta situación de trato especial al usuario. (de hecho, a esta fase de los proyectos se le llama precisamente la fase de HyperCare)

Posiblemente pensarás que este tipo de roll-outs son poco habituales, que las cosas las hacemos de manera iterativa e incremental y que eso de un gran proyecto en modo cascada está pasado de moda. Te doy toda la razón del mundo, pero también es cierto que la gran mayoría de proyectos que significan sustituir una plataforma por otra, aquellos que tienen una puesta en marcha en formato big-bang, aquellos que ponen un producto mínimo viable en manos de un gran número de usuarios y todos aquellos que se ponen en marcha por motivos de extremada urgencia (por ejemplo, motivados por la activación de planes de continuidad) son candidatos a recibir este tipo de tratamiento. 

¿Y cuál es la respuesta?

Bueno, en G2 llevamos tiempo ya dándole vueltas a esto y ayudando a nuestros clientes a crear esto que llamamos Unidades de Intervención Inmediata. 

Para ello, nos inspiramos en el concepto de Arquitectura Efímera: son instalaciones que se diseñan y se piensan teniendo en cuenta que serán poco duraderas. Están orientadas a transmitir sensaciones, mensajes o emociones a través de las formas durante un breve espacio de tiempo (semanas o quizás meses), como puede ser una instalación artística en un aeropuerto, el stand alucinante que viste en la última feria a la que asististe o un hospital de campaña montado de manera urgente para atender una situación como la que estamos viviendo.

Estas arquitecturas efímeras están pensadas para transmitir un mensaje concreto durante un tiempo concreto, de la misma manera que en IT necesitamos transmitir un mensaje concreto (la tranquilidad de dar el paso a usar una nueva herramienta) durante un tiempo concreto (el que necesite el negocio hasta haber estabilizado el uso del nuevo sistema).

Así, nuestra propuesta es la generación de una plataforma de soporte completamente nueva, especialmente orientada a apoyar a los usuarios en la transición a esta nueva manera de trabajar que supone el despliegue del nuevo servicio y que se concibe desde el inicio como una plataforma efímera: se monta rápido, se usa rápido, se destruye rápido y sólo se paga por el tiempo que se usa.

El próximo Jueves 7 de Mayo de 2020 haremos un webinar explicando cómo montamos una de estas plataformas express para habilitar una Unidad de Intervención Inmediata. En esta charla veremos cuáles son las ventajas que le aporta al cliente, tanto al equipo de soporte, como al equipo de administración de herramientas y a los usuarios finales.

Si te ha picado el gusanillo de la curiosidad, inscríbete en nuestra página del G2 Atlassian Team y trae preparadas todas las preguntas que quieras plantearle al equipo que con gusto las resolveremos.

No catalog, No cloud

La estrella invitada de esta noche, Rodrigo Flores, ha sido compañero de penurias en este mundo blogeril y de relaciones sociales virtuales. Lo conseguí desvirtualizar el año pasado, durante el congreso ITSMFUSION 10 y me llevé un muy grato recuerdo de las conversaciones mantenidas: es emprendedor, iluminado y visionario…  comenzó en el mundo ITSM, vio la oportunidad en el mundo Cloud y consiguió colocarle su empresa a Cisco… ¿Qué mas pedir!?  Bueno… por el camino escribió EL libro sobre Catálogos de Servicio: Defining IT Success Through The Service Catalog: A Practical Guide

Hoy ha impartido un webinar sobre la relación entre el Catálogo de Servicios y el mundo cloud, que no se deben perder:

Reflexiones tras el Fusion10

El congreso del itSMF USA Fusion10 quedó atrás y yo tenía pendiente escribir un post al respecto de la experiencia. Aún así, he preferido dejar que las ideas se sedimenten un poco, porque después de cinco días intensos de conferencias y networking con gente tan buena como la que había por allí la tormenta de ideas que tenía en la cabeza me exigía escribir por lo menos diez posts en lugar de uno!

Yo creo que el resumen definitivo que se puede hacer del congreso es que hay cuatro puntos que se establecen como “el último grito” en ITSM: El Catálogo de Servicios y de Peticiones, Cloud Computing, Lean Service Management y Social Media. No asistí a ninguna de las conferencias de Social Media, pero sí que me di caña especialmente en las tres primeras y mi conclusión particular es que son tres conceptos que encajan a la perfección el uno con el otro y que son las áreas de conocimiento más trendies de los próximos cinco años.

Si nos fijamos, resulta que tanto un buen Catálogo de servicios y Peticiones como los conceptos de cloud computing son una aplicación directa de los principios del Lean Consumption expresados por Womack y Jones en su libro Lean Solutions:

• Solventa mi problema completamente
• No me hagas perder el tiempo
• Dame exactamente lo que quiero
• Añade valor donde yo lo necesito
• Resuelve mi problema/necesidad cuando yo necesito

Es posible que no acabes de ver los conceptos de cloud computing aquí en medio, pero en realidad lo que ocurre es que los dos conceptos más importantes dentro de un “planteamiento cloud” son por una parte el catálogo de servicios y peticiones (nadie concibe una cloud, ya sea pública o privada sin una estandarización de las peticiones que se le pueden realizar o de los productos que ofrece ni llamando a la extensión #111 para pedir un servidor… cloud va intimamente ligado al concepto de catálogo de servicios accionable) y por la otra un grado de automatización exagerada, que debe facilitar que la provisión se realice en tiempos récord.

Así, el uso de los conceptos y principios Lean para la definición y construcción del catálogo de servicios y peticiones, unido a los conceptos de cloud computing para proporcionar el mayor grado posible de automatización en la ejecución de esas peticiones son la clave para la Gestión de Servicios en los próximos años.

En la foto vemos cómo se materializa esa fusión de conceptos: Ivanka Menken, de The Art of Service quienes ofrecen el esquema de formación y certificación en Cloud Computing; Rodrigo Flores, de newScale y reconocido impulsor de los conceptos de Catálogo de Servicios y Peticiones y yo mismamente, de G2 y difusor de la combinación de Lean con ITSM.

Definiendo la lista de Servicios

Hank Marquis acaba de publicar un artículo en el que explica un proceso de cinco pasos para la definición de la lista de servicios (primer paso para la definición de un catálogo de servicios).

Es interesante ver que también cultiva el "estilo campechano" y la "fusión de estándares", así que plantea un mecanismo que asimila conceptos de otros estándares como eTOM y SID.

Hay que leerlo con calma, pero es muy interesante.

http://www.itsmsolutions.com/newsletters/DITYvol4iss11.htm

La extremada complejidad del Catálogo de Servicios

Desde que comencé a trabajar con los conceptos de Gestión de Servicios, haciendo mis primeros pinitos en la implantación de herramientas de OpenView, siempre he usado el correo como el primer ejemplo del concepto de Servicio.

Así, el correo electrónico es más que el servidor, más que el sendmail que corre sobre él y más que las líneas de comunicaciones, sino que es el concepto agregado de todo ello.

Pero siendo como es el más extendido de todos los servicios, el más usado como ejemplo y el primero en ser documentado desde todos los puntos de vista que exige una correcta gestión de servicios (desde el SLA hasta la monitorización pasando por el soporte presencial o la capacidad), es curioso que no hayamos llegado a un acuerdo sobre cómo se debe plantar el simple y vulgar correo en un catálogo de servicios.

Y es precisamente el hecho de que no esté estandarizado (aunque sea de facto) el correo ni ningún otro de los servicios más comunes (impresión, archivos compartidos, navegación Internet, telefonía...) lo que me demuestra esta increíble complejidad que se oculta tras el (simple) concepto de Catálogo de Servicios.

Cuando miras el servicio de correo desde el punto de vista del usuario, ves un buzón con algunas funcionalidades adicionales como puede ser antivirus, antispam, quota de buzon, etc.

Cuando lo miras desde el punto de vista de la operación, ves servidores, líneas, software...

Cuando lo miras desde el punto de vista del ServiceDesk, ves las incidencias y los diferentes tipos de peticiones que se pueden realizar sobre el correo: backup y restauración del buzón, reseteo de la contraseña, movimiento del buzón, etc.

Y cuando, además modernizas el servicio, resulta que te encuentras con que a ese mismo buzón el usuario accede desde un cliente pesado por MAPI, desde un cliente ligero por OWA, desde otro sistema por IMAP4 y desde una blackberry.

¿Es el mismo servicio el correo accedido desde un cliente pesado que desde una blackberry? Quizás desde el punto de vista del usuario sea lo mismo o muy similar, pero desde el punto de vista de la Gestión de la Disponibilidad no es lo mismo medir la disponibilidad del buzón (backend) que la disponibilidad del acceso Blackberry (con sus frontends y la disponibilidad de la red GPRS).

Y así podríamos seguir encontrando toneladas de pequeñas diferencias y matices que hacen que una cosa sea distinta de la otra... Así que, o llegas a un acuerdo y dejas de buscarle las cinco patas al gato, o te has tirado meses sólo discutiendo sobre el correo y aún te faltan 30 servicios más por documentar!

¿Y todo esto por qué pasa? Pues en mi humilde opinión porque ITIL define un concepto único que es el catálogo de servicios como piedra angular de la Gestión de Servicios (evidentemente, si quieres gestionar servicios necesitas saber a qué servicios te refieres, ¿No?) cuando en realidad hay que pensar en un concepto de catálogo multidisciplinar y que permita diferentes puntos de vista, a la vez que te debe permitir canalizar el diálogo con todas las partes implicadas... y eso es extremadamente difícil de lograr.

Lo fácil es tener una lista de servicios, quizás enriquecida con algunos atributos que te permitan describir de una u otra manera estos servicios, y luego tener diferentes "ampliaciones" de estos conceptos.

Así, puedes tener lo que yo llamo "carta de servicios", que es la representación del catálogo especialmente orientada a clientes, indicando qué pueden pedir o esperar de IT; o puedes tener un catálogo interno de servicios, con la arquitectura tecnológica y los conceptos de medición para el área de operaciones/explotación; y así los diferentes "sabores" de catálogo que te permitan gestionar cada una de las facetas de los diferentes servicios.

Y entonces llegan Charlie Betz y Rob England y siembran la duda cuando ya pensabas que lo tenías claro, aquí y aquí.

Tienes opiniones al respecto? Cómo es el correo en tu catálogo de servicios? Qué haces con los diferentes canales de acceso?

Aquí podríamos estar hablando durante horas, así que no dejes de añadir tu granito de arena, porque tu catálogo ¿es un catálogo de productos, de servicios TIC, de peticiones, de servicios profesionales o de buenas intenciones?

Crónica del evento itSMF CAT del 6 de Febrero de 2008

El pasado 6 de Febrero se realizó en Barcelona el evento anual del capítulo Cataluña del itSMF. Fue una jornada interesante, con una asistencia más que respetable (sobre unas 120 personas) teniendo en cuenta el corto plazo que hubo para hacer publicidad del acto y en el que pude ver un montón de caras conocidas.

Para mi, lo más importante del evento fueron las presentaciones realizadas por los representantes locales, que presentaron su visión actual en la Gestión de Servicios. Hablaron personalidades del CTTI (Centro de Telecomunicaciones y Tecnologías de la Información), del Banco de Sabadell, de Gas Natural y de Cuatrecasas Abogados, así que estaban representados distintos sectores, además de grandes organizaciones presentes en Cataluña.

En general, me llamó la atención que se trataron de forma recurrente tres temas principales:

CATALOGO DE SERVICIOS

Todos los ponentes resaltaron la importancia del catálogo de servicios, presentando cada uno una visión diferente. Es curioso ver cómo los cuatro ponentes locales mezclaron rápidamente el concepto de Servicio TIC con el de Servicio Profesional y en seguida el concepto de Catálogo de Servicios fue derivando en el siguiente punto tratado por todos los demás:

GESTION DE LA DEMANDA

Convertir el catálogo de servicios en un catálogo de peticiones y a partir de ello, centralizar toda la demanda del usuario a través del ServiceDesk (ya sea telefónico o web-based) en base a peticiones permitidas. Además apareció en varias ocasiones el concepto de Oficina de Proyectos como canalizador de la demanda "grande" y transmisor de la estrategia corporativa hacia la estrategia TI.

GESTION DE LA EXTERNALIZACION

La presentación de Brigitte Noordegraaf, de Quint Wellington Redwood, versó sobre el tema de la externalización, pero posteriormente en la mesa redonda la gran mayoría de preguntas se focalizaron en este aspecto. Me sorprendió mucho que el modelo de outsourcing que plantea Quint no contempla la devolución del servicio, e incluso cuando le lancé esta pregunta a Brigitte simplemente contestó que no se suele dar el caso (en mi opinión es importantísimo contemplar la devolución del servicio ya sea por finalización o por cancelación del contrato, lecciones aprendidas de los concursos de la Generalitat)

Hubo varias perlas, frases lanzadas al aire (para el que las quisiera coger), algunas de las cuales les paso a detallar:

Jordi Bosch: (Generalitat de Catalunya)

La capacidad de compra de la Administración Pública hace de regulador en épocas de crisis.

[...]

Es misión de ustedes, los asistentes a este tipo de evento, realizar una labor de socialización de ITIL de tal manera que vayan filtrando estos conceptos a las capas más altas en la dirección  de las empresas

Ricard Pons: (IBM)

No podemos estocar servicios, así que tenemos que proporcionarlos en el momento en que nos los pidan. Lo único que podemos hacer es influenciar en la demanda.

Ivor McFarlane: (IBM)

Sharon Taylor nos pidió que relacionásemos el contenido de los libros de la V3 con la fotografía que hay en la portada. ¿Ven lo que hay en la portada del Service Transition? Es una foto en Rayos X de unas vainas de guisante. ¿Para qué sirve? Obviamente, para saber si dentro hay guisantes o no. Como pueden ver, aquí falta un guisante (justo debajo de la palabra "Transition").

¿Me podrían decir si esta vaina es aceptable?

Obviamente, no pueden si no saben para qué se va a usar. Si es para hacer unos guisantes salteados, da absolutamente igual: abriremos las vainas y sacaremos los guisantes para saltearlos, pero si es para hacer un "Vainuá a le menoriette" (cuando queremos que la comida parezca buena, le ponemos nombres en francés) para la Reina, le pondremos en un plato las vainas abiertas y cuando el maitre la lleve a la mesa, su majestad pensará  "oh! alguien me ha robado un guisante, el guisante de la Reina!)"

La clave es saber para qué se va a usar el servicio.

David Wheeldon: (HP)

Normalmente, las organizaciones querrán invertir lo mínimo posible en los entornos en producción y desviar el máximo de inversión hacia el desarrollo de nuevos proyectos/servicios ya que esto es lo que produce nuevas funcionalidades que permiten mejoras en el negocio. Las inversiones en los entornos en producción son poco visibles.

Brigitte Noordegraaf: (Quint)

El 78% de los contratos de outsourcing se realizan con el principal objetivo de reducir costes. Si lo que quieres es reducir costes, ¡lo primero es saber cuánto te cuesta!

[...]

El primer mandamiento es implementar un marco de gobierno efectivo tanto para el proyecto de externalización como para el seguimiento del contrato.

Xavier Virgili: (Banc de Sabadell)

Con el paso del tiempo, no hemos aprendido "negocio" del usuario; le hemos enseñado informática al usuario, y eso ahora se nos ha dado la vuelta.

[...]

De repente nos dimos cuenta de la criticidad relativa del proceso de negocio frente al servicio TIC, y descubrimos que si no iba el correo, el banco no se hundía.

[...]

Antes de poder establecer SLA's se requiere una cultura del indicador en toda la compañía. Establecer SLA's sólo para las TIC no tiene sentido (en este momento, el cliente escéptico del que hablaba en un post anterior me miró y se echó a reír)

Francesc Muñoz: (Cuatrecasas Abogados)

El problema de plantearnos SLA's internos está en captar indicadores de negocio que se puedan reflejar en los SLA's.

Josep Bastida: (Gas Natural)

La clave para la Gestión de la Demanda está en establecer correctamente las expectativas del cliente y exigir siempre un Business Case o estudio de ROI del cliente para aceptar la demanda.

[... ]

El Catálogo de Servicios debe ir ligado a un sistema de Gestión de Peticiones. No puedes pedir nada que no esté en el catálogo.

En conclusión, el evento fue interesante, pero había que leer entre líneas. El networking (como siempre) estuvo a la orden del día y la organización, excelente.

Espero que el año que viene los ponentes sean de un nivel más operativo para poder ver la realidad "en acción" y que haya mucho más cliente que proveedor en el público. Esos son mis deseos para el evento itSMF 2009 (y espero poder trabajar para que se conviertan en realidad)

Libro: Service Management, strategies that work

Poco antes de Navidad, un amigo me comentó de pasada que se estaba leyendo un libro, que se lo había comprado pensando en encontrar material sobre Gestión de Servicios TIC y que le había sorprendido muchísimo encontrarse con una excelente documentación sobre IT Governance.

Coincidió por esas fechas que unos pocos de los lectores de este blog se decidieron a comprar algún que otro libro en la Biblioteca GobTIC, así que me cayó por Navidad un cheque-regalo de Amazon para gastar y pensé que estaría bien dedicarlo a este libro.

¡Qué grata sorpresa!

Aun no me lo he terminado de leer, pero tenía ganas de comentarlo con ustedes porque realmente da gusto leerlo. Sólo la introducción ya da una visión de IT Governance fresca y agradable de leer (qué lejos de ese estilo serio y gris de las publicaciones de ISACA, que parecen sacadas de una notaría), unas definiciones de conceptos como Servicio que he sentido realmente próximas y la diferenciación entre Servicios IT y Servicios profesionales que llevo aplicando desde los primeros proyectos realmente importantes allá por el año 99.

En realidad es un conjunto de whitepapers, de los cuales alguno como el de definición de un modelo de costes para los servicios TIC llevan tiempo circulando por la red (todos los autores son de Pink Elephant, así que allí podremos encontrar algunos de ellos).

El índice de contenidos es el siguiente:

• Introducción: ¿Alineación con el Negocio, o Integración con el Negocio?
• IT Governance al descubierto
• El proveedor externo de servicios gestionados
• Implementación de Procesos
• Definición, modelado y contabilidad de costes para servicios TI
• La CMDB Federada
• Desarrollando un marco de trabajo de medición basado en Calidad
• La Teoría de las Limitaciones y la mejora continua del servicio

Es una lectura que recomiendo fervientemente: al menos a mi, personalmente, ha conseguido algo que hacía tiempo que no me pasaba con literatura profesional: la Magia ha vuelto a recorrer mi cuerpo.

Título: Service Management Strategies That Work-guidance for Executives

Autores: Gary Case, Troy DuMoulin, George Spalding, Anil C. Dissanayake.

ISBN: 978-9087530488

Si quieres echarle un ojo, en GoogleBooks  puedes hacerlo e incluso leer (y disfrutar) del prefacio y la introducción.

¿Ya lo has hecho? ¿Qué Opinas?

Outsourcing, Gobierno TI y Santo Tomás

Ya he comentado más de una vez en alguno de los artículos publicados por aquí que me llama la atención cómo las cosas nunca vienen solas. ¿Será que nos persigue un destino indescifrable?

Escribía hace cuatro días en GobTIC Flash sobre la importancia de COBIT en un entorno externalizado, hoy leía un artículo en la edición de Junio del IS Control Journal sobre la posibilidad (para mí remota) de externalizar la función de Gobierno TI y hoy me llega al buzón una pregunta para el Consultorio GobTIC con un texto como el que sigue:

[...] se está a punto de adjudicar una externalización total de los servicios del área de Sistemas. Pués bien, el viernes me propusieron que fuera el responsable del "gobierno" de los servicios y aquí me asaltarón dudas. ¿Por donde empiezo? ¿Establecemos métricas estilo COBIT para controlar posibles ANS (perdón SLA)? ¿Definimos un catálogo de servicios a prestar? ¿Acabamos de implantar la gestión de la configuración añadiendo, en lo posible, datos económicos no contemplados en su día? ¿A qué santo rezo? [...]

La respuesta a esta pregunta podría ocupar tomos y tomos, o bien se podría resumir en un simple "Rézale a Santo Tomás", patrón de las Universidades, la enseñanza y de los incrédulos.

Bromas aparte, vamos a ver unas cuantas cosillas que hay que tener en cuenta: lo primero es lo primero, así que si te proponen ser el responsable del gobierno de los servicios, tenemos que dejar claro qué significa Gobierno y qué significa Servicio en tu contexto. Me da la sensación que el término Gobierno en este contexto significa "Supervisión del desempeño del outsourcer", mientras que el término Servicio es más delicado, ya que me hablas de externalizar los servicios del área de Sistemas de una gran organización, luego el concepto Servicio IT posiblemente no sea el que aplique aquí.

Veamos tus reguntas una por una:

¿Establecemos métricas al estilo COBIT para controlar posibles ANS/SLAs?

Ojo con esto, ya que es un error muy común a la hora de pensar en métricas. Siempre que pensamos en métricas acabamos pensando en SLAs y casi se podría decir que no tiene nada que ver (ojo, ¡casi!). Las métricas pueden medir varias cosas, servicios, procesos, cumplimiento de objetivos, etc. COBIT plantea métricas que ayudan a medir procesos y actividades, pero nunca Servicios TI.

De esta forma, podrás establecer métricas de COBIT que te ayuden a definir los SLA de Proceso del proveedor (Resolución de Incidencias, Gestión de Cambios, etc...) pero COBIT no te dará métricas de Servicio TI (rendimiento de la Intranet hospedada y gestionada por el proveedor).

¿Definimos un Catálogo de Servicios a prestar?

¡Ya tardas! Si no existe este catálogo de servicios, la oferta del proveedor será una gran estimación y luego todo serán discusiones. Además, será sobre este catálogo de servicios sobre el que podrás negociar los SLA (la S es de Servicio, no lo olvidemos) y establecer esas métricas de servicio.

Es decir, tal y como me lo imagino, la oferta del proveedor sin catálogo de servicios se podrá comprometer a métricas de proceso (porque se siente que los puede controlar) y a catacterísticas genéricas de los sistemas, pero no puede llegar a comprometerse en métricas concretas de servicios porque no sabe cuáles son.

¿Acabamos de montar la Gestión de Configuraciones?

Oh! ¡Qué bonita pregunta! En el más puro sentido de la externalización, en el momento en que el proveedor tome el control, a tu organización "le importa tres pepinos la configuración"... eso sería lo que uno podría pensar si se creyera de verdad todas las grandes maravillas de la externalización, pero... si te lo crees nunca más cambiarás de proveedor porque te tendrá pillado por donde no te gusta, teniendo él todo el conocimiento relativo a la infraestructura y las relaciones entre componentes.

Osea, o te aseguras una devolución perfecta del servicio externalizado a la finalización del contrato, o mejor quédate con el conocimiento de la configuración.

¿A qué santo le rezo?

Lo dicho, a Santo Tomás.

Para mi, la actividad principal debe ser la de supervisión del desempeño del outsourcer, junto a la definición, supervisión y mejora de los modelos de relación entre las organizaciones. Es decir, no creo que sea suficiente monitorizar los SLAs y "apretarle las tuercas" al proveedor cuando no se cumplan algunos de los indicadores, sino que se debe realizar una acción continuada sobre la relación, los procesos y los requerimientos del negocio sobre los servicios TIC que tienes externalizados.

Para acabar, una recomendación sobre las métricas: centrate en las métricas que te sirvan para gobernar (valga la redundancia) los servicios y la relación con el proveedor y deja las métricas de operación para el proveedor: es su trabajo.

Por ejemplo, en un proceso de Gestión de Incidencias, es fácil ver la métrica de "tiempo de primer contacto" o la métrica de "porcentaje de resolución en primer nivel de soporte"... a ti, como cliente, ¿realmente te interesa ese tipo de métricas? Seguramente te interesará una métrica del tipo "% de incidencias resueltas dentro de plazo".  Cuando este indicador no funcione bien, será el proveedor quien tenga que investigar en el valor del "tiempo de primero contacto".

PD: Me preguntabas en tu mail si se debería tener en cuenta a la gente de procesos y metodologías para esta labor: ¡¡POR SUPUESTO QUE SI!! Además, seguro que podrán ayudar un mucho en la definicion de controles, auditorias, indicadores, políticas, etc.

Definiendo Servicios: mejor desde la ignorancia

LLega un momento en cualquier implantación/definición de procesos de Gestión de Servicios en el que, axiomáticamente, hay que definir los servicios. Hay compañias que empiezan la casa construyendo un catálogo de servicios bien detallado, hay otras que comienzan definiendo procesos y herramientas y al ir a pensar en los datos necesarios para la herramienta aparece el campo "Servicio" que hay que rellenar con algo, así que al menos hay que obtener la lista de servicios.

Sea como sea, cuando llega el momento de pensar en la lista de servicios invariablemente aparece la necesidad de definir el concepto servicio después vienen las discusiones al respecto de cuáles son los servicios que prestamos al resto de la organización (el negocio como lo llamamos habitualmente).

Bueno, vamos a empezar por una definición de servicio que estoy utilizando últimamente y que me cuadra bastante:

SERVICIO TIC:

Uno o más Sistemas TIC [...] proporcionados por el Departamento de IT y que facilitan los procesos de negocio de la Organización. Un Servicio TIC debe ser percibido por el cliente como una entidad coherente o como un producto consumible.

Lo que más me gusta de esta definición es aquello de debe ser percibido como una entidad coherente o como un producto consumible. Y aquí es donde viene la segunda parte del título del artículo: mejor desde la ignorancia.  Esa percepción a la que nos referimos, es la percepción del usuario, no la nuestra desde dentro de IT.

Escribo este post en un avión, volando desde Bruselas a Barcelona y precisamente lo que me ha inspirado el sentido de ignorancia es que yo no tengo ni idea de qué es lo que hace falta para conseguir que el avión me lleve desde un sitio a otro, los mecanismos, las capacidades, la atención del personal de cabina, etc... yo tengo claramente la percepción de vuelo y veo claramente que hay diferencias entre volar en una compañia Low-Cost o volar en Iberia Business Class... veo los diferentes niveles de servicio, pero no sé (ni quiero saber) las tripas que componen este servicio.

Cuando llega el momento de definir la lista de servicios que ofrece IT al negocio, mejor hacerlo desde la ignorancia (en el buen sentido de la palabra): vayámonos al negocio y preguntémosle qué es lo que ellos perciben como un producto consumible, qué es lo que ellos usan/piden/consumen de IT y tendremos gran cantidad del trabajo hecho y de discusiones internas eliminadas; porque nosotros, como IT ,conocemos las tripas del servicio y nos plantearemos dudas complejas sobre la estructura de servicios.

Un ejemplo simple: un servicio puede ser "el teléfono móvil". Si lo veo como usuario, es un aparato que sirve para llamar por teléfono desde cualquier punto del pais, con posibles ampliaciones al extrangero. Si lo veo como un entendido en la materia puede ser que decida diferenciar entre el servicio "teléfono móvil 3G", "teléfono móvil UMTS", "teléfono móvil satelital", porque, desde el punto de vista de IT son cosas diferentes.

Pero el usuario ni ve ni comprende estas diferencias... sólo quiere llamar por teléfono. (o sólo quiere volar... da igual el resto)

Se positivamente que este post me va a traer problemas, porque yo mismo he defendido en más de una vez que el correo POP es diferente servicio que el correo WEB o que el correo BlackBerry basándome en que a)los parámetros de medición son diferentes, b)los niveles de servicio son diferentes c)las infraestructuras/tecnologías que hay debajo son diferentes.

Pero en el fondo, el usuario sólo quiere leer el correo... lo que varía es cómo lo lee.

No pretendo sentar cátedra en este tema... sólo reflexiono en voz alta porque ninguna de las dos aproximaciones me da respuesta a todas las preguntas. Pero... desde la ignorancia las cosas se ven de una manera mucho más simple.

TOGAF y el Catálogo de Servicios

Cuando se inicia un proyecto de definición de un Catálogo de Servicios, uno de los primeros pasos es obtener la lista de los servicios que se van a tratar y a documentar. Está claro que para la organización TI es necesario llegar a documentar todos los servicios en su catálogo, pero para seguir  un métido de aproximaciones sucesivas y poder obtener entregables a corto plazo, la idea es obtener primero la lista de los servicios y abordar su documentación detallada por "tacadas" de mayor a menor importancia para el resto de la organización (a.k.a "el negocio").

Llegados al punto en que hay que comenzar a obtener la lista, podemos comenzar desde cero o aprovechar algo de información sobre "los servicios más comunes que tienen todas las organizaciones", y es aquí donde puede servir de gran ayuda un apartado especial de TOGAF llamado Taxonomía de Aplicaciones.

No es aplicable al 100%, pero puede servir como base para desarrollar esta lista.

¡Buena Caza!

Un whitepaper interesante

He encontrado un whitepaper interesante titulado Defining, Modeling & Costing IT Services publicado por los chicos de Pink Elephant en el que se habla de un par de asuntos de gran importancia:

1. Una definición (más) del concepto Servicio
2. Los 4 pasos necesarios para obtener la lista de servicios
3. La separación entre servicios profesionales y servicios IT que tanto he remarcado en mis anteriores artículos sobre Catálogo de Servicios
4. La necesidad de un modelo de costes basado en servicios
5. La necesidad de que este modelo de costes tenga en cuenta aquellos servicios profesionales que no son directamente relacionables con los servicios IT ya existentes.

El paper está escrito por Troy DuMoulin (no lo dice explicitamente, pero he encontrado una versión anterior en la que sí que lo decía claramente), co-autor del libro Defining IT Success Through the Service Catalog junto con Rodrigo Flores y Bill Fine, de NewScale.

El Catálogo de Servicios y la Orientación a Objetos

Esta mañana, mientras me duchaba y estaba en esa zona de penumbra que separa el sueño de la vigilia, le daba vueltas a la cabeza a cómo le podría explicar los conceptos de ITSM a un grupo de programadores.

A esas horas de la mañana se me suele ir mucho la olla y mi cerebro genera un montón de ideas poco recomendables, pero de vez en cuando sale algo interesante, y así ha sido esta mañana, aunque en realidad lo plasmo aquí para que vaya madurando y quizás (con un poco de suerte) le pique el interés a alguno de los lectores y quiera añadir comentarios que mejoren la idea.

Si pensamos en el conjunto de actividades que se realizan en una organización como en un gigantesco programa desarrollado en un lenguaje de esos orientados a objetos (la verdad es que hace al menos 13 años que no programo, así que no se muy bien cómo han evolucionado estas cosas. Pero la base es la base), podemos entender que algunos de los objetos utilizados para el desarrollo son proporcionados por IT. Incluso , algunas de las áreas de la organización cogen objetos de los proporcionados por IT y los amplían y mejoran usando esas fantásticas técnicas de herencia múltiple.

En OOP cada clase se puede instanciar en varios objetos que mantienen propiedades similares, pero son instancias diferentes. En el mundo de los servicios TIC podemos tener exactamente lo mismo, servicios instanciados (por ejemplo) para diferentes clientes, o bien una única instancia del servicio para toda la organización.

Una clase queda definida por los atributos del objeto y por los métodos que se le pueden aplicar (perdónenme los exquisitos de la OOP por no utilizar el vocabulario 100% correcto!) y en un servicio tendremos los atributos que lo definen (descripcion, horario de soporte, etc) y las peticiones que los usuarios pueden realizar sobre este servicio.

Así mismo, hay algunos métodos que no son exportados (osea, que son internos del objeto y no se ven desde el exterior), que pueden ser relacionados directamente con las peticiones internas que cada una de las áreas de IT puede realizar sobre los servicios.

Por otra parte, a veces ocurre que quien ha desarrollado la librería de objetos que vamos a emplear la ha instrumentado, es decir, que disponemos de operaciones específicas para saber datos de rendimiento, volumetría de uso, profiling u otras propiedades al respecto del uso que se está dando de los objetos en nuestra aplicación... ¿Qué tal si eso lo relacionamos a nivel de explicación con el catálogo de métricas o conjunto de métricas disponibles para cada uno de los servcios?

Por último, en el ciclo de vida de nuestro paquete de clases definidas veremos que se van añadiendo nuevas funcionalidades (métodos), nuevos atributos, mejoras en el profiling y esto se corresponde directamente con los ciclos de maduración de nuestros servicios y de nuestro catálogo de servicios, que irá incluyendo cada vez nuevos atributos, ampliando las métricas por las que medimos y evaluamos los servicios y ampliando el abanico de peticiones que los usuarios pueden realizar sobre ellos.

A medida que avanzo en el post más me da la sensación de que una persona que ya sepa de qué va un catálogo de servicios puede considerar esta analogía como una "ida de perola", pero no olvidemos que el objetivo inicial era tratar de explicar estos conceptos a un grupo de programadores, acercándonos a su terreno. Con esta aproximación, casi que podríamos usar un buen JavaDoc para documentar y publicar nuestro catálogo de servicios, no?

¿Algún programador en la sala? :-)

Catálogos de Servicios - ¿ Fast Food o 'a la carte' ?

Hoy he leido el post publicado por Rodrigo Flores en su blog Service Catalogs al respecto de la definición del concepto de Servicio, algo que se echa en falta en todas las ocasiones en que pensamos en ITSM. Me ha encantado la comparación de un departamento de TI con un McDonalds o con un Burguer King y me ha dado que pensar en cuanto a la relación que existe entre la flexibilidad que le damos a los servicios y la forma de organizar los SLA.

Me explicaré un poco mejor: según los libros y las matemáticas combinatorias, hay principalmente 3 formas de organizar un ANS, a saber:

• MODELO 1: Un SLA para un servicio concreto S acordado con los "n" clientes de este servicio. En este caso tenemos un único documento de especificaciones del servicio con unos valores uniformes de Objetivos de Nivel de Servicio (SLO). De esta forma, proporcionaremos el servicio S a los "n" bajo las mismas especificaciones.
• MODELO 2: Un SLA para un cliente C con todos los servicios consumidos por este cliente. En este caso podremos parametrizar cada servicio de forma especial para cada uno de los clientes y tendremos un único documento que lo cubre todo.
• MODELO 3: Un SLA por cliente y por servicio. Es el modelo "producto cartesiano", que en una organización aunque sólo sea un pelín grande ya es inmanejable porque significa un volumen de documentos brutal.

Bueno, y frente a estas tres posibilidades, ¿Cuál es la correcta para mi organización?

Y aquí es donde entra el concepto McDonalds frente al concepto Burguer King, al concepto Restaurante Mibistec o a la cocina de mi casa: si voy al McDonalds no puedo customizar la hamburguesa ni pedir un bistec, si voy al Burguer King puedo customizar la hamburguesa, pero no pedir un bistec; si voy al restaurante, puedo pedir cualquier cosa que haya en la carta y customizarla y por último, si me quedo a comer en casa, hago lo que quiera (y/o pueda) con mi comida.

¿Cuán flexible es la provisión de los servicios hecha desde nuestra organización TIC? Habrá servicios con una gran flexibilidad, que requerirán un SLA especial para cada cliente que contrate y habrá servicios absolutamente rígidos que nos van a permitir firmar un único SLA con todos los clientes.

Desde el punto de vista del proveedor de servicios, cuanto más rígidos sean los servicios más simple es su gestión pero menor valor añadido de cara al cliente; de modo que como lo que pretendemos es alinearnos con nuestro cliente, tendremos que dar el nivel de flexibilidad que requiera la organización y aquí está el secreto: ajustaremos la complejidad de la gestión de nuestros servicios en tanto en cuanto seamos capaces de acordar unos niveles de flexibilidad adecuados.

Rafa ha añadido un comentario interesante a este post:

“Creo que lo que busca un cliente (sea interno o no) es la satisfacción de una necesidad (y quizás estoy pensando más en nuevos proyectos que en soporte). En ese caso, no creo que la rigidez vaya siempre en contra del valor añadido.
...
Quizás la flexibilidad no es tanto ser el restaurante (o la casa), sino ser McDonalds-Burguer-Restaurante-Casa en función del cliente y la necesidad. ”

Efectivamente, estoy de acuerdo contigo. Ahora bien, creo que el problema aparece cuando en realidad tienes muchos clientes (ya sean internos o no) y tienes que adecuar el servicio en función de cada uno de ellos. El extremo más radical sería que cada usuario pudiera pedir (o exigir bajo contrato de SLA) unas características diferentes en términos de calidad y cantidad para un servicio determinado: ¿Qué pasaría si cada usuario pudiera pedir diferentes SLOs para el servicio de correo --el más clásico de los servicios --?

Si cada usuario pudiera "ajustarse" sus características, tendrías que controlar las quotas, los filtros anti-spam, las listas de correo, etc por cada uno de ellos!! --INVIABLE--

Claro, si nos vamos al otro extremo, llegamos al nivel "Café para todos": el correo en esta casa es asi, asi y así para todos los usuarios y no hay excepciones. --INVIABLE--

Así, y como casi siempre, la solución no está en los extremos sino que en un punto medio en el que la satisfacción de los clientes y usuarios se equilibre con el coste en el que incurres para gestionar el servicio de una forma adecuada.

La definición del Catálogo de Servicios

El Catálogo de Servicios es la piedra angular de ITIL en lo referente al tan consabido lema de alineación de las TIC con el Negocio. No deja de ser sorprendente la poca atención que se le presta en los libros centrales de Service Support y Service Delivery a algo tan importante, al mismo tiempo que es uno de los grandes reclamos de productos como el ITIL Survival Kit y similares.

Todo aquel que está interesado en la implementación de alguno de los procesos de ITIL tiene en un primer momento la necesidad o el interés de imaginar qué aspecto debe tener un Catálogo de Servicios y por eso llueven las peticiones de ejemplos, formatos, plantillas o casos de estudio en los que basar el boceto que se está iniciando.

En mi opinión, un Catálogo de Servicios debe cumplir con una serie de requisitos indispensables, a saber:

• Debe tener una orientación especial para tres tipos de perfil diferente: el usuario, que lo utiliza para obtener información al respecto de los servicios a los que tiene acceso y la forma de interactuar con el proveedor de estos servicios (IT), el cliente, que lo utiliza como si fuera la carta de un restaurante (muchas veces se conoce como carta de servicios) y TI, que lo utiliza para dar un enfoque orientado al negocio (alineado) a sus procesos internos.
• Debe contener los atributos necesarios como para satisfacer las necesidades de estos tres tipos de perfil.
• Debe nacer, ya desde su mismo origen, con un espíritu flexible y adaptativo: todo cambia y muy rápidamente.
• Debe ser publicado en un formato electrónico, accesible para todos los perfiles que lo necesiten.

Antes de acometer el redactado global de la descripción detallada de cada uno de los servicios conviene hacer un ejercicio previo orientado a dar respuesta a tres preguntas importantes: ¿Qué es para mí un servicio?, ¿Qué es para mi cliente un servicio? y Siguiendo esta definición, ¿Cuales son los servicios que proporcionamos?

Una vez resueltos estos dilemas, tendremos que decidir la lista de atributos que va a tener cada uno de los servicios; será de gran ayuda hacer un repaso de los diferentes procesos implementados o por implementar a corto plazo y detectar las necesidades de información que tiene cada uno de ellos, algo así como responder a la pregunta ¿Qué le pediría cada uno de mis procesos al Catálogo de Servicios?. Así dispondremos del conjunto mínimo de atributos necesarios, a los que deberemos añadir aquellos atributos que hagan falta para otras actividades o para facilitar la lectura/uso por parte de los clientes y usuarios finales.

Por último, la etapa final del desarrollo del Catálogo de Servicios será realizar un análisis detallado de cada uno de los servicios que hemos identificado para describir cada uno de los atributos. Aquí es donde el trabajo de definición comienza a requerir bastantes más esfuerzos, ya que tendremos que obtener información de muchas fuentes diferentes y convertirla en algo homogéneo.

En ocasiones ocurrirá que haremos preguntas que la organización no está preparada para responder, que no se ha planteado nunca o que tenía “escondidas bajo la alfombra”, y en ocasiones encontraremos que no hay una única respuesta que dar. En estas ocasiones habrá que llegar a un consenso y decidirse por una u otra opción, pero no nos engañemos: la respuesta que demos puede ser determinante para el futuro de la organización TI.

Un ejemplo de este tipo de icebergs escondidos en el mar de los servicios es una pregunta tan “inocente” como intentar decidir cuál es el modelo de métricas que caracterizan el servicio en cuanto a conceptos como la calidad o el uso que se hace del servicio en cuestión. Resulta que muy probablemente nos encontraremos con que todas las mediciones que se están tomando (o que los responsables de los trocitos de tecnología que componen el servicio nos proponen) son orientadas a la administración, mantenimiento, operación o soporte de la tecnología, pero nunca nadie se ha planteado medir el servicio. Si nos dejamos llevar por la sencillez (a preguntas concretas, respuestas concretas, yo me lo creo y asi queda reflejado en el Catálogo), estaremos cualificando la tecnología sobre la que reposa el servicio y no el servicio en sí mismo.

Por último, simplemente recordar que la definición de un servicio (es decir, todo el conjunto de atributos, reglas y relaciones que lo cualifican) acabará formando parte de la CMDB y entrará en el Ciclo de Vida de los Elementos de Configuración, por lo que habrá que contar con ellos en la creación de nuevos servicios, gestión de cambios, relación con el cliente, etc, etc, etc.

¡Buena suerte, inspiración e imaginación!

BIBLIOGRAFIA

The IT Service Catalogue
The ITIL Community forum
Virgin Mobile
How to Produce an Actionable IT Service Catalog