El punto débil de DevOps

Hace algún tiempo leí el libro The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, una novela muy inspiradora al respecto del uso de las técnicas Lean en el mundo de las operaciones IT y su fuerte relación con el mundo del desarrollo y DevOps. Como novela es entretenida, explica y ejemplifica los conceptos fundamentales y es un cuento de hadas, donde todo va de acuerdo a lo que el guionista ha pensado y desemboca en un fantástico final feliz. Desde luego, no creo que sea necesario recordarles a los lectores que lo que pasa en esos mundos imaginarios no siempre se parece a la realidad y al contrario que en el mundo de Fantasía, a este otro lado a veces las cosas no son tan maravillosas. (Nadie piensa que los lobos hablan después de leer Caperucita, verdad??)

En un momento del libro, el protagonista está reflexionando al respecto de cómo acelerar el ritmo de pasos a producción en el equipo de desarrollo (se han puesto el objetivo de conseguir diez –si, 10- despliegues al día) justamente para seguir los consejos que daba el equipo de Flickr en su conferencia de 2009. Parte de esa reflexión le lleva a decir la frase

 

Until code is in production, no value is actually beign generated, because it is merely WIP stuck in the system

o sea… hasta que el código no está en producción no se está generando realmente valor porque es únicamente WIP atascado en el sistema

Claro, el paralelismo con el libro de Service Operations de ITIL® y el sentido de que no es hasta este momento cuando realmente se entrega valor al usuario del servicio es directo… pero mi reflexión posterior me llevó un poco más adelante: recordé aquel post que había escrito al respecto de que en realidad el valor de un servicio no es como dice ITIL® el equivalente a Utilidad x Garantía, sino que debemos incorporarle un factor más: el uso.

Así, pues, y siguiendo con la reflexión, tanto da que seamos capaces de hacer 1, 10 ó 100 despliegues al día, que si el usuario no es consciente de lo que pasamos a producción y no es capaz de usar las nuevas funcionalidades que estamos incorporando, en realidad IT habrá generado su parte de valor pero si damos un paso atrás e intentamos encontrar dónde está el valor aportado/generado por el negocio no lo encontraremos: así, mi propuesta de modificación a la frase es

Until code is properly USED to GENERATE the EXPECTED VALUE, it still will be WIP stuck at any other point of the system

o sea.. hasta que el codigo no sea USADO de forma adecuada para GENERAR el VALOR ESPERADO, seguirá siendo WIP atascado en cualquier otra parte del sistema.

Intenté contactar con Gene Kim, el autor del libro, a ver qué opinaba del tema, pero es un hombre ocupado y no he conseguido llamar su atención… pero sí que hubo otra persona que dio su punto de vista: Byron Miller opinó al respecto diciendo que en el fondo todo lo relacionado con formación, cambios culturales y modificación de procesos debe ser también considerado WIP.

Vamos a ver si soy capaz de explicar hasta qué punto es importante esto: dentro de las metodologías ágiles (Scrum, XP, etc.) hay un aspecto que es fundamental y es lo que llaman la definición de “HECHO”. Sin esta definición no funciona nada… y es algo que está aquí para arreglar gran parte de los problemas que tenemos en las TIC.

Es necesario que todo el equipo que participa en la cadena de valor del servicio llegue a un consenso al respecto de qué significa decir que una petición del cliente esté HECHA. Históricamente, cada uno de los diferentes silos que participan en la entrega de esta petición ha interpretado como HECHO el momento en que lo da por terminado (según su visión especializada de las cosas) y lo pasa al siguiente elemento en la cadena. Así, el analista da por hecho el análisis cuando lo pasa a desarrollo, el desarrollador da por hecho el código cuando lo pasa a QA Testing y toda la división de desarrollo da por hecho el programa cuando lo entrega a producción.

Pero la cosa no debe de ser así. Todo el equipo, completo, debe tener una definición común de hecho. ¿Cuándo está hecho el evolutivo? ¿Cuando entrego a Ops? ¿Cuando lo despliego? ¿o cuando he conseguido que los usuarios lo usen adecuadamente?

Desde el punto de vista del negocio, claramente el evolutivo está hecho cuando entrega el valor prometido y eso sólo se hace mediante el USO, por lo tanto HECHO incluye también la formación, el cambio cultural, la modificación de los procesos de negocio, etc etc etc.

Así que, desde luego, todo ese aspecto soft de la entrega de servicios forma parte del WIP.

Ahora vamos a darle otra vuelta de tuerca a todo esto. Si pensamos en la teoría de las limitaciones, la propuesta de Goldratt dice en parte que dado un sistema, siempre existirá un cuello de botella. Es más, resulta que cualquier mejora que pretendamos aplicar al sistema debe de ser directamente sobre el cuello de botella, ya que si actuamos antes el resultado será un atasco monumental a la entrada del cuello de botella; y si actuamos después nos encontraremos con que no servirá de gran cosa puesto que será la limitación actual del sistema la que no esté entregando suficiente “ritmo” a las piezas que se encuentran detrás de ella. Así, cualquier mejora introducida en el sistema si no es en el cuello de botella, o bien no tiene efecto o bien contribuye a empeorar el rendimiento global del sistema.

Ufff… esto es complicado, pero va cogiendo sentido!

¿Qué pasa cuando agilizamos el desarrollo y no agilizamos los pasos a producción? Pues que se produce un atasco monumental en los PaP, y eso provoca… que la gestión de cambios es “el malo”, el que no deja pasar las cosas a producción, el que es un freno para la organización. Y qué pasa cuando agilizamos también el paso a producción? Que nadie se explica cómo puede ser que no se usen las nuevas funcionalidades de las aplicaciones y que cuando se usan el equipo de soporte y apoyo funcional no da abasto (hemos movido el atasco a otro sitio).

Si juntamos una definición de HECHO con visión completa, en la que el evolutivo está hecho cuando se está usando y está generando valor a la organización, con la “prisa” por adoptar metodologías DevOps que nos permitan hacer diez despliegues al día, nos encontraremos con que ahora el cuello de botella es el usuario, que no es capaz de absorber tanto cambio de forma continuada o la organización no permite que el usuario dedique el tiempo necesario a formación para ser capaz de absorber los diez despliegues al día.

En mi opinión, el ejemplo más claro de esta situación es el mundo de las Apps, en las que se despliegan (no 10 veces al día, pero hay algunos que despliegan al menos una vez al mes) nuevas funcionalidades que son documentadas en un pequeño “Read-Me” o similar que nadie se lee. El resultado? Pilas de nuevas funcionalidades que nadie usa… waste por todas partes porque no se está entregando valor con ese código desplegado, pero un equipo de desarrollo orgulloso de haber conseguido los hitos previstos.

De esa forma, todo vuelve a girar alrededor del “activo más importante de las empresas”: las personas. Las personas son la pieza sobre la que no tenemos capacidad de automatización y por lo tanto será el elemento que siempre será nuestro cuello de botella y sobre el que debemos trabajar en primera instancia, porque de lo contrario lo único que estaremos haciendo será cambiar el atasco de sitio (práctica muy habitual en las organizaciones estructuradas por silos, donde no hay una visión de conjunto: “yo ya he hecho mi parte… el resto no es cosa mía” y donde, además, se ponen objetivos por cumplimientos parciales)

En fin, todo esto ha sido una reflexión provocada por un párrafo en una novela… así que es probable que esté profundamente equivocado. ¿Tienes experiencias al respecto? ¿Trabajas en una empresa DevOps y nos quieres contar cómo transmites todo el cambio a la comunidad de usuarios?

¡Usa los comentarios, por favor!

Postdata: Ops! Por cierto… si somos capaces de hacer diez despliegues al día de correctivos, adelante!!! La comunidad de usuarios y los equipos de soporte lo están deseando! Es decir, todo este discurso es válido cuando el cuello de botella es el usuario por su ritmo de adoptar/asimilar/aprender las nuevas funcionalidades que estamos desplegando. Pero si hablamos de demanda fallo, el discurso es completamente distinto!

Visión sistémica en el outsourcing – o nos crecen los enanos

Llevo varios meses trabajando con diversas empresas que se encuentran en una situación de outsourcing con múltiples proveedores. Cada una tiene sus características, sus situaciones especiales, si carácter; pero eso sí, hay algunos detalles que son factor común. Uno de estos puntos en común es la dificultad que tienen para gobernar los contratos con proveedores de servicios que están trabajando en diferentes áreas.

Cuando una empresa se plantea externalizar parte del trabajo que se realiza debe tomar una primera decisión: ¿por dónde pasamos las tijeras?  ¿cómo “troceamos” el modelo de provisión de servicios al cliente interno para asignar partes de este trabajo a terceros? Básicamente, hay tres respuestas a esta pregunta:

Opción 1:  trocear por servicios – Se le asigna a un proveedor la entrega de un servicio completo, extremo a extremo, hacia el cliente interno. Es una práctica muy poco (o nada) empleada en IT, pero sí que se ve en otras áreas de negocio, donde se le llama Business Process Outsourcing o BPO.

Opción 2: trocear por funciones – Se le asigna a un proveedor la ejecución de una función (un grupo de personas con un cuerpo de conocimiento específico). Esto es lo más habitual en el entorno de IT, y así vemos a terceros realizando “Gestión de Infraestructuras”, “Gestión del puesto de trabajo”, “Gestión de Aplicaciones”, etc.

Opción 3: combinar las dos anteriores con un reparto regional – Cuando la empresa está localizada en múltiples sedes o en diferentes países, se puede realizar una aproximación en la que se asigna una función o un servicio por región geográfica (por ejemplo, la “Gestión del puesto de trabajo” para la región de “Sur de Francia”)

Una vez tomada la decisión, viene la siguiente fase: la creación de los contratos; aquí ya se empieza a diversificar el asunto, y normalmente serán los responsables de las diferentes funciones (del área TI interna) quienes definan los requerimientos para estos procesos de externalización, resumiendo en pliegos o RFPs las necesidades y las primeras guías de cómo se va a gobernar la ejecución del contrato (aparecen los primeros indicadores, los primeros borradores de niveles de servicio y de SLAs, etc)

Si nos fijamos bien, en este momento del proceso comienzan a sentarse las bases de lo que será en el futuro el “nuevo modelo de prestación de servicios” de IT a su cliente (a.k.a. “el negocio), y aquí es donde comienzan a sentarse las bases de los futuros problemas de gobernabilidad: lo que en una primera fase fue la definición holística de un modelo ahora se ha traducido en una contratación por partes y de ahí viene el título de este post: es necesario mantener una visión sistémica del conjunto y es necesario transmitir esa visión sistémica a la contratación por partes.

¿Nunca has tenido la sensación de que gobernar tu departamento de IT se parece a una partida de Whacka-Mole?

Básicamente, la sensación viene producida porque cuando aprietas en un sitio, el problema sale por otro lado… y la razón simplemente es que, a pesar de que en la superficie los contratos con tus diferentes proveedores sean inconexos, por debajo están conectados; entre ellos, con nosotros, con los clientes, con las personas; formando una intrincada red de túneles por las que se mueven los topos, los enanos, los problemas, el dinero y siempre aparecen por donde menos te lo esperas.

Es por esta razón por la que debemos adoptar una visión sistémica, de sistema, de todo lo que ocurre en este entorno.

Yo creo que el mejor ejemplo que se puede dar para entender esto es poner un caso simple: una empresa que tiene un equipo interno de Sistemas (que se encarga de la gestión y administración de las infraestructuras, sistemas operativos, máquinas, middleware como las bases de datos o los servidores web, comunicaciones…), un proveedor externo que se encarga del soporte al usuario y otro proveedor externo que se encarga de la gestión de aplicaciones.

Aquí vemos un sistema formado por 3 componentes (a gran escala) que colaboran entre sí para entregar un conjunto de servicios TI al cliente y que se ven regulados por una serie de contratos. Veamos cómo son estas reglas de juego (simplificadas en aras de que se comprenda bien el ejemplo, claro!)

EQUIPO	RESPONSABILIDAD	OBJETIVOS
SISTEMAS	Mantener las infraestructuras en marcha con los niveles adecuados de capacidad y disponibilidad	Disponibilidad de los Sistemas Rendimiento de los sistemas
SOPORTE	Atender las incidencias y peticiones de los usuarios	Resolución de incidencias en plazos Ejecución de peticiones en plazos
GESTION APPs	Mantener y evolucionar las aplicaciones de negocio	Cumplimiento de plazos y presupuestos de desarrollo

Ante esta situación, si pretendemos gobernar el sistema mediante el uso de indicadores y SLAs nos encontraremos con que:

1. A pesar de tener una correcta disponibilidad y rendimiento de los sistemas, los usuarios pueden estar completamente descontentos (es necesario incorporar una figura que vele por el servicio extremo a extremo, independientemente de las 3 funciones que tenemos en el ejemplo)
2. El proveedor de soporte… ¿cómo nos factura por el servicio? Evidentemente, es justo que a mayor carga de trabajo nos pueda facturar más; sin embargo, la mayor carga de trabajo puede ser generada en otras de las funciones (que, en el caso de Gestión de Aplicaciones es otro proveedor al que no le interesa lo más mínimo reducir la carga de trabajo de Soporte)
3. El proveedor de desarrollo, ¿qué objetivos tiene? Cumplir plazos y ajustarse al presupuesto. Simplemente eso.

Así, en este ejemplo vemos rápidamente que la tarea del CIO será hacerse con un martillo y comenzar a golpear enanos que le irán creciendo eternamente… cambiará 1, 2… hasta 7 veces de proveedores y seguirá con el martillo porque la causa no es una incompetencia del proveedor, sino un sistema diseñado para fallar. Apretará al de soporte, pidiéndole que resuelva en plazos y el de soporte hará hasta que los números se lo permitan. El de desarrollo cumplirá plazos y presupuestos, pero a costa posiblemente de producir desarrollos de baja calidad que llenarán al SAU de llamadas o que malgastarán los recursos de sistemas hasta tener que ampliar máquinas una y otra vez. Ahorraremos en un sitio, pero los costes se irán a otro lado.

¿Y todo esto por qué? Porque los objetivos individuales van en contra de una visión de conjunto. Al tener objetivos individuales en cada contrato, estamos rompiendo la visión de sistemas y estamos primando la creación de silos verticales. Además, no nos engañemos: el objetivo de cada uno de los proveedores de servicios será siempre, salvo contadísimas excepciones, “barrer para casa”, así que o imbuimos la visión sistémica desde el principio, en el propio diseño de “por dónde paso las tijeras” y añadimos esa visión en los contratos y en la operativa diaria, construyendo equipos focalizados no en el cumplimiento de indicadores parciales sino en la entrega real de valor al cliente, o estaremos toda la vida dándole golpetazos con un martillo a los enanos que nos crecen por todas partes. Por ejemplo, podríamos:

1. Hacer co-responsable al proveedor de desarrollo de las implicaciones de su software en soporte y en sistemas.
2. Hacer que el proveedor de soporte sea co-responsable de la mejora continua de las aplicaciones y los sistemas.
3. Hacer que el equipo de sistemas sea co-responsable en la definición de arquitecturas y estándares para apoyar al equipo de desarrollo.
4. Hacer que todos tengan responsabilidad sobre indicadores globales de servicios extremo a extremo.
5. Establecer responsabilidad transversal de la entrega de servicios entre las diferentes funciones.
6. Establecer, como decía Walter en una de las presentaciones del itSMF Catalunya 2011, un único indicador: satisfacción del cliente. Perder un poco el foco en el cumplimiento de SLAs y poner el foco en lo que nos importa: el cliente

Ya lo decía Jim Womack en una de sus últimas conferencias: EL problema es que el poder y el control se ejerce verticalmente, cuando el valor al cliente fluye horizontalmente. ¡¡Gestionemos la horizontal!!

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:

Incidencias, Peticiones, Consultas… Service Requests

Desde que comencé a trabajar en asuntos relacionados con ITSM, allá por el año 96, ya aparecían problemas a la hora de clasificar correctamente los tipos de solicitudes que llegaban a un CAU. Con la entrada de ITIL V2, recuerdo que enseñaba en los cursos de formación la Gestión de Incidencias y luego aclaraba que “aunque la teoría dice esto, en realidad recibimos muchos tipos diferentes de llamadas”, asunto que provocó un artículo en este mismo blog titulado Una Queja no es una Incidencia.

Con la llegada de ITIL V3 apareció de la nada un nuevo proceso llamado “Gestión de Peticiones”, que nos permitía romper aquel flujo único en dos, cosa que desde el principio ya fue aceptada positivamente, ya que separábamos lo que podríamos entender como Demanda Valor de lo que sería Demanda Fallo, pero cuando vas a la vida real te chocas con dos asunto básico: (a) un mismo flujo no sirve para todos los tipos de peticiones y (b) no es tan fácil saber, en el momento en que tienes al usuario al teléfono y apenas un par de minutos para atenderlo y registrar, si lo que el usuario quiere es una incidencia o una petición.

Las diferentes aplicaciones de ITIL en las que he trabajado (nótese lo premeditado de no utilizar la palabra implantación) han lidiado con este problema de diferentes formas, muchas veces en función de lo estandarizado que se tuviese la lista de peticiones o de las capacidades de las herramientas para soportar flujos, ordenes de trabajo, plantillas, etc.

Más tarde comencé mi viaje por el mundo del Pensamiento Lean, en el que fui a parar a la lectura del libro Lean Solutions de Jim Womack y Daniel Jones. En este libro se describe una forma de canalizar las peticiones del consumidor en lo que se denominan pathways de tal forma que se pueda estandarizar, optimizar y priorizar el trabajo en cada uno de estos caminos [cosa que nos resolvería el punto (a)]

Por otra parte, el estudio de una de esas obras poco difundidas pero de gran valor que es el libro Guide to the Universal Service Management Body of Knowledge (USMBOK) me llevó a ver que el planteamiento que se realiza en USMBOK es el de recibir todas las peticiones de consumidor, sean del tipo que sean, en una entidad llamada Service Request, que se clasifica según diferentes tipologías, entre ellas:

1. Peticiones de servicio procesadas automáticamente por el motor de transacciones
2. Peticiones de servicio derivadas de que una de las de tipo 1 ha fallado (incidencias)
3. Peticiones de servicio procesadas con intervención humana, pero no del tipo 2
4. Peticiones de servicio que solicitan la modificación del servicio (Petición de Cambio)

Esta aproximación nos resuelve el punto (b) ya que todo es una Service Request que luego es fácilmente reclasificable entre los diferentes tipos. Por otra parte, ayuda a implementar el concepto ITIL V3 de CSI Register (que USMBOK incorporaba previamente como Project Incubator) y permite ver toda la demanda agregada (cosa crítica ya que todos los diferentes tipos de demanda compiten por los recursos finitos de la organización proveedora de servicios).

Así, si unimos todo esto en un modelo único, lo que obtenemos es que hay diferentes formas de canalizar una Petición de Servicio hacia la organización proveedora de servicios, y diferentes tipos de petición que se pueden realizar. Por otra parte, la organización proveedora puede recoger todas estas peticiones y canalizarlas a través de diferentes flujos de actividad para su realización. Esto, aunque es de sentido común y podría parecer obvio, choca con estándares oficiales y de-facto que plantean flujos únicos para el tratamiento de las peticiones, mientras que la combinación Lean + USMBOK nos lleva a un tratamiento detallado y unificado de la demanda, tal y como podemos ver en los siguientes gráficos.

Puede parecer complicado, pero es una forma de incrementar el detalle de nuestra gestión de una forma gradual (incorporando nuevos tipos de petición con sus correspondientes pathways) que nos permitirá luego aplicar las técnicas Lean de mejora continua a elementos más pequeños y atómicos como es una petición concreta. Con una definición de la gestión al nivel de “Gestión de Peticiones” no tenemos la granularidad necesaria como para poder mejorar ni plantear objetivos de nivel de servicio ni criterios de comparación… ¿Te imaginas haciendo un benchmark del tipo “cuánto tiempo tardas en resolver peticiones” o “qué coste tienen las peticiones en tu organización”? ¿Y del tipo “cuánto tiempo tardas en proporcionar un equipo a un nuevo empleado” o “cuánto te cuesta el alta de un usuario”?

Hay otras maneras de hacer las cosas, no dejemos que las best-practices nos impidan pensar. Recordemos la máxima de la familia Atreides en Dune (un guiño cariñoso a Luis Moran)

El camino fácil dirige, inevitablemente, al estancamiento

enseñanzas de las Bene Gesserit
Dune

¿Quieres saber más?

Crónica de una reparación

Se ve que estos meses son de fallar las cosas, así que esta vez traigo un ejemplo que, si bien es poco importante, me pareció interesante como caso de estudio de cosas que se pueden mejorar en un servicio de atención al cliente.

Antes que nada, no se vayan a pensar que soy un quejica que protesta por cualquier frivolidad: el caso, insisto, no es algo grave ni especialmente molestoso; sólo sirve para analizar un poco el proceso de atención al cliente.

El asunto es que a finales de Agosto se rompió el teléfono fijo de casa. Lo habían traído los Reyes estas navidades pasadas y estaba en garantía, de modo que allá que partimos al centro comercial donde lo habíamos comprado con la esperanza de que nos lo cambiaran por otro.

Aquí aparece el primer mensaje del caso de estudio: vamos a la tienda a realizar una Petición de Servicio porque un aparato se ha roto… ese es el tipo de Demanda más dañino con el que nos podemos encontrar, porque el Centro de Atención al Cliente tendrá que trabajar para algo que no le aporta valor a la organización y sólo me aporta valor a mi porque se ha roto. Se llama Demanda Fallo (Failure Demand) y es algo a evitar a toda costa.

Pregunta: ¿Cuánto invierte tu organización en Demanda Fallo? ¿Se podría evitar? ¿Estaría mejor invertido ese dinero en otro tipo de actividades? [ ¿Cuánto dedicas a mantenimiento correctivo y a gestión de incidencias? ]

Ya habíamos tenido contacto con el Centro de Atención al Cliente de esta tienda, así que sabíamos que nos tocaría aguantar un buen rato de cola… un buen rato, sí, pero… ¿1,5 horas? Así fue… llegamos, pillamos el número del Turn-O-Matic y esperamos… las niñas aburridas, el calor, el ruido… nos leímos el catálogo de ofertas, dimos un paseo por la tienda, esperamos en la calle, esperamos en el CAC… hasta que nos tocó el turno!

Aquí tenemos otro aspecto interesante relacionado con aquellos principios de Lean: 1,5 horas de espera para contactar con un CAC es algo exagerado. El mostrador del CAC tenía 4 terminales, pero sólo había una muchacha atendiendo. Siempre hay unas colas terribles en este lugar, lo que demuestra que el foco está puesto en la venta (asesores, cajeras, de todo! No falta personal en la zona de ventas!)

Después de la espera, la muchacha que nos atendió tomó nota de mis datos y me dijo que enviarían el teléfono a reparar, me pidió la dirección de email y el número de móvil. Me dijo que contara 30 días y que me avisarían para pasar a buscarlo. Firmé el comprobante (en el que decía que lo había entregado todo con el embalaje original) y me fui con la familia a que nos diera el aire en otro sitio.

30 días sin teléfono! No está mal en los tiempos modernos! Aquí no había SLA ni nada parecido, pero en otras ocasiones (un DVD roto, un TDT sin mando… nada importante) ya nos habían dicho siempre que 30 días.

En casa teníamos plan de contingencias: mi mujer, que es súper ordenada y lo guarda todo, tenía el teléfono antiguo; le fallaba el display pero podíamos llamar, así que podíamos esperar 30 días sin mayores problemas.

No habría pasado nada ni yo hubiera escrito esta entrada si no hubiera sido porque un buen día, una semana después de toda esta historia, me llegó un SMS a mi móvil (sin número de origen) que decía literalmente

LE ROGAMOS TRAIGA LOS ACCESORIOS DEL PRODUCTO DEPOSITADO EN NUESTRAS DEPENDENCIAS.

¿Mande? Yo entregué todos los accesorios! Y tengo un comprobante que así lo dice, pero.. el SMS no tenía número, no me habían enviado un mail así que no podía responder… y yo pensaba ¿Otra hora de espera para nada? y ya me iba calentando yo solito…

Total, que cuando llegué a casa llamé por teléfono al sitio en cuestión, a ver si podía aclarar qué accesorio les faltaba… riiing, riiing y me contesta una de esas máquinas odiosas que te preguntan 7 cosas (por ejemplo, me preguntaba 2 veces en qué idioma quería que me atendiera) para al final llegar a que me pedía un número de expediente y me respondía (a la tercera o cuarta, cuando torpe de mi conseguí atinar con el número que me estaba pidiendo) que tenía que pasar por el Centro del Atención al Cliente.

Luego me fui a la web, donde después de mucho buscar encontré un sitio donde si entrabas un número y los apellidos me dijo… ¡Que el aparato estaba listo para su recogida!

Una lección más: cada interacción con el cliente, ya sea humana o mecanizada se convierte en lo que llamamos un momento de la verdad. El servicio de atención se la juega en cada uno de esos momentos y se puede romper toda una buena imagen de atención con un momento de la verdad mal diseñado [un SMS que no me permite responder] o mal ejecutado [una máquina que no me permite interactuar]

Así… ¿qué querían estos señores, que llevara accesorios o que recogiera mi teléfono? Sea como sea, estaba condenado a ir de nuevo a la fatídica tienda… cogí a la familia, otra vez, y nos fuimos al centro comercial.

Entro en el CAC, me voy directo al Turn-O-Matic, cojo mi número y miro al indicador luminoso… que estaba apagado! Miro a mi alrededor y no veo nada que me indique por qué numero van, así que le pregunto a la chica (la misma de la otra vez) y me dice “No, es que está roto.. tiene que pedir la tanda”…

¡Qué graciosa! ¡La tanda, como en la pescadería! Así que pregunto “Quién es última?” y me responden 2 o 3 a la vez… ¡Ya la hemos liado! Mientras nos ponemos de acuerdo han entrado por lo menos 3 personas más al CAC que han ido a coger su numero y no se han dado cuenta de la movida… madre mía la que se está montando!!

Bueno, ahora que la cosa va por tanda no me puedo mover de allí, así que la espera se hace eterna. Unos 40 minutos más tarde me toca el turno y le digo a la chica que me había llegado un SMS diciendo que tenía que entregar accesorios, pero que los accesorios ya los había entregado todos…

“Ah, si..” – Me dijo – “Eso te lo envían cuando te van a hacer una sustitución del aparato; déjame que mire el expediente… a ver… si, aquí está: no tiene reparación, pero como no hay en stock, te haré un vale por el importe del teléfono” y me hizo una tarjeta por unos 40€ que es lo que costaba el maldito aparato…

Aquí podemos ver otra de las “alegrías” del caso: el momento de la verdad estaba tan mal diseñado que enviaba mensajes falsos al cliente! Precisamente el mensaje que me hizo poner de mal humor. Y por si fuera poco, es error habitual que los empleados conocen y les parece tan normal que nadie lo ha resuelto.

Finalmente, me ahorro de discutir con la señorita al respecto de si cuando yo pagué utilicé dinero de verdad o si les pagué con un vale; así que recojo la tarjeta-vale, me voy a la tienda y me compro un teléfono de la misma marca, mejor, más moderno y más barato.. cosas de la tecnología.

Podemos aplicar las ideas de Lean para analizar este caso, más allá de los comentarios que he ido intercalando:

1. El concepto de PathWay nos podría ayudar aquí: habilitar “rutas” especiales para actividades especiales... por ejemplo, una cola para entregar material y otra cola para recogerlo, ya que el procedimiento de entregar el material es mucho más lento que el de recogerlo.
2. El concepto de derroche en forma de tiempos de espera innecesarios, colas, movimiento de materiales (si realmente se llevaron el teléfono a un centro de reparaciones, el gasto fue importante!). ¿Qué tal si se decide que aparatos de menos de 100€ que no funcionen y lo que no funcione no sea una pieza móvil directamente se reembolsan? (Y si después resulta que si que funcionaba o tenía fácil reparación, lo vendes en un outlet tipo cash-converters)
3. El concepto, ¡cómo no! de momento de la verdad: esa máquina de enviar SMS hay que utilizarla lo menos posible: si el cliente ha proporcionado una dirección de email, se le debe enviar un mail para que la comunicación sea bidireccíonal. Y por supuesto, enviando los mensajes correctos! Por otra parte, cuando el Turn-O-Matic no funcione, pon un cartel que así lo indique, que ya nos organizaremos como en la pescadería.
4. El concepto de Actividad de Valor Añadido y Actividad de No Valor Añadido (VA y NVA): si representásemos el mapa de flujo de valor para esta transacción, veríamos que, a grosso modo, hay unas 200 horas de NVA frente a 10 minutos de VA… un ratio de aportación de valor al consumidor del 0,083% (!!!!)
5. El concepto de reducción de las esperas: ¿qué tal si paralelizamos y ponemos a 4 personas a atender en los momentos en los que haya picos de trabajo? Si, ya se que esto de la atención al cliente no aporta ventas pero así como vamos ahora, a)Algunos no vuelven a comprar b)Las extensiones de garantía esas que ofrecen no se deben vender mucho.
6. Walk the Gemba: Womack lo ha defendido en prácticamente todos sus libros; la verdadera gestión se debe ejercer desde el conocimiento de lo que ocurre en el lugar donde se encuentra la verdad (Gemba), osea, donde se trabaja; el director se pasa habitualmente por el CAC? Seguramente no… seguramente no lo utiliza cuando se le rompe uno de sus gadgets, y por lo tanto tienen que ser los clientes los que te hagan ver cómo funciona, visto desde fuera, la atención al cliente.

Bueno.. insisto, este ladrillo es más un ejercicio de análisis que una queja… y quien sabe! Igual los chicos de esa tienda lo leen alguna vez, les sirve de “consultoría gratuita” y la próxima vez que se me rompa alguno de sus productos me llevo una sorpresa tan grata como la del post anterior.

Dirigir para o por los indicadores

Después de leerme detenidamente un par de veces los artículos publicados por Artur Tallada (Teoría Básica de Indicadores) y Mariá Cano (Ingeniería de Indicadores) me quedé con una espinita clavada que me pedía a gritos escribir un poco sobre el tema.

Del artículo de Mariá, me encantó la “demostración de fuerza” matemática y la aportación de ciencia en algo que cada vez está más desprestigiado. Del artículo de Artur me llamó la atención el uso de un indicador de “Porcentaje de Mejora”, calculado en base al incremento sobre la situación inicial en relación al objetivo marcado, de manera que cumplir el objetivo es un 100% de mejora y empeorar la situación nos da un % de Mejora negativo.

A primera vista parece interesante, porque me permite “normalizar” un conjunto de objetivos marcados y realizar operaciones entre ellos con lo que los puedo agregar y dar un índice mixto. La principal ventaja que tiene este indicador es que es profundamente “marketiniano” y sirve para ponernos medallas en una nota de prensa, comunicado o aparición en público, ya que oculta completamente el objetivo marcado.

Esto se trasluce claramente en la disertación de Artur mediante la utilización del Principio de Maximización  y el Principio de Minimización, mediante los cuales se nos insta a ponernos objetivos alcanzables cuando sean fáciles de obtener (con lo que el % de mejora será muy alto, incluso mayor del 100 en función de cómo se calcule) y poner objetivos exageradamente ambiciosos cuando la cosa sea especialmente difícil, para camuflar los empeoramientos en forma de pequeños porcentajes negativos.

Seguramente el párrafo anterior te haya resultado igual de chocante que me pareció a mi la lectura del artículo de Artur, pero ciertamente es así y eso nos lleva a dos reflexiones importantísimas para toda la Teoría de Indicadores y para los principios de dirección por objetivos:

a) ¿Estamos seguros de que cuando montamos un esquema de indicadores orientado a la mejora (del servicio, de la gestión, de los procesos, de lo que sea) el equipo que realiza las tareas va a dirigir o gestionar POR los indicadores y no PARA los indicadores?

En el preciso instante en que una persona se da cuenta de que el cumplimiento de determinados objetivos (la zanahoria) le afecta de alguna manera (por regla general, económicamente), inmediatamente comienza a tomar decisiones orientadas a satisfacer el objetivo, y no a satisfacer lo que podríamos denominar “el espíritu del objetivo”.

Si a un vendedor le ponemos un objetivo de ventas que afecta a su prima trimestral, venderá; pero ¿qué venderá? Lo que haga falta! Lo que importa es cumplir el objetivo, no vender aquello que el cliente necesita o aquello que genera mayores beneficios, sino aquello que más fácilmente me haga cumplir el objetivo.

Si a un profesor le ponemos como objetivo un porcentaje de aprobados, aprobará a sus alumnos sin preocuparse del “espíritu del indicador”, que es que los alumnos aprendan y, de rebote, aprueben.

Así, dirigir POR el indicador es utilizar el indicador para orientarnos, para ayudarnos a tomar decisiones y, como un GPS con un mapa y una ruta establecida, servir como herramienta para la dirección y como seguimiento de la planificación estratégica realizada, mientras que el dirigir PARA el indicador es una aproximación cortoplacista y poco corporativa a la gestión.

b) ¿Estamos seguros de haber establecido la necesaria segregación de funciones en nuestro modelo de indicadores?

Tenía un cliente que siempre que hablaba de contratos de ousourcing y seguimiento de SLA’s hacía la misma pregunta: ¿Quién corrige los exámenes, el alumno o el profesor?.

La persona/rol/función que define el indicador y sus objetivos, no puede ser la misma que la que realiza las tareas/actividades/procesos/servicios medidos por el indicador. En caso contrario, ocurrirá que el que establece el objetivo aplicará los Principios de Maximización y de Minimización y manipulará sutilmente los indicadores o las fórmulas de cálculo o los objetivos para cumplir siempre (con mayor o menor elegancia, claro)

De la misma manera, la persona/rol/función que realiza las tareas/actividades/procesos/servicios medidos no puede ser la misma que la que obtiene las mediciones, calcula los indicadores y reporta el cumplimiento o no de los objetivos.

Dicho esto, ¿Quién genera los informes de SLA en tu contrato de outsourcing?

Discusiones, reflexiones y alineación con el “negocio”

Seguimos de mundo 2.0… En los tiempos en los que estaba en la Universidad el grupillo de amigos montó una lista de correo que hoy en día, casi 20 años después, sigue funcionando a la perfección.

La usamos para quedar a tomar cervezas, para comentar cotilleos de que si Manolo ha tenido una hija o que la Loli se ha comprado un perro, para discutir temas profundamente tecnológicos del tipo “qué me compro, una tele de LED con HDMI y upscale o un iMac y un proyector?” y de vez en cuando para cosas de trabajo o reflexión sobre la profesión.

Esta semana ha habido una discusión interesante y después de pedirles permiso a los amiguetes, aquí va un trozo de corta y pega de la conversación porque me ha parecido realmente interesante. Todo empezó cuando yo lancé un tweet con el último post de Outi Nyström, entonces @dassun me contestó, al cabo del rato entró @werwerf y la cosa siguió ya por email.

@dassun:

Todo comenzó con este tweet de Antonio:

avallesalas

RT: @OutiNy: Check out this site:http://outinystrom.blogspot.com/ Cadena de Valor en TI empresarial <- Interesante!

12:20 AM Jun 19th via Echofon

que me llevó a un artículo en el que se leía:

Si somos capaces de ser excelentes en la gestión de estas tareas, automáticamente nos convertimos a un "trusted advisor" de nuestro partners de negocio en la compañía.

Yo encontré la grase graciosa (no por el error gramatical, el artículo lo escribe Outi Nyström, queda escusada) sino por partners de negocio en la compañía cuando es nuestra compañía. Desde mi punto de vista IT no es ni un partner ni una unidad de negocio. El discurso me parece una reacción al menosprecio de IT en muchas organizaciones, que la ven directamente como un gasto. Y ya que ellos no cambian, IT ha de alinearse con el negocio y ser partner e incluso ser unidad de negocio y facturar por sus servicios... Vamos, ya que no nos dan amor, al menos que nos den dinero.

Mi punto es pues que IT da un servicio dentro de la empresa (como lo hace administración, contabilidad o RRHH) que puede ser considerado un gasto si es posible, mediante la estandarización y, por lo tanto el uso de tecnologías no customizadas o un valor añadido si, gracias a IT, la compañía tiene una ventaja competitiva. Este último es el sueño húmedo de IT, el marcar de chilena en la final del mundial de cualquier niño. Pero ocurre lo mismo con cualquier otro departamento que da más que la competencia. Con la diferencia de que nadie en su sano juicio se gastaría millones en desarrollar un novedoso sistema de contabilidad para conseguir añadir valor a la compañía :)

Si queréis generar valor, iros al core de la compañía (el desarrollo y venta de software de transporte en nuestro caso, el desarrollo y venta de medicamentos en el caso de DavidW). Lo demás está a un paso de la estandarización y el outsourcing.

A lo que yo contesté:

No descubriremos qué fue primero, la gallina o el huevo, el menosprecio de unas TIC vistas sólo como un gasto o las TIC que se lo han ganado a pulso… lo que es cierto es que en muchos sitios esa es la situación actual. ¿Cómo salir de ese ciclo?

Efectivamente nadie va a invertir, como tú dices, una pasta en un novedoso sistema de contabilidad, pero si que van a escuchar al financiero si propone novedosas maneras de reducir impuestos o de sacarle más partido a la pasta que tenga la compañía invirtiendo en bonos del estado o yo que sé… así como también le van a escuchar si propone un cambio en la contabilidad que les permita conocer el coste por [producto, servicio, línea de fabricación, proceso de negocio] de tal forma que se pueda optimizar el mismo.

Por eso lo que yo planteo: la mejora (innovación o como le quieras llamar) se debe producir con equipos multidisciplinares: los de TIC no sabemos de contabilidad, ellos no saben de arquitectura IT y ninguno de los dos sabemos de fabricación de Nolotiles y, por otra parte, cada mejora puede producir mayormente dos efectos:

a) Una reducción en los costes de hacer lo mismo que hacemos ahora

b) Una diferencia en las cosas que hacemos ahora, lo que nos puede dar una ventaja competitiva puntual

Eso de la diferenciación “puntual” viene porque con cada salto, el mercado copia lo que parece bueno y pronto deja de ser diferencia para ser “lo normal”, así que hay que estar permanentemente dándole vueltas al tarro para ver cómo conseguimos otro salto.

La cosa se pone interesante, y se nos cuela @mgbuddy en medio aportando su punto de vista:

Cuando trabajaba en Lemmerz, la decisión de comprar una nueva línea de producción, un nuevo robot o cualquier cosa de la planta, siempre era una decisión que parecía clarísima.

No se de donde surgía esa decisión, pero nadie la dudaba y siempre funcionaba. Todo el mundo sabia lo que haría esa nueva maquina (O se lo creía a pies juntillas) y para que se compraba. Y normalmente hacia lo que se le presuponía.

Porque no es igual en IT? porque siempre hay dudas?

Porque ha fallado demasiado durante demasiado tiempo y nadie se lo cree...  La informática se ha metido demasiado rápido en muchos temas para lo que no estaba preparada (O no estaban preparados los ingenieros, o era demasiado barata).

El software del Challenger no falla (No fallaba). Es anodino, pero esta hecho de manera que parece una Ingeniería de verdad. Es muy poco glamuroso pero funciona perfectamente y no falla.

Lo que pasa es que eso es tan caro como una nueva línea de producción en una planta. Que es lo que debería costar, pero nadie acepta esos costes. Siempre hay alguien que lo hace mas barato.

Aquí entra en escena @werwerf… uno que se pasó al “lado oscuro”, abandonando las TIC y ahora es el rey de los Procesos de Negocio:

Panda de capullos!

Empezáis una discusión interesantísima y yo con un pie en la carretera (otra vez a Alemania)...

Dicho esto, dos cosas:

1) Twitter es una mierda para discutir

2) El gran problema de IT/IS comoqueraisllamarlo es que nunca hemos sabido hacernos marketing y nos hemos masturbado tecnológicamente durante años dando soluciones que, en la mayoría de los casos, solo daban mas trabajo (exagero, pero es la visión del negocio...)

Solo hay dos maneras de hacerte atractivo al negocio: los "green dollars" y los "blue dollars".

Los dólares verdes son los contantes y sonantes, que en el caso de IT (va, por hacer corto usare IT) es ahorro, menos gasto por el mismo servicio. Los azules son las oportunidades; puede no representar un ahorro o representar una inversión (y digo bien inversión) pero reporta a la empresa en efectividad, optimización de recursos, etc.

Ejemplos de dólares verdes: economías de escala (lo que hace Boehringer ahora), centralización de los servicios de infraestructura

Ejemplos de dólares azules: Business Intelligence, permite dar al negocio una mayor visibilidad y proyectar el futuro.

Y es todo lo que hay! Es todo lo que va a entender el negocio. Lo demás son pajas mentales que nos hacemos para que nos quieran... No nos van a querer, ni falta que hace. Lo que hay que demostrar es que aportamos dólares verdes y azules a la empresa.

Que siempre nos ponen en duda? Como a RRHH y a Finanzas y a Servicio Generales y al Dept. Médico y a Soporte a la red de ventas y... Es parte del juego.

En el caso peor, una empresa puede llegar a externalizarlo todo, pero allá ellos...

Salvo que trabajes en HP o en TSS (donde la informática es core de negocio), el panorama es este; luchar y luchar para demostrar green and blue y que no te externalizen...

¿Interesante? Aún no hemos acabado… de repente aparece por la banda derecha el amigo @querty72 dándole una puntillada al gremio:

Como en casi todo (menos en el tema Apple) Werfwerf tiene razón...
... sólo añadiría la PUTA manía que tiene muchas veces el negocio en querer decidir sobre la tecnología: a IT le deben pedir la solución para un problema/proceso/oportunidad aportando los requerimientos a cubrir.

Por desgracia, no suelen quedarse ahí dejando que IT decida cómo integrar eso en su infraestructura y adecuándolo a su plan estratégico.. no, suelen traer bajo el brazo el CRM tal o la plataforma pascual y ya se ha liado gorda.

De todas formas admito que en todo esto debo tener una visión subjetiva por ser parte implicada y no haber visto mucho 'mundo' más allá de los barrotes de la jaula :)

Aquí la discusión ya se diluye… ha aparecido en un mismo hilo Apple, estrategia IT y Negocio.. con qué crees que nos quedaremos para seguir charlando? Evidentemente, por mucho que se empeñen, el iPad romperá esquemas y nos hará cambiar la forma en la que vemos el mundo… :-)

Y tú… qué opinas sobre el tema?

La evolución cuántica

Hoy quería escribir al respecto de los diferentes ejes que dirigen la generación de valor por los servicios TI. El primer aspecto que debemos considerar es el de recorrido histórico: la Informática es una profesión relativamente joven que en pocas décadas ha conseguido revolucionar la forma en la que las empresas utilizan la información, tanto para los procesos internos y de soporte como para articular sus relaciones con clientes y proveedores.

La evolución ha sido meteórica y ha motivado cambios profundos en la forma de hacer negocios, pero esa velocidad de cambio (y no me refiero al cambio puramente tecnológico, sino al cambio en la forma en la que las organizaciones se relacionan con clientes y proveedores) es cada vez ligeramente más lenta.

Uno de los motivos importantes es que las TIC se han convertido en un factor higiénico: las siglas TI están pasando lentamente de significar Tecnologías de la Información a significar Tecnologías Invisibles y, cuando están presentes no las notamos pero cuando faltan se produce una situación dramática.

Hay muchos inventos de la Humanidad a los que les ha ocurrido esto, de hecho es la forma habitual de evolucionar (a saltos, cuánticamente): ¿Es importante la electricidad? ¡Desde Luego! Pero estamos tan acostumbrados a ella que ya no nos parece un invento revolucionario; simplemente está: pulsamos un interruptor, una luz se enciende y nos parece lo más normal del mundo.

En las empresas ocurre exactamente lo mismo: el ERP está y cuando hay que procesar un pedido se rellenan unos formularios y nadie le da mayor importancia… hasta el día en que no funciona: entonces el mundo se viene abajo.

Es por esta razón que para aquellos servicios que están en marcha las características realmente vitales, aquellas que siempre veremos sobre la mesa del CIO son la capacidad y la disponibilidad: las Tecnologías Invisibles se convierten en un factor higiénico y queremos, sobre todo, que sigan siendo Invisibles.

Pero las Tecnologías Invisibles no son revolucionarias, no facilitan que las organizaciones se diferencien significativamente de su competencia ni que ganen cuotas importantes de mercado ni que inventen (o accedan a) mercados nuevos. Para eso es necesario que en ocasiones las TI dejen de ser invisibles y pasen a significar Tecnologías Innovadoras, ayudando a crear nuevas formas de operar, de relacionarse con clientes y proveedores, de facilitar el consumo de nuestros productos y servicios o simplemente reduciendo significativamente los costes de la compañía facilitando un comportamiento más agresivo y diferenciador en el mercado.

Este segundo eje de aportación de valor es el que se articula consiguiendo que TI y negocio trabajen juntos, integrados, para la definición, diseño y construcción de nuevos Servicios TI innovadores y, en mayor o menor grado, revolucionarios.

Pero no nos olvidemos de un aspecto importante: una vez diseñado y construido, el servicio TI no es nada más que una simple herramienta en manos de aquellos que verdaderamente deben crear valor para la compañía: los USUARIOS: aquellas personas que usan la herramienta que TI les ha proporcionado generando los verdaderos resultados para la organización.

En resumen, vemos que la aportación de valor de TI hacia la organización se compone del factor revolucionario aportado por las Tecnologías Innovadores y de la presencia permanente del factor higiénico aportado por las Tecnologías Invisibles, mientras que el valor generado por el negocio gracias a las Tecnologías de la Información estriba en el correcto USO de las TI, de manera que podemos ampliar la definición de valor propuesta por ITIL V3 con una aportación que trata de mostrar el valor generado por el negocio gracias al uso de las TIC como:

VGN=VS x USO, donde

VGN= Valor Generado por el Negocio

VS=Valor aportado por el servicio TI

USO=Uso de las TIC por parte del Negocio

por lo que

VGN=(Utilidad x Garantía) x Uso

Esta función devuelve el valor cero en caso de que cualquiera de sus tres componentes sea nulo.

NOTAS:

(1) Este artículo nace como reflexión para la mesa redonda del itSMF al respecto del valor aportado por el concepto de servicios, pero no me pareció adecuado como discurso porque disponía de poco tiempo y no encajaba 100% con la temática.

(2) La primera mención a las Tecnologías Invisibles se la escuché a Ian Clayton en el congreso de Octubre de 2009.

La Gestión Financiera de las TIC - Presupuestos

En lo que se refiere a la relación con el Cliente, hay tres herramientas que son la columna vertebral de cualquier modelo de Gestión de Servicios TIC: la Gestión de la Demanda, que permite responder a la pregunta ¿Qué quieres que te dé?, la Gestión de Niveles de Servicio, que responde a la pregunta ¿Cómo quieres que te lo dé? y la Gestión Financiera, que responde a la pregunta ¿De cuánto dinero dispongo para hacerlo?.

En este último punto, aparecen tres grandes prácticas o subdivisiones, totalmente relacionadas unas con otras: la Gestión Presupuestaria, la Contabilidad de Costes y finalmente la Gestión de la Facturación.

Nos centraremos en este artículo en las dos primeras, porque la facturación requiere una visión completamente diferente.

Cualquier CIO de cualquier organización del mundo se enfrenta periódicamente al reto de preparar los presupuestos del periodo siguiente. Para ello, se encuentra con que hay unas condiciones de contorno especiales: por una parte está el paquete necesario para “mantener el negocio como hasta ahora” (lo que los angloparlantes llaman el business as usual) y por otra parte está todo el paquete necesario para acometer la variación (mejoras en los servicios actuales o nuevos servicios a construir), por lo que todas las entradas provenientes de la Gestión de NIveles de Servicio y de la Gestión de la Demanda son especialmente importantes en este momento.

Pero también existe una condición administrativa importante, que es la que obliga a que el presupuesto del área TIC se pueda combinar con el resto de presupuestos de la organización para que la alta dirección pueda disponer de una visión completa y agregada de las previsiones de gasto e inversión en la compañía. Esta necesidad es la que provoca que se requiera de un paquete estandarizado de partidas presupuestarias que serán comunes a todas las unidades organizativas.

Es precisamente esta necesidad de agregación corporativa la que provoca que los presupuestos TIC suelan tener una estructura “artificial” que no facilite especialmente la gestión de la operativa económica del departamento y por lo tanto el CIO se ve en una situación en la que o bien mantiene una “doble gestión” o bien se mueve por intuición en un terreno peligroso.

Trabajando de esta manera, los presupuestos tienen tienen la misma estructura en todas las unidades de negocio, lo que le facilita la visión a la alta dirección, pero para que el CIO pueda articular una correcta Gestión de Servicios es necesario que el presupuesto adquiera una dimensión adicional: la de los servicios. Cuando conseguimos esta segunda dimensión, de repente nos damos cuenta de que tenemos en nuestras manos una de las herramientas más potentes que proporcionan las metodologías de gestión para objetivizar y racionalizar la relación con el cliente.

La gran contrapartida que tiene esto, es que no basta con sólo realizar un presupuesto; luego, a lo largo de todo el año será necesario realizar un seguimiento del presupuesto, lo que significa que entra en juego el segundo subproceso de la Gestión Financiera: la contabilidad de costes. Será necesario que durante todo el año vayamos realizando una contabilización de cada uno de los gastos que se realicen y los vayamos distribuyendo como costes directos o indirectos a cada uno de los servicios, de manera que esto nos permita responder a la gran pregunta: ¿Cuánto te ha costado cada servicio? (que es mucho más interesante que "¿Cuánto me cuestan las TIC?)

Teniendo esta información, ahora podremos tomar decisiones importantes (de reducción de costes, de continuar la inversión, de actualización o renovación tecnológica…) con criterios objetivos y de acuerdo con la estrategia corporativa: hemos construido, casi sin darnos cuenta, una de las principales herramientas de alineación y estrategia del área TIC.

PS: Dedicado a todos aquellos que me aprietan para que siga escribiendo, a pesar de lo que me está costando últimamente. ¡¡Gracias!!

Subcontratando el riesgo

Tanto el blog de Joseba Enjuto como el de Javier Cao tienen un sitio preferente en mi lector de feeds, así que he podido leer en estos días un par de artículos muy interesantes: Caracterizar un Servicio, de Joseba y una reflexión generada por este primer artículo llamada La Subcontratación del Riesgo de Javier.

En ambos artículos se habla de la componente de riesgo que hay en la externalización y Javier acaba con una frase matadora:

Por que de lo contrario, cuando el Responsable de Seguridad vaya a comprobar qué ha pasado, podrá encontrarse al Steve Urkel de turno diciendo ¿he sido yo? y la cabeza a cortar será la que quien contrató un servicio inadecuado.

Es decir, que no se puede subcontratar o externalizar "a lo loco", sino que siempre debe quedar una capa de control y supervisión dentro de la propia organización para garantizar que se realice un seguimiento adecuado de lo que se ha contratado fuera.

Aquí (como en tantos otros sitios) COBIT nos puede ayudar. El Objetivo de control de alto nivel DS2 indica que se deben gestionar las relaciones con terceros. Fijémonos qué nos dice en la descripcion del OCAN

La necesidad de asegurarse de que los servicios proporcionados por terceros cumpla con los requerimientos del negocio requiere de un proceso de gestión apropiado. Este proceso se cumple mediante la correcta definición de roles, responsabilidades y expectativas al respecto de los acuerdos con terceros, así como revisando y monitorizando dichos acuerdos buscando su efectividad y cumplimiento. Una correcta gestión de estos servicios minimiza los riesgos asociados a proveedores poco efectivos o productivos.

Ajá! Una correcta gestión de los servicios minimiza los riesgos asociados a los proveedores... vamos bien. ¿Y los objetivos de control detallados?

DS2.1 Identificación de las relaciones con proveedores. Básicamente, mantener un catálogo de proveedores "homologados" con información al respecto del tipo de proveedor, solvencia, significatividad y criticidad.

DS2.2 Gestión de la Relación con proveedores. Asegurarse de que el proceso de gestión de relación con proveedores está en marcha para cada uno de los proveedores de nuestro catálogo.

DS2.3 Gestión del Riesgo de proveedores. Identificar y mitigar los riesgos relativos a la capacidad del proveedor para continuar prestando los servicios de una forma segura y eficiente.

DS2.4 Monitorización del rendimiento de proveedores. Establecer un proceso que monitorice la provisión del servicio para asegurar que el proveedor está cumpliendo con los requisitos de negocio actuales y continúa cumpliendo los acuerdos contratados y los SLAs establecidos, así como para asegurar que el proveedor sigue siendo competitivo en el mercado

Por último, el modelo de madurez va (como siempre en CobiT) desde el 0-Inexistente hasta el 5-Optimizado, donde y a modo de ejemplo vemos que el nivel 1-Inicial indica

La dirección es consciente de la necesidad de establecer políticas y procedimientos de contratación. La medición de los servicios es informal y reactiva. Las prácticas dependen de la experiencia de los individuos o del tercero

y el nivel 4-Gestionado indica

Existen criterios formales y estandarizados para la relación con terceros, incluyendo planificación, costes, facturación, responsabilidades. Las cualificaciones y riesgos de los proveedores se analizan periódicamente. Los requerimientos de servicio están alineados con los del negocio y existe un proceso que permite analizar el rendimiento del proveedor. Se tienen en cuenta los costes de transferencia y se han acordado KPIs y KGIs

Asi, vemos claramente que CobiT nos ayuda, no sólo a ser conscientes de que es importante mantener una capa de control que nos permita asegurar que cuando se cede un trozo de los servicios TIC a un tercero, éste se va a comportar como hemos acordado, sino que tambien nos ayuda a establecer estos controles.

Por último, recordar que CobiT es un marco de mínimos donde vemos los controles mínimos que debemos establecer.

Nuevo estándar ISO para el Gobierno de las TIC

Hace un poco más de un año, en Noviembre del 2007, Jan van Bon pasó por Barcelona y dio una conferencia en un evento del capítulo Catalunya del itSMF España. Durante esa conferencia dejó caer que se estaba cocinando un nuevo estandard para el Gobierno de las TIC a partir de un estándard australiano que no debíamos dejar de revisar porque estaba en modo Fast-Track para convertirse en una norma ISO.

Como el tema me llamó la atención, hice un poco de búsqueda de información hasta que pude echarle un ojo a la norma australiana: la AS8015-2005 y publiqué en este blog un post en el que explicaba los contenidos de esta norma.

Bueno, ha pasado un año y medio y el nuevo estándar verá la luz el próximo 22 de Mayo en Holanda (cómo no!) donde bITa Center ha organizado un evento de presentación donde se explicarán los contenidos de la nueva norma ISO/IEC 38500 - Corporate Governance of Information Technology.

Aún no he podido leer la nueva norma, pero Mark Toomey (uno de los promotores de la norma) ha explicado en algunos foros las bases principales de la norma:

1. Es una versión corregida y aumentada de la norma australiana AS8015-2005
2. Define seis principios para "el buen gobierno del uso de las TIC": Responsabilidad, Estrategia, Adquisición, Rendimiento, Cumplimiento y Comportamiento Humano (los mismos 6 principios presentes en la AS8015)
3. Establece las tareas que se deben implementar en el Sistema de Gobierno (ojo!): Evaluar, Dirigir y Monitorizar el uso actual y futuro de las TIC para el cumplimiento de los objetivos de la organización.

Uno de los comentarios más interesantes es al respecto de la aproximación "de fuera a adentro" que hace esta visión del Gobierno: estamos hablando "del uso que se hace de las TIC" y no "de la provision que hacemos desde las TIC hacia 'el negocio'".

IT is a tool of business. It is the job of business to determine how, when, where and why it will use the tool – and it is the job of IT to then deliver the tool that fulfils the need. In too many organisations, the business abdicates its role to IT - and wonders why IT does not get it exactly right. In some organisaitons, having abdicated its own job to IT and been dissatisfied, the business then either abdicates its role further – outsourcing supply and trying to outsource its own responsibilities as well – or trying to take on the delivery (supply) role of IT.

The new ISO standard is actually an umbrella that spans both demand (what the business is responsible for) and supply (what the IT department is responsible for). This should help organisations be more clear about what is happening when they do an ITIL of other supply side initiative, and it should help with clarifying what’s not covered by such projects.

 

Por último, otra de las perlas de Mr. Mark es al respecto del concepto de Sistema de Gobierno, algo que sonar, me suena feo... pero que con la explicación de Mark suena mucho, pero que muchísimo mejor:

But “system” is also a fundamental concept. When we think of a system, we think of a set of processes, performed by people with appropriate skills and training, operating within some sort of an organisaiton or control (or authority) structure, and with supporting tools and technology. A Governance System comprises all of these elements, and to get the right system means that work must be done to design and implement that system. Corporate Governance of IT does not merely “happen” – it must be planned and implemented. And once implemented, it must be improved on an ongoing basis to ensure that it continues to be effective, efficient and acceptable.

De birras con el sector duro

I amar prestar aen
Han mathon ne nen
Han mathon ne chae
A han noston ned wilith
[...]

El mundo está cambiando
Lo siento en el agua
Lo siento en la tierra
Lo huelo en el aire
Mucho de lo que era, se ha perdido...
pero nadie vive que lo recuerde

Interpretación libre del Señor de los Anillos

Los días 21 y 22 de Abril se hizo historia. Tuve el increíble privilegio de que Jan van Bon me invitara a la conferencia organizada por itSMF-NL (si no la cuna, el sitio donde ITIL creció) y por bITa Center en un pequeño pueblo de Holanda llamado Ede.

Cuando vi el cartel de la conferencia, no le presté demasiado interés al título; ya se sabe, que eso es cosa de "los de marketing" y poco importa... pero esta vez iba en serio: Beyond ITIL. Beyond Control. Tenía que significar algo así como "Más allá de ITIL. Más allá del Control" y yo le di el significado de..."Hasta el infinito y más allá", pero no tardaría en darme cuenta de cuán equivocado estaba.

Cuando comencé a ver a los ponentes, vi (en realidad ya lo sabía, pero lo pude confirmar en ese momento) a Rob England entre ellos: mi apreciado IT Skeptic iba a estar en Holanda!

Pero cuando llegué allí, me encontré con que no sólo compartiría mesa con Jan y Rob... además había personajes de la talla de Ian Clayton, Paul Wilkinson o Brian Johnson (no! el cantante de AC/DC, no.. ese no!) y la preconferencia fue una fantástica tarde/noche que acabó más allá de las 12 de la noche entre cervezas, charla y crítica... mucha crítica.

Al día siguiente, una apretada agenda de conferencias (lástima, casi todas en Holandés y sin traducción, pero con un track en inglés que fue más que suficiente) en el que se fue perfilando claramente que el sentido de "Más allá de ITIL" en realidad era algo así como "Ya está bien de ITIL" y lo de "Más allá del control" en realidad era "Y nos vamos a librar del control".

Señores, el pensamiento crítico que ha hecho visible Rob England en su blog y que en realidad viene como una corriente subterránea acercándose desde hace dos décadas, ha confluido en Ede esta semana, ha marcado historia y la comunidad más avanzada del mundo en temas de Service Management ha dicho claramente que hacen falta alternativas, mejoras y nuevos puntos de vista.

El mundo está cambiando (I amar prestar aen), pronto veremos alternativas más prácticas, abiertas, colaborativas y sobre todo, no ligadas a un copyright, trademark o propiedad exclusiva.

Porque mucho de lo que era, se ha perdido...pero nadie vive que lo recuerde, aunque en el caso de ITIL autores como Brian Johnson que participaron en los primeros libros de ITIL V1 sí que recuerdan cuál era el espíritu original: la comunidad de usuarios, el cliente, la Gestión del Servicio, el cliente, la profesión y el cliente.

Aquí huele a futuro...

Charlie Betz ha sido elemento de inspiración de más de un artículo en este blog. Escribe un blog llamado erp4it desde hace años (2003), antes incluso de que yo conociera el propio concepto de blog, siempre suele dar en el clavo y es el autor del libro Architecture and Patterns for IT Service Management, Resource Planning, and Governance: Making Shoes for the Cobbler's Children

Recientemente ha escrito un artículo llamado BISM - you (probably) heard it here first. en el que habla de un concepto que me ha parecido interesantísimo: El BISM o Business Information Services Management. La idea es que el concepto de IT Services se va quedando lentamente obsoleto y comienza a aparecer el concepto de Business Information Services, lo que me parece de lo más correcto si pensamos en que lo que realmente consume el negocio de las TIC es la información y, además, esto alinea con el concepto de "Requerimientos de la Información" que ya planteaba COBIT desde los inicios.

Por si fuera poco, profesionalmente he podido ver cómo el contacto entre el mundo ITSM y el mundo BI cada año es más frecuente y más estrecho, lo que me lleva a pensar que este nuevo concepto no está del todo desencaminado.

Aqui huele a futuro, y yo no he sido... ha sido Charlie!

AS 8015-2005: Corporate Governance of ICT

En la presentación que hizo Jan Van Bon durante el evento del itSMF el pasado Noviembre, hizo mucho hincapié en que tuviesemos un ojo puesto en este estándard, ya que está en fast-track para convertirse en ISO y puede significar una ISO sobre Gobierno (corporativo) de las TIC en un plazo relativamente breve.

Lo primero fue encontrar algo de información sobre este estándar de las antípodas, así que me armé de Google y encontré los siguientes enlaces interesantes:

http://www.ramin.com.au/itgovernance/as8015.html

http://www.usq.edu.au/resources/as8015corporategovernanceofict.pdf

http://goanna.cs.rmit.edu.au/~keithf/Managing%20the%20risks%20of%20ICT%20Governance.pdf

Después de leer un rato, aquí van mis impresiones al respecto:

VOCABULARIO

Lo primero que me llamó la atención fue el apartado de definiciones, en las que aparece una definición de Gobierno de las TIC interesante:

El sistema mediante el cual se dirige y controla el uso actual y futuro de las TIC. Incluye la evaluación y la dirección de planes para el uso de las TIC en el soporte a la organización y la monitorización de este uso para el cumplimiento de los planes, así como la definición de estrategias y políticas relativas al uso de las TIC en la organización

Me gusta especialmente la primera frase como definición de IT Governance, más que la enrevesada y difícilmente comprensible definición que da COBIT.

PRINCIPIOS

Este estándard incluye la definición de "los 6 principios del buen gobierno de las TIC":

1. Establecer responsabilidades en el ámbito de las TIC y que éstas sean claramente entendidas y asumidas.
2. Planificar las TIC de forma que soporten de la mejor manera posible las necesidades de la organización.
3. Adquirir las TIC de una forma válida.
4. Asegurar un correcto rendimiento, según requerimientos de la organización.
5. Asegurar el cumplimiento.
6. Asegurar que las TIC respetan los factores humanos.

MODELO

Establece un modelo para el Gobierno orientado a tres tareas principales:

1. Evaluar el uso de las TIC
2. Dirigir la preparación e implementación de planes y políticas
3. Monitorizar el cumplimiento de la dirección.

¿Se acuerdan del modelo de Governance propuesto por COBIT? Básicamente plantea las actividades de establecer objetivos, comparar resultados, proporcionar dirección y medir rendimiento... un modelo similar, pero más ampliado que el que propone el estándard australiano.

MATRIZ DE ACTIVIDADES

Por último nos plantean una matriz de actividades donde se cruzan los 6 principios con las 3 actividades, de tal forma que dan una pincelada de tareas a realizar para, por ejemplo, evaluar el establecimiento de responsabilidades, dirigir el establecimiento de responsabilidades y monitorizar el establecimiento de responsabilidades.

CONCLUSIONES

Personalmente, como estándard me ha parecido un poco flojo, y creo que tendrá que llenarse mucho de contenido para realmente aportar más que COBIT. De todas formas, hace un enfoque interesante (una vez más, la sutileza en el uso de las palabras):

En todo el texto, en las definiciones usadas, en la definición de ámbito, en los principios, se utiliza el concepto de uso de las TIC, así como la coletilla en el título que dice Corporate Governance: estamos hablando de un estándard que piensa más en cómo las organizaciones usan las TIC que en cómo los departamentos de IT las gobiernan o gestionan.

Esta es la variación importante, lo que hace este estándard diferente y el motivo por el que Jan Van Bon nos recomendaba el tenerlo en el punto de mira, y para muestra un pequeño extracto del capítulo de ámbito del estándard:

Este estándard proporciona guías y principios para los Directores de las organizaciones [...] para el uso efectivo, eficiente y aceptable de las TIC en su organización.

Aquí está la clave.

Medir procesos no es tan simple

Como ya comentaba en un post anterior, en el mundo de las métricas hay dos grandes conjuntos: las métricas de proceso y las métricas de servicio.

Básicamente, las métricas de proceso están orientadas a medir rendimiento y cumplimiento de objetivos en la ejecución del proceso, mientras que las métricas de servicio están orientadas a medir calidad, capacidad y disponibilidad de los servicios TIC .

Ahora bien, cuando llega el momento de medir nos encontramos con una curiosa situación: a priori, parece más sencillo y viable obtener métricas sobre los procesos que sobre los servicios; pero la experiencia nos acaba demostrando que no es así. ¿Por qué?

Pues yo tengo una teoría que trata de explicar esto: aplicando (de aquella manera) el principio de indeterminación, lo que queremos medir debe ser estable al menos durante el instante que necesitamos para realizar la medicion y para que estas medidas sean comparables entre sí deben ser relativas a algo básicamente similar.. vamos, lo que nos explicaban de pequeños: "no podemos comparar peras con manzanas"

Los chicos de la Carnegie Mellon lo tienen claro, y en CMMI han apostado por un modelo de madurez en 5 etapas que también ha sido adoptado por COBIT:

0. El proceso es inexistente
1. El proceso está en un estado inicial
2. El proceso es repetible pero intuitivo
3. El proceso está definido
4. El proceso está Gestionado y Medido
5. El proceso está Optimizado

Así, para poder tener unas métricas decentes de un proceso necesitamos que el proceso esté ubicado en nivel 4 de madurez y eso no es tan fácil como conseguir que la tecnología esté en un estado "Gestionado y Medido". Lo primero es un problema de cultura de empresa y lo segundo es simplemente un problema de dinero.

Vamos a verlo con un ejemplo que creo que será bastante claro: es bastante común que tengamos un proceso de Gestión de Incidencias, donde registramos incidencias, las clasificamos, las tratamos, comunicamos al cliente y las cerramos.

A la que tenemos una herramienta donde poder registrar las incidencias y les hemos explicado a los chicos de soporte cómo se debe trabajar, es posible que tengamos un proceso en un nivel más o menos similar al Nivel de Madurez 3 - Definido

Tenemos un proceso DS8 en un nivel de madurez Definido cuando se ha reconocido y aceptado la necesidad de una función de ServiceDesk y de un proceso de Gestión de Incidencias. Los procedimientos se han documentado y se ha impartido formación (aunque sea informal) al respecto. Se desarrollan FAQs y guías de usuario, pero los individuos deben buscarlas y posiblemente no las sigan, Las peticiones e incidencias se siguen de forma manual y son monitorizadas de forma individual, pero no existe un sistema formal de reporting. La respuesta "a tiempo" a las incidencias y peticiones no se monitoriza y algunas de estas llamadas de servicio pueden quedar sin resolver. Los usuarios han recibido información clara al respecto de dónde y cómo reportar estas llamadas de servicio.

Ahora veamos qué pasa con nuestro ServiceDesk: los usuarios contactan con la extensión 3030 y un equipo de operadoras registra sus llamadas, hay un equipo de técnicos que resuelven las llamadas, escriben FAQs y guías de usuario, resuelven las incidencias y lo documentan todo en la herramienta XXX... el departamento de IT se ha gastado una pasta y el Director quiere mostrar los fantásticos resultados en unos preciosos informes que deben subir a Dirección General (que se pregunta en qué se ha gastado la pasta el CIO), así que pide tener un informe muy chulo que muestre, entre otros valores, los siguientes:

• Número de Incidencias registradas
• Número de Incidencias resueltas
• Tiempo medio de primer contacto (T0)

Parece fácil, no? A primera vista parece realmente fácil, pero vamos a ver qué pasa cuando intentamos analizar los números:

Para empezar, tenemos que poder diferenciar las incidencias de cualquier otro tipo de llamada de servicio... ¿Lo hemos tenido en cuenta en la implantación de la herramienta? ¿Podemos diferenciar una incidencia de, digamos, una petición o una consulta?

Luego viene la segunda parte: cuando Rosa registra una llamada, la clasifica como incidencia y la pasa al pool de primer nivel. Manolo, de primer nivel, ve que lo que el usuario está pidiendo no es una incidencia, sino una consulta (bajo su criterio, lógicamente). Pero como no le parece importante para la resolución, no modifica el registro, sino que hace lo posible por cerrar la incidencia y termina.

Con el ejemplo anterior, y si no hemos dejado muy, pero que muy claro en qué se diferencia una incidencia de una consulta, los operadores y/o técnicos nos clasificarán las llamadas de servicio como buenamente les parezca y así... ¿qué validez tendrá nuestra métrica?

En definitiva, lo que ocurre con las métricas es que dependen directamente de la calidad del hecho analizado, y normalmente lo que nos encontramos es que los datos analizados suelen tener bien poca calidad.

¿Y porqué tan poca calidad?

Pues simplemente porque las personas que manipulan esos datos no son conscientes de su importancia, de la importancia de obtener un dato bien "modelado" y (como decíamos en un post anterior) de las consecuencias que se sufren si los datos no son de buena calidad.

Así que como conclusión deberíamos ver una serie de condiciones que se deben cumplir para que nuestro sistema de medición y reporting de KPI's , KGI's y demás números informativos sea realmente útil:

1. El equipo que trata los datos "unitarios" debe ser consciente de la importancia de los datos introducidos.
2. Los datos introducidos deben ser periodicamente auditados para validar su coherencia
3. Los criterios de clasificación deben ser claros y no dar pie a ambigüedades
4. Las métricas definidas deben contar con un manual de interpretación: quien tome decisiones utilizando las métricas como fuente de información debe conocer el significado exacto de la métrica.

Y conseguir todo esto es precisamente lo que hace que medir procesos no sea tan fácil: aparece el factor humano y eso lo complica todo.

¡Felices y Mesuradas Fiestas!