Gobierno de las TIC - Conocimiento Adquirido

10 Preguntas a hacerse en la Gestión de la Capacidad

2012-05-15T12:43:00.001+02:00

USMBOK™ es una fantástica referencia a la hora de gestionar servicios de cualquier tipo. Define un modelo de gestión quizás demasiado amplio, pero hay que tener en cuenta que se trata de un cuerpo de conocimiento, un compendio del conocimiento relacionado con la gestión de servicios y por lo tanto es como una enciclopedia: uno coge lo que necesita en cada momento.

En la sección en la que se habla sobre la gestión de la capacidad, se indica que el objetivo de esta actividad es

asegurar que existen suficientes recursos para cumplir con los objetivos de rendimiento del servicio acordados con los clientes, ahora y en el futuro, a un coste óptimo y acordado

Que existen suficientes recursos, pero ¿de qué tipo?. Esta pregunta,que a priori puede parecer retórica, es importante, porque en realidad la gestión de la capacidad debe incluir también la existencia de recursos humanos adecuados para realizar el trabajo.

La guía propone diez preguntas a hacerse para conseguir una gestión de la capacidad robusta y efectiva:

1.- ¿Cuánta capacidad tenemos para hacer el trabajo?

Plantearnos de qué recursos disponemos y de qué capacidad tienen para satisfacer las necesidades de los consumidores de nuestros servicios puede parecer fácil inicialmente. Rápidamente nos iremos a pensar en FTEs, en horas, etc… pero es importante disponer de otro dato esencial: ¿cuánto trabajo somos capaces de hacer con esos recursos?

2.- ¿Cuánto trabajo del que tenemos es no autorizado o no planificado?

Una de las grandes problemáticas que existen en la gestión de la capacidad es conseguir planificar el consumo de la capacidad disponible. Fijémonos en que parte del objetivo incluye la idea de “coste óptimo”, y eso tiene mucho que ver con eliminar la compra compulsiva o de emergencia.

Y ¿cuál es la fuente principal de trabajo no planificado en un área de informática? Justamente, el tratamiento de incidencias, errores, emergencias… todo aquello que nos hace ir “de bomberos”. En un entorno en el que el tamaño de trabajo no planificado es superior al del trabajo planificado, poca gestión de la capacidad podremos hacer, lo que nos lleva a que los costes crecen inevitablemente.

3.- ¿Quién es responsable del uso de la capacidad?

Esta es una de esas preguntas típicas que te hacen los responsables de explotación: necesito saber quién se está comiendo mis recursos. Para eso, es importantísimo ser capaces de clasificar cada consumo por cliente, área, edificio u otras dimensiones de análisis que nos permitan responder a la pregunta.

4.- ¿Cuánta capacidad (usada o no ) está asignada al coste del servicio?

Pregunta difícil de responder donde las haya. La capacidad que no se usa igualmente se paga y por lo tanto de alguna manera se debe repercutir a los servicios con algún criterio (esos famosos costes no absorbibles de los que habla ITIL®). Y la que se usa, se debe repercutir sobre los servicios, habitualmente con un criterio de reparto por uso (por lo que se debe poder medir).

5.- ¿Cuáles son las consecuencias de no disponer de la capacidad adecuada?

Responder a esta pregunta será de gran utilidad para realizar un análisis de coste/beneficio frente a la decisión de si “estocar” capacidad o no, saber cuáles son los riesgos a los que nos enfrentamos en caso de no disponer a tiempo de los recursos adecuados. Le pongo un especial énfasis a la palabra adecuados porque sobre todo cuando hablamos de personas no siempre podremos disponer de aquel técnico que sabe exactamente lo que hay que hacer o de aquel programador que conoce exactamente la tecnología que tenemos que usar, y aquí entra mucho en juego la planificación.

6.- ¿Cuánta capacidad “de sobras” o buffer necesito, cuándo, para qué?

Combinar lo que sabemos sobre el trabajo planificado y nuestras experiencias de trabajo no planificado, junto con los calendarios de servicios y plan de cambios nos permitirá anticiparnos y ser capaces de mantener un “buffer” de capacidad que nos permita absorber picos de trabajo (a combinar con la pregunta numero 5 por si acaso!)

7.- ¿Podemos crear capacidad adicional sin inversiones adicionales en capacidad?

Cuando miras los diagramas de ITIL® sobre la gestión de capacidad aparece una caja con una actividad de “tunning”. Básicamente se trata de ajustar el uso de los recursos actuales para conseguir algo de capacidad extra sin necesidad de comprar más recursos. En el mundo de los recursos humanos se trata de balanceo de cargas de trabajo, uso racional del tiempo de las personas, eficiencia, reducción de derroches, etc.

8.- ¿Disponemos de mediciones de la capacidad, y cuán frecuentemente se mantienen y reportan?

Todas las preguntas anteriores no se pueden responder sin mecanismos decentes de medición. Disponemos de sistemas de medición? Se mide, realmente? Se hace un estudio/análisis de los resultados?

9.- ¿Cuánta capacidad no utilizada existe?

Esta pregunta es prácticamente un desarrollo sobre la primera. La idea es saber de toda la capacidad disponible, cuánta se está utilizando (en qué, para qué, para quién, a qué costes) y cuánta me queda libre.

10.- ¿Necesitaremos la misma capacidad para cuando estemos en modo “continuidad”?

Debemos plantearnos, formalizar e incluir dentro de los planes de continuidad si los objetivos de nivel de servicio pactados con las comunidades cliente serán los mismos o no. De aquí se deriva la información necesaria para saber si en el momento de activar el plan de continuidad tendremos que proporcionar los mismos niveles de capacidad (seguramente habrá muchas actividades que dejen de hacerse y probablemente los niveles de capacidad necesarios serán menores).

Puedes encontrar más información como esta en las publicaciones USMBOK y USMBOK Practitioner Series

Mismo servicio, distintas perspectivas

2012-05-09T16:15:00.001+02:00

Hace unos días se comenzó una discusión en el foro de LeanSpain titulada “Muda en la Sanidad, 1-2-3 responda otra vez” en la que diversos participantes han hecho un breve resumen de la percepción que tienen sobre las ineficiencias en los hospitales. Uno de los participantes nos refería a una entrada que había escrito en su blog hace ya algún tiempo llamada “Muda en los hospitales”.

La lectura de este hilo junto con el post de José Iglesias me hizo pensar un poco en las diferentes perspectivas con las que vemos un servicio y, sobre todo, en cómo este caso me servía para ejemplificar algo de lo que siempre acabo hablando cuando me toca exponer Lean Service Management™: el consumo Lean.

Normalmente, cuando haces un taller de análisis Lean (un Value Stream Mapping, un estudio de derroches o cualquier otra actividad que sirva para ayudar a una organización a dar sus primeros pasos en la aplicación del Lean Thinking) convocas a un pequeño grupo de personas que vivan la ejecución de las actividades en su día a día (en terminología Lean, aquellos que viven el Gemba) y en la medida de lo posible convocas a los consumidores de eso que estás analizando. En el momento en que el equipo se comienza a plantear los derroches o las situaciones de ineficiencia, pronto comienzan a salir ideas que mejoran “el cómo se hace”.

Pero si nos fijamos bien en la lista de Mudas que se plantean en el hilo o en el post de José, las mudas que estamos explicando son… ¡¡ de consumo !!. Ninguno (creo) de los que estamos en el foro somos médicos, ni trabajamos en un hospital.. las ineficiencias las hemos explicado desde nuestro punto de vista: el de consumidor del servicio… pero si le hubiésemos preguntado a una doctora o a un enfermero, posiblemente nos hubiera dado una lista de mudas totalmente diferente: las mudas de producción, no las de consumo.

Eso es lo importante cuando hablamos de aplicar Lean al mundo de los servicios: en los servicios se produce un acople entre la producción y el consumo; hay un acto de co-producción y por lo tanto una representación clásica de VSM no sirve, puesto que la experiencia del cliente es tanto o más importante que la producción del servicio en sí mismo.

En el mundo de servicios tenemos dos flujos de valor que confluyen y que hay que tratar de forma sincronizada: el flujo de la producción y el flujo del consumo. Si estos flujos no están acoplados, tenemos una situación negativa cuya resolución es fundamental.

Lean Management: la clave para un outsourcing de primera clase

2012-04-24T20:33:00.001+02:00

El 2011 ha sido el año de Lean-IT: han aparecido publicaciones y foros, se ha realizado el I European Lean IT Summit, han surgido de la nada nuevos esquemas de certificación y se han impartido clases y dado conferencias por todo el país.

Esto probablemente ha sido motivado porque se acabaron definitivamente las vacas gordas y ahora nos enfrentamos a una larga temporada de vacas flacas; los directivos buscan maderos a los que agarrarse y poder seguir entregando los niveles de servicio demandados pero, eso sí, dentro de unos niveles de calidad aceptables y, sobre todo, dentro de los márgenes económicos en los que se pueden mover en esta nueva situación.

El Pensamiento Lean se mueve siempre basado en una serie de principios, que podemos resumir en el siguiente gráfico:

Por otra parte, un proveedor de servicios IT en modalidad de outsourcing o prestación de servicios continuados se encuentra en estos momentos con la necesidad acuciante de cumplir con las necesidades del cliente (representado principalmente en el modelo tradicional de entrega de servicios por “cumplir las exigencias del contrato” o “satisfacer los SLA”), posiblemente reducir los importes de estos contratos (hacer más con menos) y por otra parte satisfacer sus propias necesidades de rentabilidad (mantener los márgenes de beneficio).

Así, nos encontramos en una situación en la que por una parte la demanda tira del beneficio hacia abajo y mantiene, si no aumenta, la tensión sobre las exigencias de nivel de servicio; por otra parte, el proveedor se ve en la obligación de mantener el beneficio obtenido por la prestación, por lo que alguno de los puntos del triángulo de los servicios se verá afectado.

Pero esto no debe ser necesariamente así. La primera lectura es que si disponemos de menos financiación, habrá que dar menor rendimiento o peores niveles de servicio, y es aquí donde Lean-IT nos puede ayudar especialmente. Veamos cómo siguiendo los diferentes principios que hemos presentado anteriormente:

IDENTIFICAR EL VALOR: Lean asume que los atributos de un producto o servicio que establecen el valor aportado para el consumidor son variables y que por lo tanto debemos realizar una alineación permanente con estos atributos. Eso repercute directamente en la necesidad permanente de contacto con el cliente/consumidor para identificar en cada momento qué es lo importante, ajustando la producción a esas necesidades. Desde el punto de vista de un proveedor de servicios, esto significa que necesitamos contratos lo suficientemente flexibles como para soportar fácilmente variaciones en las necesidades, en los ámbitos, en los niveles de servicio entregados y, lógicamente, en los niveles de facturación y por lo tanto se debe trabajar en equipo para formalizar estos contratos ágiles con mecanismos de facturación variable. Por otra parte, un proveedor de servicios con espíritu Lean no sólo se centrará en el cumplimiento del contrato; pondrá su interés en el propósito de su cliente… ¿Recuerdas la definición de servicio según ITIL? “Un medio de generar valor al cliente facilitando los resultados que desea obtener…” esto es lo que significa ese interés en el propósito: entender y facilitar los resultados que el cliente desea obtener.

IDENTIFICAR, REPRESENTAR Y OPTIMIZAR EL FLUJO DE VALOR: Como dicen Mike Rother y John Shook en su libro “Learning to See”, siempre que hay un producto para un cliente, hay un flujo de valor. El reto consiste en verlo. Este principio Lean hace aflorar uno de los principales problemas organizativos que existen: la jerarquía es a nivel funcional, a nivel de unidades organizativas mientras que el flujo de valor hacia el cliente/consumidor es transversal y cross-funcional. Cuando se aprende a representar y ver el flujo de valor se puede detectar una multitud de actividades que se realizan que no aportan nada a esos parámetros o atributos de valor que hemos identificado en el punto anterior: es lo que el Pensamiento Lean denomina waste (desperdicio, ineficiencia, derroche) y que nos permitirá optimizar el flujo, dejándolo libre de todas estas actividades que sólo incorporan más tiempo de proceso, más volumen de actividad y más ineficiencia global. Aquí es donde entra en juego la posibilidad de hacer más con menos, hacer más de lo que aporta valor, más de lo que al cliente le sirve para lograr su propósito, con menos consumo de recursos, con menos ineficiencia y con menos actividades que no aportan valor. En el fondo, aquí de lo que estamos hablando es de poder lograr los objetivos marcados utilizando menos recursos con lo que podremos ajustar el presupuesto tal y como nos lo exigen los tiempos que corren, al tiempo que podemos mantener los niveles de servicio esperados.

FACILITAR EL “PULL”: Durante las sesiones de formación en Lean Thinking es habitual realizar simulaciones o juegos de mesa en los que se demuestran algunos de los conceptos explicados durante las clases. Uno de estos juegos consiste primero en simular un sistema basado en PUSH (empujar la producción hacia el mercado, producir en base a previsiones y acertar a que el producto se consuma en el momento esperado) y posteriormente otro sistema basado en PULL (en el que es la demanda y el consumo el disparador de la producción, principio básico para la producción Just in Time). Los resultados son espectaculares en estos juegos, donde llegamos a ver incrementos en el resultado final (no sólo en la productividad, sino en los resultados económicos finales: se produce ajustadamente a lo que se puede vender y por lo tanto no hay sobrecostes de almacenamiento, sobre-stock, materiales, etc..)

Pero nosotros, en IT, no nos movemos en una cadena de montaje. Lo nuestro no es una producción en serie con poca variabilidad en el producto entregado y por lo tanto las herramientas Lean no se pueden aplicar directamente sin modificaciones; nos movemos en el mundo de los servicios, intangibles, variables y con una característica fundamental que los hace únicos: la coproducción. El usuario sincroniza el acto del consumo con el acto de la producción que se realiza desde el área de IT (no en el 100% de los casos, pero sirve como generalización). Es por eso que en esta situación el PULL o acto de “estirar de la cadena de producción” se convierte en un factor crítico. Debemos facilitar el consumo y debemos conseguir alisar en lo posible la demanda.

En el caso de nuestro hipotético proveedor de lo que podremos llamar “LeanSourcing”, el hecho de estar permanentemente cerca del cliente, co-planificando la demanda y pensando con él en maneras de conseguir que haya el mínimo posible de picos, hace que el proveedor pueda organizar mucho mejor los recursos necesarios, entregar los recursos adecuados, planificar sus propias necesidades de contratación y de formación, racionalizar, en definitiva, sus costes.

Un ejemplo interesantísimo de este caso se produce cuando vemos a empresas que tienen externalizado su AM&O (Application Management & Operations ) y que colaboran con su proveedor para planificar la demanda de nuevos desarrollos y evolutivos en ventanas a 3 meses vista. Cuando esta planificación se hace de forma apropiada, el cliente consigue a las personas más adecuadas para cada uno de los trabajos y el proveedor, con un conocimiento previo de la demanda que tendrá del cliente, puede planificar mejor sus equipos e incluso planificar las necesidades de contratación o de formación que tendrá.

BUSQUEDA DE LA PERFECCION: Este principio asume que la perfección es un estado utópico, inalcanzable; no por ello debemos tirar la toalla, sino que debemos iniciar actividades de adaptación continua a las necesidades de ese “blanco móvil” que es el valor desde el punto de vista del consumidor. Bajo este paraguas aparecen las herramientas de mejora continua, tanto del sistema de producción como del producto/servicio producido.

Aquí aparece el trabajo en equipo, el aprovechar la inventiva, imaginación y conocimiento de todo el equipo, hacer participar a los diferentes integrantes del flujo de valor en las propuestas de mejora y un concepto importantísimo en toda iniciativa de gestión Lean: Walk the Gemba, pasear, visitar, conocer cómo se realiza el trabajo de verdad (Gemba es una palabra japonesa que tiene el significado de “lugar donde se encuentra la verdad” y “lugar donde se produce la acción”). Hablando con expresiones más castizas, comprenderemos mejor cuáles son las necesidades de mejora del sistema productivo si somos capaces de ponernos en la piel de cada uno de los que intervienen en el flujo de valor; y podremos comprender las necesidades de mejora del producto/servicio que entregamos si nos ponemos en la piel del consumidor/usuario que utiliza nuestros productos/servicios.

Otro ejemplo especialmente interesante del grado de comprensión que se adquiere cuando se vive el Gemba es el caso de una empresa en la que, después de varias sesiones destinadas a plantear las mejoras necesarias en la gestión de facturas de proveedores, el analista se pasó una mañana validando facturas y conformando albaranes. Mientras lo iba haciendo, iba exclamando “¡Pero este trabajo lo he hecho ya dos veces!”, “¡Aquí me faltaría un campo para registrar esta información!” o “¡Necesito una consulta que agilice este paso!”

Un LeanSourcer no desarrollará su trabajo de manera deslocalizada sin exigirle a su cliente que los equipos de trabajo puedan visitar, ver y vivir de vez en cuando el Gemba del usuario, sentir sus problemáticas y poder así plantear mejoras a los servicios entregados.

En conclusión, cumplir con la exigencia que hacen los clientes hoy en día de hacer más con menos sin perder la calidad es un reto que se puede conseguir traduciendo la consigna en “hacer lo necesario, bien a la primera, y con el menor consumo de recursos posible”, que es justamente el leitmotiv de la gestión Lean, aunque para ello es preciso que ambos componentes de la ecuación, cliente y proveedor, trabajen en equipo para conseguirlo. Se construye de esta forma un sistema productivo en el que todos ganan y, en esta relación win-win se consolidan relaciones de larga duración en las que el cliente y el proveedor se convierten en partners.

NOTA: Este artículo se publicó por primera vez en la revista Service Talk de Abril 2012 (Año VII – Edición I), publicada por el itSMF de España.

¿Un cliente satisfecho?

2012-03-25T03:11:00.001+02:00

Imagina que vas a un hotel. Llegas y la atención en recepción es impecable, te atienden rápido, te informan de los servicios y te dan tu habitación justo como tú la querías: cama doble, vistas a la ciudad, silenciosa… Entras en la habitación y está todo como debe y justo cuando te sientas en la cama, ¡Una pata de la cama se parte y la cama cae al suelo!

Llamas a recepción, en un par de minutos llega el chico de mantenimiento y en poco tiempo te han sustituido la cama (para no hacerte cambiar de habitación; ya habías desmontado la maleta). Se disculpan efusivamente por el inconveniente y te invitan a cenar al restaurant del hotel para compensarte por el mal rato. Al poco rato, alguien te llama para preguntarte si el problemilla se ha solucionado y saber si te han atendido correctamente. Les das 5 sobre 5 puntos en la encuesta de satisfacción.

A la mañana siguiente, cuando te vas a ir, te quedas con el tirador de la puerta en la mano; tienes que bajar a desayunar, así que vuelves a llamar a recepción pidiendo ayuda. Casi antes de colgar se presenta otro chico de mantenimiento que repara la situación en menos de un minuto, se disculpa y te da un cupón de descuento del 50% para la próxima visita que hagas a la ciudad.

Cuando estás haciendo el check-out, el recepcionista te pregunta amablemente si el incidente de la puerta se resolvió adecuadamente y tú lo vuelves a puntuar con 5 sobre 5, ya que se resolvió rápido, te trataron bien y te compensaron por la espera.

Según sales por la puerta, coges el cupón de descuento, lo rompes en 8 pedazos y lo tiras a la papelera mientras piensas “no vuelvo a pisar este antro nunca más”.

Pero ojo! las encuestas te dan por cliente muy satisfecho, ya que has puntuado dos veces con 5 sobre 5, siempre que has tenido un problema te han atendido excepcionalmente bien y todo ha sido muy rápido; ¡Que viva el SLA!

¿Te suena este tipo de situaciones? ¿Lo has vivido, o quizás lo estás potenciando e tu organización?

Lo lamentable es que esta forma de medir la satisfacción del cliente es una Best-Practice en el mundo del ServiceDesk, y deberíamos pararla inmediatamente. Deberíamos dejar de preguntar si la atención (puntual, por incidente) ha sido buena y comenzar a preguntar por el servicio.

¿Cómo haremos las encuestas el día que seamos tan pero que tan buenos, que no tengamos incidencias? ¿A quién le preguntaremos?

Como mínimo, como dice Charlie Betz ( twitter @CharlesTBetz), deberíamos tener una alerta al respecto, algo como un “Repeat Caller Incident” que nos permita saber que un cliente está sufriendo repetidas incidencias, aunque sean de diferente tipo, durante su encuentro con el servicio y de esa forma hacer lo posible por retenerlo (y medir la aparición de este tipo de situaciones para poder gestionar esta situación de manera global)

El servicio no es el soporte.. el soporte es una característica que ponemos cuando el servicio no es perfecto; debemos poner foco en medir (evaluar, analizar, reportar y mejorar) la calidad del servicio.

Esta entrada es una traducción adaptada y reflexionada de un comentario de Aale Roos (twitter @Aalem) en el grupo de Facebook Back2ITSM.

Conectando el taller con la fábrica

2012-03-22T00:35:00.001+01:00

Este fin de semana salí con la familia a comer al campo, junto con otras cuatro familias del colegio de las niñas; dimos un fantástico paseo por el campo, hicimos un poco de Geocaching y al final fuimos a comer un poquito de carne a la brasa… un día agradable y entretenido en que la familia se lo pasó de perlas y yo desconecté un mucho de la tensión del día a día del trabajo.

A la hora de comer dejamos fluir la conversación entre temas de todo tipo: los “padres” hablamos de futbol, de la crisis, del tiempo… Delante de mí en la mesa estaban sentados Fernando (que se dedica a la inyección de plásticos en una fábrica) y Luis (mecánico, con su taller de barrio donde repara todo lo que se le ponga en las manos); en un momento en que estábamos hablando del taller, de repente yo le hice una pregunta a Luis:

--Oye Luis, dime una cosa: los Toyota, ¿qué, son buenos?

Luis comenzó a asentir con la cabeza, pero antes de que le diera tiempo a decir nada, Fernando (que tiene un Toyota) me dijo:

-- Yo soy socio de la OCU y tengo un informe que dice que los Toyota son los coches que menos averías tienen de todos. Por eso me compré uno. Son buenísimos!

-- Y que lo digas! – dijo Luis – son un coche que se estropea muy poco, pero además, es que se nota que están bien hechos. Las piezas que más se rompen, son accesibles y se sustituyen con facilidad. En un Seat o en un Renault te las ves negro para cambiarlas, pero en un Toyota están ahí, fáciles de acceder, con espacio… una gozada!

-- Hmmm… Interesante… – Yo movía la cabeza interesado…

-- Y otra cosa que tienen – siguió Luis – es que están bien diseñados. A veces ves un coche por dentro y piensas “El tipo que diseño esto, no ha arreglado un motor en su vida”. Por ejemplo, los Seat tienen muchísimos problemas eléctricos. ¿Sabes por qué? Porque ponen las piezas donde no deben: hay sensores que están cerca del radiador, o cables que pasan por donde el motor más se calienta… y con el tiempo se estropean. En un Toyota lo ves, y no pasa así: todo está donde debe estar.

-- Ah! - Dije yo – Eso es porque tienen un enlace directo desde el taller hacia el ingeniero para mejorar los diseños continuamente!

Y Luis me terminó de rematar:

Y no sólo eso! Además, cuando se produce una avería los mecánicos se preguntan ¿por que? y no una sino varias veces! Imagínate que me vienes con tu coche con una avería: se ha roto algo y yo te cambio la pieza.. si no me pregunto por qué se ha roto, a los pocos meses vendrás de nuevo a que te arregle la misma avería y encima te cabrearás conmigo porque no te lo he hecho bien.

Hace años hice un curso de Toyota y ahí nos decían que hay que preguntarse por qué pasan las averías y así resolverlas para siempre. Y si es un tema de diseño, podemos decírselo para que arreglen el diseño. Eso no lo tienen las otras marcas!

Imagínate cómo se me quedó el cuerpo.. que Luis, el mecánico de barrio que me arregla el Skoda un día y arregla un Tuareg al otro, dándome clases de Lean! Que gustazo!

Y claro… inmediatamente viene la aplicación en el mundo Lean Service Management: tienes conectado el taller con la fábrica en tu casa? Se enteran los equipos de Arquitectura y de Desarrollo de las causas de las incidencias? Hacen algo con ello?

Si.. ya se… ITIL también habla de Incidencias, Problemas y Cambios, así que podemos usar ese vocabulario también: ¿Tienes Gestión de Problemas en tu casa? Si quieres salir en el informe de la OCU como “Best-In-Class Service Delivery”, ya tardas…

PD: El hecho de tener muy pocas averías, hace que el Toyota tenga un coste de propiedad reducido. Además, hace que el coste de la garantía (para el fabricante) sea menor, y que el coste de mantener una red de talleres gigante y sobredimensionada sea eliminado.

¡Ser bueno es más barato!

Entrevista a un bloguero

2012-02-22T20:54:00.001+01:00

Dentro de la iniciativa que ha tenido el itSMF España de conocer a las personas que hay detrás de los blogs y cuentas de twitter más importantes del sector de las Tecnologías de la Información, se ha iniciado una ronda de entrevistas que se publican en el canal de televisión que esta organización tiene en GlobbTV.

El objetivo de estas entrevistas es mostrar que tras estos blogs hay personas, con sus opiniones, sus ideas y sobre todo con “cara y ojos”, de carne y hueso y por eso nos ayudan a “desvirtualizar” a sus autores con entrevistas en video en un formato ligero, entretenido y sobre todo informal.

He tenido el placer de participar (y el honor de ser de los primeros) en esta actividad del itSMF y después de entrenarme un poquito con el software utilizado para la grabación, pudimos registrar esta entrevista que hoy les dejo aquí. Si quieres conocer un poco más de qué se cocina en este blog, de cómo se preparan las entradas o de cuáles son los temas que más nos llaman la atención, sólo tienes que echarle un ojo a la entrevista.

¡¡Espero tu opinión, tus retweets, tus “me gusta” en facebook!!

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

2012-01-30T12:23:00.001+01:00

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:

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)
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)
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:

Hacer co-responsable al proveedor de desarrollo de las implicaciones de su software en soporte y en sistemas.
Hacer que el proveedor de soporte sea co-responsable de la mejora continua de las aplicaciones y los sistemas.
Hacer que el equipo de sistemas sea co-responsable en la definición de arquitecturas y estándares para apoyar al equipo de desarrollo.
Hacer que todos tengan responsabilidad sobre indicadores globales de servicios extremo a extremo.
Establecer responsabilidad transversal de la entrega de servicios entre las diferentes funciones.
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!!

Felices Fiestas

2011-12-23T10:32:00.001+01:00

No catalog, No cloud

2011-11-16T22:57:00.001+01:00

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

2011-11-15T20:10:00.001+01:00

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:

Peticiones de servicio procesadas automáticamente por el motor de transacciones
Peticiones de servicio derivadas de que una de las de tipo 1 ha fallado (incidencias)
Peticiones de servicio procesadas con intervención humana, pero no del tipo 2
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?

Basic Service Management, por Rob England

2011-09-28T00:19:00.001+02:00

Esta semana he aprovechado un viaje a Madrid para leerme en el AVE el último libro que ha publicado Rob England AKA The IT Skeptic. Se trata de Basic Service Management, una introducción a la Gestión de Servicios en 50 páginas, escrita en un idioma coloquial, simple y sin emplear tecnicismos, en la que se plantean las bases de la Gestión de Servicios (ojo… no de la Gestión de Servicios TI, sino de forma genérica para cualquier tipo de proveedor de servicios). Presenta una imagen global de lo que significa este arte y aporta punteros que señalan a los diferentes cuerpos de conocimiento, marcos de referencia o simplemente artículos y bibliografía que permitirán al lector profundizar en aspectos concretos.

Aparte de su fácil lectura nada indigesta, es de resaltar que la orientación que presenta Rob en este libro es “de cosecha propia”: hay un fuerte componente de USMBOK (Universal Service Management Body of Knowledge)combinado con pizcas de ITIL®, de COBIT™, alguna referencia a Lean, a la Quinta Disciplina, a Kotter, al marketing de servicios, al product management… en definitiva, es un resumen de todo lo que ha leído el autor combinado con todo lo que ha desarrollado él en los últimos años y aderezado con su experiencia personal; si hubiera escrito ese libro yo, lo hubiera titulado como el lema de este blog: Conocimiento Adquirido

La aproximación que propone al lector es fundamentalmente pragmática: escoge lo que te guste de este libro, haz un análisis de si realmente te vale la pena y usa sólo aquello que represente un beneficio en tu organización.

Para terminar de redondear la propuesta, el autor mantiene un portal en http://www.basicsm.com/ donde podemos encontrar orientación adicional, material de descarga, foros, recomendaciones, plantillas y un fantástico paquete de checklists para ayudar en la gestión de los servicios.

Realmente es un libro que vale la pena para todo aquel que:

a)Quiera conocer de qué va esto de la Gestión de Servicios, sin necesidad de ser un especialista.
b) Quiera tener una visión global de la Gestión de Servicios y deba orientar su empresa/organización hacia la provisión de servicios
c) Tenga que explicar aspectos de la Gestión de Servicios en lenguaje simple, llano, de la calle, a no iniciados.

Crónica de una reparación

2011-09-12T22:33:00.001+02:00

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:

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.
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)
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.
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% (!!!!)
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.
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.

Una grata sorpresa

2011-09-08T17:26:00.001+02:00

Hace poco tuve una avería de hardware con mi portátil y, como está en garantía, llamé al servicio técnico donde diagnosticaron y enviaron a un técnico para que sustituyera unas piezas. La misma tarde que vino el técnico me llamó por teléfono la chica que me había atendido en el ServiceDesk para confirmar si el técnico había llevado a cabo la intervención y para saber si podía dar el caso por cerrado. Al decirle que sí, me indicó que me llegaría una encuesta de satisfacción por correo y que si no me importaría rellenarla.

Al día siguiente me llegó la encuesta de satisfacción donde me preguntaban una serie de asuntos relativos al soporte, al técnico, etc… pero la última pregunta fue una muy grata sorpresa: destilaba pensamiento Lean por todas partes.

La aportación de valor al cliente se resumen en el Pensamiento Lean en una serie de principios que, expresados por la voz del cliente, suenan como

Resuelve mi problema completamente
No malgastes mi tiempo
Dame exactamente lo que quiero
Agrega valor allá donde yo quiero
Resuelve mi problema cuando yo quiero

Las preguntas de la encuesta iban enfocadas a saber si se había resuelto mi problema correctamente, en plazos, en el momento que yo había indicado… preguntas habituales para saber si estoy o no satisfecho con el soporte dado. Pero la última pregunta estaba orientada a saber si yo había percibido que habían malgastado MI tiempo… el tiempo del consumidor, algo cada vez más precioso y que pocas compañías se preocupan de cuidar.

¿Evolución o Revolución?

2011-09-06T18:11:00.001+02:00

Uno de los planteamientos que más habitualmente nos encontramos en G2 cuando desarrollamos un Plan Director es la duda que se plantea la organización al respecto del tipo de cambio que se debe impulsar.

¿Qué hacemos? – Nos preguntan – ¿Evolución o Revolución?

Normalmente, las empresas tienen muy en cuenta aquellos grandes (enormes) proyectos de “transformación” en los que realmente se lleva adelante una revolución y se cambian aspectos de la organización considerables. Es el gran cambio, en el que se invierten grandes sumas de dinero y, sobre todo y desde mi humilde punto de vista, el que es más o menos fácil de iniciar/provocar/aprobar/ejecutar simplemente porque es una gran pelota a la que todo el mundo le va a prestar atención, ya sea por involucración, ya sea por implicación o ya sea por compromiso [te acuerdas del desayuno de huevos con jamón y la reacción de la gallina y del cerdo?]

¿Y qué pasa entre revolución y revolución?

Aquí es donde entra en juego la evolución. Evolucionar significa acumular cientos de pequeñas mejoras, ya sean individuales o sean de pequeños grupos, pero pequeños cambios (como decía el Capità Enciam, “los pequeños cambios son poderosos!”).

Pues precisamente de eso, de los cambios pequeños pero constantes, es de lo que va el Kaizen, concepto Lean que va asociado a la forma de organizar la recogida, análisis y puesta en marcha de todas esas pequeñas iniciativas de mejora continua generadas por todos y cada uno de los trabajadores.

En el Kaizen aparecen un par de conceptos que son la clave de esta evolución organizacional:

La fuente de oportunidades de mejora es colectiva: todos los trabajadores participan aportando aquellas ideas que permitan mejorar aunque sea discretamente el trabajo… ¿Conoces esos sitios en los que la gente siempre se está quejando porque hay algún detalle del trabajo que se podría hacer mejor, de otra manera o más cómoda?. En un entorno Kaizen, cada una de estas pequeñas quejas es una oportunidad de mejora, se propone, se estudia y se corrige. En estos sitios, hay un indicador relativo al numero de mejoras x persona x año… en los entornos más comprometidos con la mejora continua nos podemos encontrar con indicadores del calibre de 60 o 70 propuestas de mejora por persona al año… de las cuales se implementan ratios rondando el 90%… ¿Te lo imaginas?
La mejora se implementa: tal y como comentaba en el párrafo anterior… Kaizen no es un buzón de sugerencias, es un sistema de mejora continua. Eso significa que no sólo se señalizan los problemas u oportunidades de mejora, sino que se plantean las soluciones, se discuten y se llevan a cabo. Eso significa que la organización evoluciona pero no sólo en el sentido de la eficiencia, o de la mejora hacia la entrega de valor al cliente/consumidor, sino que también mejora en términos de entorno de trabajo, de ambiente para el trabajador… en una organización Lean, la gente trabaja más a gusto.
La mejora se extiende: como comentaba en un artículo anterior, el acto del “pequeño cambio poderoso” no termina hasta que se ha extendido a todas las áreas susceptibles de utilizar la mejora. Esto significa que un técnico que implementa un pequeño script para mejorar un aspecto concreto de su trabajo, lo comparte, lo comunica hacia el resto de el/los equipos. A esta propagación de las mejoras se le llama Yokoten.

En una empresa madura en el uso de Kaizen podemos estar hablando de estas 70 propuestas de mejora por persona por año, aunque en una empresa que comienza este indicador se puede posicionar perfectamente en 2 propuestas por persona/año. Eso nos demuestra, por una parte el largo camino que hay por recorrer, y por la otra la necesidad de inculcar el concepto de cultura de mejora y los beneficios inimaginables que se pueden obtener: de repente, la mejora no es cosa de unos “pocos innovadores” sino que se convierte en un comportamiento generalizado en la organización, lo que multiplica el número de cerebros pensantes que tienen ideas por aportar. En contrapartida, el entorno de trabajo se convierte en mucho más motivador simplemente porque las mejoras que propongo veo cómo se llevan adelante, cómo aportan a las personas que tengo a mi alrededor y lentamente (evolutivamente) la empresa avanza.

En definitiva, el poder de las cosas pequeñas pero numerosas… siempre queda oculto, pero desde niños nos lo van inculcando; para muestra, un botón

El círculo cero, la eternidad y la reencarnación

2011-08-17T22:51:00.001+02:00

Estaba preparando las maletas para irme (otra vez) de vacaciones, mientras escuchaba Radio 3. De repente, entre canción y canción leyeron un texto que no puedo dejar de copiar aquí… un poquito de reflexión, un poquito de ciencia ficción y un pequeño disparate matemático.

- ¡Ah! -exclamó él-. Pero no lo suficiente. Supongamos que tengo un barril Con un millón de trillones de granos de arena blanca y un solo grano de arena negra. Tú te acercas y sacas un grano, uno por vez, lo examinas y vuelves a tirarlo en el barril. ¿Qué probabilidades tienes de extraer el grano negro?
   - Una contra un millón de trillones, cada vez.
   - ¿Y si sacas la mitad del millón de trillones de granos?
   - Entonces las probabilidades se igualan.
   - ¡Exacto! -exclamó-. En otras palabras, si sigues probando el tiempo suficiente, aun cuando vuelvas a poner el grano en el barril y sacas otro de nuevo, algún día extraerás el negro… ¡si continúas probando el tiempo suficiente!
   - Sí -repuse.
   El profesor esbozó una sonrisa.
   - Supongamos ahora que el experimento lo hicieras con la eternidad.
   - ¿Cómo?
   - ¿No lo comprendes, Jack? En la eternidad la Ley de Probabilidades funciona perfectamente. En la eternidad, más tarde o más temprano, ha de suceder cualquIer posible combinación de cosas y eventos. Deben suceder, si se trata de una combinación posible. Afirmo, por lo tanto, que en la eternidad, ¡cualquier cosa que pueda suceder, sucederá!
   En sus ojos azules brillaba una débil llamita. Yo estaba un poco confundido.
   - Supongo que tiene usted razón- musité.
   - ¿Razón? ¡Por supuesto que tengo razón! La matemática es infalible. ¿Ahora te das cuenta de cuál es la conclusión?
   - Bueno…, que más tarde o más temprano todo sucederá.
   - ¡Bah! Es verdad que existe la eternidad en el futuro; no podemos imaginarnos el fin del tiempo. Pero Flammarion, antes de morir, señaló que también existe una eternidad en el pasado.
   Puesto que en la eternidad todo lo posible debe suceder, ¡cabe deducir que todo debe.ya haber sucedido!
   - ¡Espere un momento! -tartamudeé-. No comprendo…
   - ¡La estupidez! -siseó-. Es como decir con Einstein que no sólo el espacio es curvo, sino que el tiempo también lo es. ¡Es como decir que, después de infinitos eones de milenios, las mismas cosas se repiten indefectiblemente! Así lo establece la Ley de Probabilidades, si se cuenta con el tiempo suficiente. El pasado y el futuro son la misma cosa, porque todo lo que sucederá ya debe haber sucedido. ¿Puedes seguir un razonamiento lógico tan simple como éste?.
   - Bueno…, sí. Pero ¿a dónde nos lleva esto?
   - ¡A nuestro dinero! ¡A nuestro dinero!
   - ¿Qué?
   - Escucha. No me interrumpas. En el pasado deben haber ocurrido todas las posibles combinaciones de átomos y circunstancias. -Hizo una pausa y luego volvió a apuntarme con su dedo huesudo-. Jack Anders, ¡tú eres una posible combinación de átomos y circunstancias! ¡Posible porque en este momento existes!
   - ¿Quiere usted decir… que yo he existido antes?
   - ¡Qué inteligente eres! Sí, has existido antes y volverás a existir otra vez.
El Círculo Cero
Stanley Weinbaum, 1936

Menos mal que el BigBang significó el inicio del tiempo y del espacio, y por eso no hay eternidad pasada, que si no… ¿para qué escribir este blog, si ya está escrito?

¡Nos vemos a la vuelta!

Dónde conseguir ITIL Edición 2011 al mejor precio

2011-08-16T16:24:00.001+02:00

Esta semana he estado buscando dónde comprarme los libros de la nueva edición de ITIL al mejor precio. Inicialmente pensaba que la mayoría de las librerías lo tendrían prácticamente al mismo precio, y sobre todo que ninguna podría superar el precio dado por TSO, pero me equivocaba… así que aquí les dejo algunas de las conclusiones a las que he llegado.

Atención, hay variaciones por el cambio de divisas, por los costes de envío y por descuentos especiales que algunas asociaciones o librerías puedan ofrecer.

Librería	Precio	Observaciones
Amazon UK	£257.21 / 293€	Envío gratuito a España
Van-Haren	400€	Costes de envío, descuento para miembros itSMF
itSMF España	450€ + IVA	Descuento para miembros itSMF España
Amazon USA	381€	Costes de envío
TSO Bookshop	£299 / 340€	(+ unos 35€ de gastos de envío)
APMG	314 €
IT Governance USA	364 €
IT Governance EU	346€

Así, y salvo que haya otras opciones que no haya contemplado, la mejor opción a día de hoy para comprar tu flamante paquete de 6Kg con los libros de la nueva edición de ITIL es Amazon UK., aprovechando que tienen el mejor precio del mercado, la libra está prácticamente al precio del euro y que hay envíos gratuitos a países como España, una oferta difícil de superar.

Reflexiones Lean desde La Calera

2011-07-27T18:25:00.001+02:00

Mis padres viven en La Calera, un pueblito a medio camino entre Santiago y Viña del Mar. Siempre que vengo a visitarlos salgo del trepidante ritmo de la gran ciudad para darme un chapuzón de ternura, tranquilidad y vida lenta. Y digo chapuzón porque es así; entrada rápida y chocante, permanencia corta y salida rápida.

Este año le he explicado a mi madre de ochentaitantos años en qué consiste la Gestión de Servicios Lean (o Lean Service Management ™ ) y le he hecho un resumen de la conferencia que daré el próximo 4 de Agosto en Santiago. Mientras le iba explicando, ella asentía y me interrumpía con preguntas y con explicaciones de cuando era niño o de cuando ella era niña y así me di cuenta de por qué razón me encajan tan bien las formas del Pensamiento Lean. Me encajan porque fui educado de esa manera.

Mi madre no había leído a Womack, ni su madre a Taiichi Ohno, pero da igual… resulta que parte del TPS se inventó en Chile antes de que los japoneses se plantearan inundar el mercado de coches… se inventó cuando mi abuelo se compró un Ford T (curiosa coincidencia, eh?).

Parte de mi educación contenía algunos de los atributos más importantes de Lean:

Romper con el Statu Quo: una de las citas que han aparecido recurrentemente en este blog y que estaban por aquí antes de que yo conociera a Ian Clayton (mi mentor en estos temas) decía

Que algo se haya hecho “toda la vida” de una determinada manera no quiere decir que esta sea la mejor manera.

Ahí tenemos una señal de romper el Statu Quo, de tener un pensamiento abierto, libre de rigideces y de normas que nos permita saltarnos a la torera las cosas como se hacen ahora y tener la libertad de pensar y de plantear nuevas maneras de hacer.

Utilizar el Método Científico: esta se la debo a mi padre, el Doctor Valle, quien siempre, toda su vida, me incitó una y otra vez a tener un pensamiento objetivo, científico y plantear hipótesis y experimentos que nos lleven a demostrar esas hipótesis. ¿Cómo si no podríamos aplicar los planteamientos de soluciones a la Gestión de Problemas?

No poner a los niños en la posición de desobedecer: esta viene de mi abuela Julia… ella daba las ordenes adecuadas, acorde a la edad y capacidad del niño, de manera que el niño pudiera obedecer y conseguía de esta manera la costumbre de obedecer. Mientras le leía el libro de El Principito a mi anciano padre llegué al momento en que el Principito visita el primer asteroide en el que vive un rey juicioso, que le dice

Si yo le pidiera a un general que se convirtiese en ave marina, y el general me desobedeciese porque simplemente no puede cumplir la orden, ¿de quién sería la culpa, del general o mía?

Hacer participar al equipo: Esta salió justamente de la explicación de Lean a mi madre… en un momento en que ella me comentó

-- Pero esto es diferente a las otras cosas que usted hace, como eso de ITIL”

--Pues si –le contesté- es diferente. Es muy diferente llegar con unas normas o con unas instrucciones o formas de trabajo [a la alemana] y decirle a la gente “aquí tienen cómo hay que trabajar a partir de ahora” frente a coger al equipo y decirles “tenemos un problema, tú, que eres el que sabe, que eres el que trabajas cada día con esto, me puedes ayudar a resolverlo? entre todos podemos pensar cómo arreglarlo"?”

En este segundo caso la solución nace del equipo, por el equipo, para el equipo… la seguirán mucho más cómodamente que en el primer caso.

Y con estas reflexiones comprendo que realmente el Pensamiento Lean es algo cultural, es algo que no encajará en todas las organizaciones ni en todas las formas de pensar… ¿Te encaja a ti con la educación que recibiste?

Cruzando la cordillera

2011-07-18T21:02:00.000+02:00

Llevaba mucho tiempo deseando que se diera la posibilidad de combinar una visita a la familia con una oportunidad laboral… siempre deseando encontrar un cliente en Las Palmas o una tentativa en Chile, hasta que al final los astros se han alineado y todo ha quedado encarado.

Hace unos meses tuve la oportunidad de conocer a Judit Laguardia, socia fundadora y directora ejecutiva de ORCI. La conexión fue instantánea, somos dos personas entusiasmadas por la Gestión de Servicios, interesadas en nuevas ideas y, sobre todo, emprendedoras… así que no hubo que hacer demasiadas filigranas para organizar el I Seminario de Gestión Lean de Servicios en Santiago de Chile.

Nos juntaremos el próximo 4 de Agosto en el Hotel Marina Las Condes y hablaremos sobre qué es esto del Pensamiento Lean, sobre cómo se pueden aprovechar estos conceptos para enriquecer nuestra Gestión de Servicios y, principalmente, compartiremos experiencias.

Puedes encontrar la nota de prensa, el cartel y la convocatoria en la página de G2

Se que hay muchos seguidores de este blog en LatinoAmérica, así que si te encaja en la agenda, no dudes en ponerte en contacto con Judit y su equipo para que lo puedan organizar todo. Te esperamos!!

Nota: Lean Service Management™ is a servicemark and trademark of Service Management 101

Un paseo por la historia

2011-06-01T19:55:00.001+02:00

Siempre que doy un curso, ya sea de ITIL®, de ISO/IEC 20000, o de Gestión de Servicios acabo pintando en la pizarra una línea histórica para tratar de poner las cosas en contexto. Al final, me he animado y he montado un timeline con los principales hitos que han sucedido en todo este mundillo.

No tengo muy buena memoria, así que se agradecen todas las puntualizaciones, añadidos y sugerencias que se te ocurran!

Historia ISO/IEC 2000 & ITIL on Dipity.

Ptolomeo VS Copérnico

2011-05-31T21:09:00.001+02:00

En la antigüedad, los primeros científicos miraban al cielo y trataban de darle una explicación razonable a lo que observaban. Una de las primeras cosas que vieron fue que todas las estrellas del firmamento se desplazaban por la cúpula celestial al unísono, manteniendo las distancias y proporciones entre ellas, por lo que usando la imaginación y contando historias sobre ellas pudieron trazar líneas imaginarias y dibujar las constelaciones que han llegado hasta nuestros días.

Pero también observaron que había algunas de estas estrellas que no se comportaban como las demás; éstas, a las que llamaron πλανήτης planētēs (los “herrantes”) se movían por el cielo siguiendo unos patrones concretos, adelantando y retrasando su marcha por el cielo y pasando siempre por las mismas zonas, en una franja alrededor de la esfera celeste que cruzaba 13 ó 14 constelaciones: el Zodiaco

Allá por el año 140 d.c. Claudio Ptolomeo se planteaba cómo justificar científicamente el recorrido de los planetas por el cielo. Aplicando las suposiciones de la época para la cosmología, puso a la Tierra en el centro del universo y todo giraba en torno a ella; de esta manera, para poder modelar el movimiento que realizan los planetas alrededor de la tierra tuvo que utilizar el concepto de epiciclos definir un sistema complejísimo que efectivamente era capaz de predecir la posición de los herrantes en el cielo para las diferentes épocas del año.

Este modelo perduró durante más de 1.000 años, hasta que allá por el año 1543 el polaco Nicolás Copérnico publicó una obra que revolucionaría las bases de la ciencia del momento: de las revoluciones de las esferas celestes, donde tomaba el testigo de las hipótesis de Aristarco de Samo y se resistía a que la realidad fuese tan terriblemente complicada: puso al Sol en el centro del modelo y de repente todo se simplificó terriblemente, dejando un modelo justificado matemáticamente, que era mucho más sencillo y que plantaba la semilla de la Revolución Científica.

Este fin de semana tuve de nuevo contacto con las teorías Geocéntrica y Heliocéntrica durante una visita al CosmoCaixa, y de repente me saltó a la cabeza la idea de que es increíble que la Humanidad se haya pasado más de 1.000 años defendiendo un modelo que, a pesar de lo terriblemente complejo que era, se daba por bueno porque realmente permitía demostrar las observaciones. Todo se basaba en la creencia de que la Tierra era el centro del Universo y que todo giraba en torno a ella, cosa bastante normal ya que aparentemente todo gira en torno al observador.

Hizo falta un salto hacia adelante de una mente que quiso cuestionar el Statu-Quo del conocimiento del momento (y que viéndose en el final de sus días no tuvo miedo de publicar el libro frente a la amenaza de la Inquisición) para que la ciencia pudiese sentar las bases de lo que es hoy en día.

De ahí a extrapolar el concepto (llevado posiblemente por la coincidencia en el uso de los epiciclos para explicar la complejidad del modelo PDCA multinivel) al mundo de la Gestión de Servicios no había mucho: desde los inicios de la Informática hemos pasado por diferentes teorías, la Calculocéntrica, la Infocéntrica, la UsuarioCéntrica, la CPD-Céntrica o la Distributo-Centrica… y en el mundo de la Gestión hemos pasado por la ProyectoCéntrica, la PresupuesCéntrica y llevamos 20 años encallados en la ServiCéntríca tratando de avanzar…

Aparecen algunas voces ingeniosas que hablan del fin de la Gestión de Servicios, por la teoría CloudCéntrica o por la teoría ProcesodeNegocioCéntrica, e incluso a veces se ven nuevos aromas que vienen del mundo de la industria con teorías ClienCéntricas y ValorCéntricas…

Pero desde luego, la teoría ServiCéntrica con #ITIL como principal estandarte parece que se demuestra demasiado compleja como para representar una realidad que, si bien más difícil, la mayoría de veces es más simple. No se si no deberíamos dar un salto adelante, romper los “silos funcionales” no ya dentro de IT sino dentro de la organización y buscar un modelo UsuarioCéntrico en el que nos centremos en el conjunto total de necesidades que tiene un usuario para ejecutar sus actividades y se las resolvamos, completa y sinérgicamente… o quizás en un modelo ConsumidorCéntrico que establezca al consumidor final como centro del universo.. pero en este caso, ¿en qué punto de la cadena de valor paramos?

De todas formas, ¿De verdad los clientes reciben valor en forma de activos estratégicos denominados servicios y cuando los consumen quedan exentos de los riesgos y los costes? O la cosa podría enfocarse de un modo un poco más fácil?

The Fractal Nature of PDCA cycle

2011-05-23T00:29:00.001+02:00

Well, I think this is going to be my first post in English in this blog (I gently ask to my English readers to forgive me this daring :-D ). A few days ago I submitted a simple and innocent tweet that generated a conversation with Ken Gonzalez ,and finally derived to this blog post. Everything started as you can see in the image:

When I explain the PDCA cycle both in ITIL® and (more intensively) in ISO/IEC 20000 training (Foundations Level and in the specially focused class called Process Management and Improvement according to ISO/IEC 20000 ) we start reading the chapter 4 of the standard, called “Planning and Implementing Service Management”. In this chapter, the standard describes a giant PDCA cycle needed to carry on the “project” of implementing the Management System, so we have 4 sub-chapters that describes the detailed requirements of the standard in order to build and run the SMS (Service Management System).

Students see a very nice graphic that explain the different PDCA steps and different inputs and outputs needed for the process. I explain them the requirements using a whiteboard where I draw a circle and move my hands following the line while I explain… the result is quite similar to what you can see in our first animation

As you can see in the animation, the IT organization is like a planet doing a complete set of orbits around the center of the Solar System (Service Management Quality in this example?) but this approach is too simple to try to represent the reality. Demming didn’t invent the PDCA cycle for such a big and complex change like putting in place a Management System for IT Service Management, a “project” that can last at least one complete year (just like a complete cycle around the Solar System!); he invented it for micro-changes, and in fact when you use it or when you imagine how an organization will manage to guide and continuously improve the Management System you can not imagine a BIG PLAN with a BIG DO followed by a GIANT CHECK with a MONSTER ACT

Well… some companies do; they imagine a BIG PLAN and then they sign for the BIG PROJECT and then there appear the Big Hordes of black_suite_with_white_shirt_and_dark_ties called “the consultant team”… they work hard for about 60 days and then the go out of the room with… THE PLAN, a book thicker than a Holy Bible plenty of drawings, RACI matrixes and workflows… but in fact this does not work, and times times of multi-million bucks contracts are finished.

So let’s imagine that we are doing things like people who has a little of common sense and then we will discover that we have a lot of small PDCA cycles that are collaborating together to build that first image of a big PDCA.. different teams, different knowledge areas, different practices but a single project in mind. Then we can imagine this as the second derivative of the first image: now, we are not in the Earth doing an orbit around the Sun, but we are in the Moon (as always! :-D) orbiting around Earth, building small PDCA cycles; you can visualize this situation in our second animation:

But you don’t need to stop in the second derivative… you can imagine a very small PDCA cycle for each small initiative and then one more time a small PDCA for each activity until you reach your level of micro-change. If you draw this infinite (well… it MUST be finite if you want to finish your cycle some day before Doom’s Day!) you will see the Fractal Nature of the PDCA cycle, and once you have seen this light, you will never see the cycle as a simple circle never again.

VI Congreso Academico de itSMF

2011-05-20T14:40:00.001+02:00

Ya se ha abierto el plazo de inscripciones para el VI Congreso Académico de itSMF, a realizar en Madrid los días 1 y 2 de Junio. Les anexo en este post la carta de invitación con enlace al programa y a la hoja de inscripción. No dejes escapar esta oportunidad, que el programa está bien relleno de conocimiento!

Estimados Profesionales,
Mantenerse al día es hoy mucho más importante que en los años pasados.

Este año hemos organizado un Congreso Académico de primer nivel, con más de 40 ponencias con el fin de impulsar la difusión de conocimiento y de las experiencias más importantes. Las ponencias seleccionadas muestran casos prácticos de Gestión del Servicio, aplicabilidad de las normas ISO 20000 e ISO 38500, aspectos clave de Gobierno TIC, etc.

Adicionalmente, el evento se ha potenciado con temas que en los últimos congresos habéis solicitado: Aspectos de Capital Humano TIC (como la gestión de competencias y del talento); casos prácticos de arquitectura empresarial (útil y poco difundida en España); buenas propuestas de cómo gestionar el CLOUD con ITIL; un análisis del mercado y de las referencias de Gobierno y Gestión, etc.

El congreso se realizará el 1 y 2 de Junio, la Universidad Carlos III y en la Universidad de Sevilla. La asistencia es gratuita. Ya está abierto el registro.

Ya os podéis registrar.
Nos vemos el 1 y 2 de Junio 2011 en el VI Congreso Académico de itSMF.
BAJAR PROGRAMA

REGISTRARSE

Conceptos LEAN : YOKOTEN

2011-04-05T20:28:00.001+02:00

La palabra japonesa Yocoten significa “despliegue horizontal”. Está directamente relacionada en el mundo LEAN con el acto de aprender de nuestros éxitos (en contra del tradicional “aprender de nuestros errores”, que también tiene su sentido). El significado que hay detrás de este término es el comprender cuáles son las prácticas que hemos llevado a cabo en el diseño, fabricación o entrega de un producto (bien o servicio) y ser capaces de “replicar” ese éxito.

Este aprendizaje continuo sobre cuáles son las prácticas que nos han funcionado bien no sólo es aplicable internamente en una organización, sino que también las podemos extrapolar al exterior, a otras organizaciones (sean o no de nuestro sector) y eso es lo bonito del tema… el conocimiento transversal, el aprender de los demás y el llevar adelante nuevas iniciativas de cambio y mejora inspiradas en éxitos de otros (contribuyendo de esta manera al crecimiento de la sociedad en su conjunto).

Así, cuando leemos los libros en los que se describe el Sistema de Producción de la Toyota, vemos algunas prácticas que a ellos les han resultado provechosas y las trasladamos a nuestra organización, estamos haciendo Yokoten; cuando entendemos cuáles han sido los factores de éxito de la implantación de un servicio en una rama de la compañía y la trasladamos, comunicamos, enseñamos y aplicamos finalmente en las otras ramas, estamos haciendo Yokoten; cuando una administración pública aprende de otra administración pública o es capaz de replicar ejemplos de éxito en sus diversas sedes, departamentos, consejerías, Ayuntamientos… estamos haciendo Yokoten.

Esto enlaza de perlas con el mundo de la Gestión de Servicios TI, ya que para empezar tenemos toneladas de “marcos de referencia” y de “prácticas recomendadas”; cuando entendemos quénos aporta ITIL® y aplicamos algunas de sus enseñanzas en nuestra organización, estamos practicando Yokoten.

Ahora bien, para eso (sobre todo internamente) es necesario no sólo aprender de nuestros errores, sino aprender de nuestros éxitos y para ello necesitamos comprender qué componentes o factores de un servicio que damos son los que contribuyen de forma importante a que éste sea un buen servicio:¿POR QUÉ NUESTRO SERVICIO ES BUENO?

Ahora, como dicen los “Lean Thinkers”, ves y mira (Go see), porque seguramente la clave de por qué tu servicio es bueno no la encontrarás en tu despacho: la verás en el lugar donde se trabaja, donde se produce el servicio, donde se consume el servicio y sobre todo en las manos de aquellos que usan tu servicio para un propósito superior. Sal fuera, observa, pregunta, muestra respeto y aprende.

Dirigir para o por los indicadores

2011-03-22T01:11:00.001+01:00

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?

El ITGI presenta el informe GEIT

2011-01-30T12:53:00.001+01:00

Este fin de semana el IT Governance Institute (ITGI) ha presentado su cuarto informe global sobre la situación del Gobierno de las TIC. Está basado en una encuesta realizada sobre 854 directivos tanto de unidades de negocio como de IT de 21 países y en 10 sectores diferentes con lo que la amplitud y globalidad del informe están garantizados.

Las conclusiones más importantes que presenta el informe son:

El aspecto al que más importancia se da es el de la creación de valor a través de las inversiones en TI. Los aspectos más problemáticos son el incremento de los costes y la falta de personal.
Hay una correlación entre la ubicación del CIO en la jerarquía corporativa y la proactividad que presenta el área TIC.
La importancia del Gobierno de las TIC: sólo un 5% de los encuestados no lo consideran importante.
Las prácticas de outsourcing siguen siendo predominantes.
El auge del cloud computing: alrededor del 40% de los encuestados se plantea utilizar la nube para servicios de misión crítica.
La contención del gasto se convierte en prioridad.
La utilización del social media tiene poco impacto.

Dado que es la cuarta edición de este informe, una de los aspectos más interesantes es poder ver la evolución desde el año 2004 de las diferentes preguntas realizadas en el informe, como podemos ver en esta gráfica que muestra la penetración de los diferentes estándares y marcos de trabajo.

En conclusión un informe interesantísimo si quieres estar al día de lo que se cuece en términos de IT Governance y si quieres tener material para pensar al respecto de cómo está tu organización en estas cuestiones.

Puedes descargarte gratuitamente el informe de la web de ISACA en este enlace