Búsqueda


5 de abril de 2011

Conceptos LEAN : YOKOTEN

dragonball2La 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.

22 de marzo de 2011

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.

Livetime Service Manager for iPhoneEsto 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?

30 de enero de 2011

El ITGI presenta el informe GEIT

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.

informeITGI

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

25 de enero de 2011

Free… de libre, como en librepensador y no de gratis

Los que me conocen saben que siempre he estado a favor de compartir lo que se y de que aquellos conceptos que podríamos llamar “ciencia base” sean de uso público. Es más, soy de la opinión de que el saber debería ser público, popular, comunitario… lo que no quiere decir que los autores tengan que morirse de hambre, porque si no estaría claro que nadie querría ser autor.

Pero en mi humilde opinión, los resultados de un trabajo realizado por el Gobierno con dinero de sus contribuyentes es totalmente lícito, digno, ético y loable que se revierta de nuevo en la sociedad. En nuestro país tenemos toneladas de ejemplos como pueden ser las guías del CTTI (de seguridad, de administración de entornos locales, de elección de herramientas, de gestión de proyectos…), la metodología Métrica 3 y el proyecto Aporta

free_itilEs por eso por lo que pienso que instar al Gobierno Británico para que libere el uso de ITIL® es una idea razonable, porque he contribuido en lo que he podido tanto para difundirla como para construirla y para asegurar un mínimo decente de calidad de forma desinteresada y mucho en mi tiempo libre.

Es por eso por lo que me adhiero a la causa del Free ITIL® Movement“Free as in free speech, not as in free beer”

Por favor, señores del Gobierno de Su Majestad, liberen ITIL®

PS: Si apoyas esta idea, envíale tu opinión al Gobierno Británico

22 de enero de 2011

Mi ruta personal hacia la CMDB

Han pasado ya muchos años desde la primera vez que me tocó participar en un proyecto de definición de CMDB en algún cliente. Desde entonces he tropezado con los errores más comunes, los he cometido, he aprendido, he rectificado y más o menos he ido saliendo airoso de cada uno de ellos; pero con cada tropiezo he añadido una piedra más a la mochila de la experiencia así que nunca dos proyectos son iguales.

imageAl principio, el foco estaba en el descubrimiento y en “rellenar” la CMDB . Aquí entraron las herramientas de descubrimiento automático (en nada parecidas a las que hay hoy en día!) y aprendimos que no todo lo que hay en la CMDB se puede inventariar de forma automatizada; pero los proyectos de CMDB (y ojo, que digo “proyecto de CMDB y no proyecto de Gestión de Configuraciones ni nada parecido) nacían como efecto secundario después de que un cliente tuviese una herramienta de descubrimiento (empezaba con algo tan simple como un NNM y terminaba con verdaderos monstruos como HP Radia)

Luego apareció la necesidad de la taxonomía: era necesario poner orden en todos esos EC ’s que inundaban las bases de datos, así que comenzamos a filosofar sobre ámbito, profundidad, metamodelo… hacía falta dejar claro qué entraba y qué no entraba en la CMDB y cuando entraba, qué información tenía que mantener.

Más tarde, a medida que pasaban los años empezó a ser necesario el discutir al respecto del concepto del Ciclo de Vida del EC (mucho antes de ITIL® V3 y su ciclo del vida del servicio!): los ECs son como los seres vivos: nacen, crecen, se multiplican y mueren… ¿cuál debía ser el ciclo de vida adecuado a cada cliente?. image

No pasó casi nada de tiempo para que la combinación de taxonomía y ciclo de vida diese un resultado inmediato: no podemos tener un único ciclo de vida; cada tipo de EC, o cada familia de ellos puede tener un ciclo de vida diferente y se hace necesario definirlos para facilitar los automatismos, la implementación de estos ciclos de vida en las herramientas e incluso para establecer las responsabilidades de los diferentes equipos en los diferentes momentos del ciclo de vida.

El ciclo de vida del EC dentro de la CMDB nos lleva directamente a reflexionar sobre el proceso de Gestión de Configuraciones: quién hace qué, porqué, para qué, cómo y con qué dentro de cada uno de los ciclos de vida de los diferentes elementos, además de cómo controlamos, monitorizamos y gestionamos que eso se cumpla.

Más adelante, cuando ya habían pasado años y años, los clientes comenzaron a ser cada vez más maduros y surgió la gran pregunta, aquella que tenía que haber aparecido el primer día: ¿Vale la pena? y en cada cliente diferente, la respuesta tenía que ser diferente: en unos casos no valía la pena (el esfuerzo requerido no iba a aportar mucho más de lo que ya tenían) mientras que en otros clientes resulta que sí que valía la pena. Todo depende de cuál sea el resultado esperado, las necesidades, la situación actual (no sólo en términos de información, sino en términos de personal, de comunicación, de cohesión de los procesos) y el esfuerzo (y coste) requerido.

Y ya últimamente, lo que estoy encontrando y me lleva a reflexiones cada vez más interesantes con los clientes es qué perfil debe tener el/las personas responsables de mantener todo esto “en solfa”. Estoy plenamente convencido de que a nada que el entorno sea un poco grande (más de 400 usuarios, por ejemplo) esto es un trabajo a jornada completa que debe desempeñar una persona con carácter… con el suficiente carácter como para dejarle claro a cualquiera que “se salte la CMDB a la torera” que eso no se puede hacer así.

Así que ya ves, en mi ruta personal he ido “escalando” en madurez al tiempo que iba aprendiendo un poquito en cada sitio y otro poquito de cada libro que leía y ahora, desde la media distancia puedo ver que el camino se ha de hacer al revés, planteando las siguientes preguntas:

  1. ¿Para qué servirá el trabajo de Gestión de Configuraciones que vamos a realizar?
  2. ¿Vale la pena hacerlo?
  3. ¿Quién será el/la/los/las responsables de la gestión?
  4. ¿Qué información queremos gestionar?
  5. ¿Qué ciclo de vida tiene cada tipo de EC y qué información se gestiona en cada etapa?image
  6. ¿Qué actividades debemos hacer para responder a que (4 y 5) sean coherentes?
  7. ¿Qué herramientas necesito en cada etapa?

Lo mas probable es que no todas preguntas tengan respuesta en un primer momento, pero de lo que estoy seguro es de que aparecerán más tarde o más temprano.

28 de diciembre de 2010

Filtraciones desde la OGC

Tenía una noticia pendiente de dar; la quería guardar hasta el día de Reyes y postearla como regalito especial, pero la verdad es que no me puedo aguantar más y, antes de que me la reviente el señor The IT Skeptic, me adelanto.

itsmComo sabrán, últimamente se está cocinando un movimiento en la red para luchar por que la OGC alivie un poco la presión que está haciendo en materia de protección de la Propiedad Intelectual que rodea las best practices. Hace unos cuantos años se las consideraba como un producto propiedad de la corona pero bajo Public Domain (tal y como podemos leer en este artículo o en este otro ), luego vino el proyecto CAR y el interés de “monetizar”, luego la revuelta pacífica. (aquí y aqui) y finalmente la coordinación de las actividades (aquí).

Bueno, pues tras las últimas decisiones del Gobierno Británico y las conversaciones que ha mantenido el grupo “The ITSM Irregulars” con la OGC, puedo filtrarles hoy como si de un cable del WikiLeaks se tratase, que durante el mes de Enero se anunciará que las best practices pasarán a estar publicadas bajo la licencia Open Government License, que permite

* Copiar, publicar y distribuir la información

* Adaptar la información

* Explotar la información comercialmente, como por ejemplo combinándola con otra información, o incluyéndola en algún producto o aplicación.

De verdad, será una gran noticia y habrá que ver cómo se lleva a cabo y cómo afecta al mercado, pero desde luego es lógico pensar que algo que se ha fabricado con el dinero del contribuyente (británico) y con el esfuerzo de la comunidad (internacional) vuelva a la comunidad… no?