Búsqueda
23 de diciembre de 2011
16 de noviembre de 2011
No catalog, No cloud
La estrella invitada de esta noche, Rodrigo Flores, ha sido compañero de penurias en este mundo blogeril y de relaciones sociales virtuales. Lo conseguí desvirtualizar el año pasado, durante el congreso ITSMFUSION 10 y me llevé un muy grato recuerdo de las conversaciones mantenidas: es emprendedor, iluminado y visionario… comenzó en el mundo ITSM, vio la oportunidad en el mundo Cloud y consiguió colocarle su empresa a Cisco… ¿Qué mas pedir!? Bueno… por el camino escribió EL libro sobre Catálogos de Servicio: Defining IT Success Through The Service Catalog: A Practical Guide
Hoy ha impartido un webinar sobre la relación entre el Catálogo de Servicios y el mundo cloud, que no se deben perder:
15 de noviembre de 2011
Incidencias, Peticiones, Consultas… Service Requests
Desde que comencé a trabajar en asuntos relacionados con ITSM, allá por el año 96, ya aparecían problemas a la hora de clasificar correctamente los tipos de solicitudes que llegaban a un CAU. Con la entrada de ITIL V2, recuerdo que enseñaba en los cursos de formación la Gestión de Incidencias y luego aclaraba que “aunque la teoría dice esto, en realidad recibimos muchos tipos diferentes de llamadas”, asunto que provocó un artículo en este mismo blog titulado Una Queja no es una Incidencia.
Con la llegada de ITIL V3 apareció de la nada un nuevo proceso llamado “Gestión de Peticiones”, que nos permitía romper aquel flujo único en dos, cosa que desde el principio ya fue aceptada positivamente, ya que separábamos lo que podríamos entender como Demanda Valor de lo que sería Demanda Fallo, pero cuando vas a la vida real te chocas con dos asunto básico: (a) un mismo flujo no sirve para todos los tipos de peticiones y (b) no es tan fácil saber, en el momento en que tienes al usuario al teléfono y apenas un par de minutos para atenderlo y registrar, si lo que el usuario quiere es una incidencia o una petición.
Las diferentes aplicaciones de ITIL en las que he trabajado (nótese lo premeditado de no utilizar la palabra implantación) han lidiado con este problema de diferentes formas, muchas veces en función de lo estandarizado que se tuviese la lista de peticiones o de las capacidades de las herramientas para soportar flujos, ordenes de trabajo, plantillas, etc.
Más tarde comencé mi viaje por el mundo del Pensamiento Lean, en el que fui a parar a la lectura del libro Lean Solutions de Jim Womack y Daniel Jones. En este libro se describe una forma de canalizar las peticiones del consumidor en lo que se denominan pathways de tal forma que se pueda estandarizar, optimizar y priorizar el trabajo en cada uno de estos caminos [cosa que nos resolvería el punto (a)]
Por otra parte, el estudio de una de esas obras poco difundidas pero de gran valor que es el libro Guide to the Universal Service Management Body of Knowledge (USMBOK) me llevó a ver que el planteamiento que se realiza en USMBOK es el de recibir todas las peticiones de consumidor, sean del tipo que sean, en una entidad llamada Service Request, que se clasifica según diferentes tipologías, entre ellas:
- 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
28 de septiembre de 2011
Basic Service Management, por Rob England
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.
12 de septiembre de 2011
Crónica de una reparación
Se ve que estos meses son de fallar las cosas, así que esta vez traigo un ejemplo que, si bien es poco importante, me pareció interesante como caso de estudio de cosas que se pueden mejorar en un servicio de atención al cliente.
Antes que nada, no se vayan a pensar que soy un quejica que protesta por cualquier frivolidad: el caso, insisto, no es algo grave ni especialmente molestoso; sólo sirve para analizar un poco el proceso de atención al cliente.
El asunto es que a finales de Agosto se rompió el teléfono fijo de casa. Lo habían traído los Reyes estas navidades pasadas y estaba en garantía, de modo que allá que partimos al centro comercial donde lo habíamos comprado con la esperanza de que nos lo cambiaran por otro.
Aquí aparece el primer mensaje del caso de estudio: vamos a la tienda a realizar una Petición de Servicio porque un aparato se ha roto… ese es el tipo de Demanda más dañino con el que nos podemos encontrar, porque el Centro de Atención al Cliente tendrá que trabajar para algo que no le aporta valor a la organización y sólo me aporta valor a mi porque se ha roto. Se llama Demanda Fallo (Failure Demand) y es algo a evitar a toda costa.
Pregunta: ¿Cuánto invierte tu organización en Demanda Fallo? ¿Se podría evitar? ¿Estaría mejor invertido ese dinero en otro tipo de actividades? [ ¿Cuánto dedicas a mantenimiento correctivo y a gestión de incidencias? ]
Ya habíamos tenido contacto con el Centro de Atención al Cliente de esta tienda, así que sabíamos que nos tocaría aguantar un buen rato de cola… un buen rato, sí, pero… ¿1,5 horas? Así fue… llegamos, pillamos el número del Turn-O-Matic y esperamos… las niñas aburridas, el calor, el ruido… nos leímos el catálogo de ofertas, dimos un paseo por la tienda, esperamos en la calle, esperamos en el CAC… hasta que nos tocó el turno!
Aquí tenemos otro aspecto interesante relacionado con aquellos principios de Lean: 1,5 horas de espera para contactar con un CAC es algo exagerado. El mostrador del CAC tenía 4 terminales, pero sólo había una muchacha atendiendo. Siempre hay unas colas terribles en este lugar, lo que demuestra que el foco está puesto en la venta (asesores, cajeras, de todo! No falta personal en la zona de ventas!)
Después de la espera, la muchacha que nos atendió tomó nota de mis datos y me dijo que enviarían el teléfono a reparar, me pidió la dirección de email y el número de móvil. Me dijo que contara 30 días y que me avisarían para pasar a buscarlo. Firmé el comprobante (en el que decía que lo había entregado todo con el embalaje original) y me fui con la familia a que nos diera el aire en otro sitio.
30 días sin teléfono! No está mal en los tiempos modernos! Aquí no había SLA ni nada parecido, pero en otras ocasiones (un DVD roto, un TDT sin mando… nada importante) ya nos habían dicho siempre que 30 días.
En casa teníamos plan de contingencias: mi mujer, que es súper ordenada y lo guarda todo, tenía el teléfono antiguo; le fallaba el display pero podíamos llamar, así que podíamos esperar 30 días sin mayores problemas.
No habría pasado nada ni yo hubiera escrito esta entrada si no hubiera sido porque un buen día, una semana después de toda esta historia, me llegó un SMS a mi móvil (sin número de origen) que decía literalmente
LE ROGAMOS TRAIGA LOS ACCESORIOS DEL PRODUCTO DEPOSITADO EN NUESTRAS DEPENDENCIAS.
¿Mande? Yo entregué todos los accesorios! Y tengo un comprobante que así lo dice, pero.. el SMS no tenía número, no me habían enviado un mail así que no podía responder… y yo pensaba ¿Otra hora de espera para nada? y ya me iba calentando yo solito…
Total, que cuando llegué a casa llamé por teléfono al sitio en cuestión, a ver si podía aclarar qué accesorio les faltaba… riiing, riiing y me contesta una de esas máquinas odiosas que te preguntan 7 cosas (por ejemplo, me preguntaba 2 veces en qué idioma quería que me atendiera) para al final llegar a que me pedía un número de expediente y me respondía (a la tercera o cuarta, cuando torpe de mi conseguí atinar con el número que me estaba pidiendo) que tenía que pasar por el Centro del Atención al Cliente.
Luego me fui a la web, donde después de mucho buscar encontré un sitio donde si entrabas un número y los apellidos me dijo… ¡Que el aparato estaba listo para su recogida!
Una lección más: cada interacción con el cliente, ya sea humana o mecanizada se convierte en lo que llamamos un momento de la verdad. El servicio de atención se la juega en cada uno de esos momentos y se puede romper toda una buena imagen de atención con un momento de la verdad mal diseñado [un SMS que no me permite responder] o mal ejecutado [una máquina que no me permite interactuar]
Así… ¿qué querían estos señores, que llevara accesorios o que recogiera mi teléfono? Sea como sea, estaba condenado a ir de nuevo a la fatídica tienda… cogí a la familia, otra vez, y nos fuimos al centro comercial.
Entro en el CAC, me voy directo al Turn-O-Matic, cojo mi número y miro al indicador luminoso… que estaba apagado! Miro a mi alrededor y no veo nada que me indique por qué numero van, así que le pregunto a la chica (la misma de la otra vez) y me dice “No, es que está roto.. tiene que pedir la tanda”…
¡Qué graciosa! ¡La tanda, como en la pescadería! Así que pregunto “Quién es última?” y me responden 2 o 3 a la vez… ¡Ya la hemos liado! Mientras nos ponemos de acuerdo han entrado por lo menos 3 personas más al CAC que han ido a coger su numero y no se han dado cuenta de la movida… madre mía la que se está montando!!
Bueno, ahora que la cosa va por tanda no me puedo mover de allí, así que la espera se hace eterna. Unos 40 minutos más tarde me toca el turno y le digo a la chica que me había llegado un SMS diciendo que tenía que entregar accesorios, pero que los accesorios ya los había entregado todos…
“Ah, si..” – Me dijo – “Eso te lo envían cuando te van a hacer una sustitución del aparato; déjame que mire el expediente… a ver… si, aquí está: no tiene reparación, pero como no hay en stock, te haré un vale por el importe del teléfono” y me hizo una tarjeta por unos 40€ que es lo que costaba el maldito aparato…
Aquí podemos ver otra de las “alegrías” del caso: el momento de la verdad estaba tan mal diseñado que enviaba mensajes falsos al cliente! Precisamente el mensaje que me hizo poner de mal humor. Y por si fuera poco, es error habitual que los empleados conocen y les parece tan normal que nadie lo ha resuelto.
Finalmente, me ahorro de discutir con la señorita al respecto de si cuando yo pagué utilicé dinero de verdad o si les pagué con un vale; así que recojo la tarjeta-vale, me voy a la tienda y me compro un teléfono de la misma marca, mejor, más moderno y más barato.. cosas de la tecnología.
Podemos aplicar las ideas de Lean para analizar este caso, más allá de los comentarios que he ido intercalando:
- 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.
8 de septiembre de 2011
Una grata sorpresa
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.
6 de septiembre de 2011
¿Evolución o Revolución?
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
17 de agosto de 2011
El círculo cero, la eternidad y la reencarnación
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!
16 de agosto de 2011
Dónde conseguir ITIL Edición 2011 al mejor precio
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.
27 de julio de 2011
Reflexiones Lean desde La Calera
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?
18 de julio de 2011
Cruzando la cordillera
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
1 de junio de 2011
Un paseo por la historia
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.
31 de mayo de 2011
Ptolomeo VS Copérnico
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?
23 de mayo de 2011
The Fractal Nature of PDCA cycle
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.
20 de mayo de 2011
VI Congreso Academico de itSMF
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
5 de abril de 2011
Conceptos LEAN : YOKOTEN
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.
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.
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?
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.
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
Es 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.
Al 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?.
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:
- ¿Para qué servirá el trabajo de Gestión de Configuraciones que vamos a realizar?
- ¿Vale la pena hacerlo?
- ¿Quién será el/la/los/las responsables de la gestión?
- ¿Qué información queremos gestionar?
- ¿Qué ciclo de vida tiene cada tipo de EC y qué información se gestiona en cada etapa?
- ¿Qué actividades debemos hacer para responder a que (4 y 5) sean coherentes?
- ¿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.