Búsqueda


28 de diciembre de 2006

Revisitando el orden de implantación

Los resultados de la Primera Encuesta GobTIC se presentaron en un post de finales de Noviembre. Entre las preguntas que se hacían en aquella encuesta había una que parecía muy inocente: "¿Todos los procesos para un servicio o todos los servicios para un proceso?" y el resultado fue que el 56% de los participantes escogió la opción horizontal: implementar un proceso para todos los servicios.

Estos días me he dedicado a leer documentación atrasada que tenía y había varios temas relativos a la todavía por estrenar ISO/IEC 20000 y su norma UNE correspondiente y a medida que iba leyendo me iban surgiendo preguntas y dudas que he ido tratando de resolver poco a poco.

La principal preocupación que me iba entrando es que la norma requiere que para obtener la certificación tengas todos los procesos de la ISO en marcha (y bien) y eso es mucho trabajo. Además, iba yo pensando que eso es, en realidad, imposible: un servicio que nuevo, con un bajo nivel de madurez es posible que no cumpla todos y cada uno de los procesos en el momento de la auditoría, ya que la implantación (o, digamos mejos, la incorporación) del servicio es un proceso largo... ¿podría ser revocado un certificado si se detectan no conformidades graves en un servicio de nueva implantación?

Por otra parte, iba pensando en aquellos entornos en los que se dan casos de externalizacion de diferentes áreas de los servicios y de los procesos a uno o varios proveedores. ¿Cómo se haría la certificación en estos casos?

La respuesta llegó de casualidad, leyendo un post en el foro del itSMF España, donde Ana Ramos daba un enlace a http://www.isoiec20000certification.com y en este website encontraba el documento estrella: las Scoping Guidelines en las que se explica algo que a mi entender es de una importancia capital y sin embargo tiene pocas referencias en la literatura que he consultado: el documento al respecto del ámbito o alcance de la certificación que se debe acordar previamente con la entidad certificadora y que será el que indique precisamente el alcance que tiene el certificado.

En estas guías aparecen los conceptos de proveedor interno, proveedor externo, organización cliente, localización geográfica, etc. y se dan varios ejemplos muy clarificadores al respecto de qué modelos de colaboración son certificables y cuáles no.

Ahora bien, ¿Qué tiene que ver todo esto con el orden de implementación? Pues resulta que la clave (lógicamente desde el punto de vista de la ISO/IEC 20.000) es que debes tener todos los procesos implementados, pero es el documento de ámbito el que regula sobre qué se aplican estos procesos y por lo tanto una aproximación "horizontal" como la que se proponía en las encuestas (un proceso para todos los servicios) no permite la certificación hasta no haber completado toda la implementación (todos los procesos para todos los servicios) mientras que una implementación "por columnas" (es decir, uno o más servicios, todos los procesos) nos permitiría obtener el sello limitado a los servicios que hayamos definido en el documento de ámbito de una forma gradual e ir (con los años) añadiendo nuevos servicios al documento de ámbito a medida que los vayamos madurando.

De esta forma, llegamos a la conclusión de que, si estás pensando una posible certificación sobre la ISO/IEC 20000, quizás la forma adecuada de implementar tus procesos sea definiendo primero el ámbito del proyecto de implantación (y del proyecto de certificación), luego hacer procesos sobre este ámbito y por último a la vez que entramos en la rueda de maduración y mejora de los procesos podemos ir entrando en la rueda de ampliación del ámbito.

¿Qué te parece?

 

Technorati tags:

Cambios en el feed RSS

Despues de la "migración" al nuevo blogger, he encontrado que la dirección del feed Atom que proporciona Blogger ha cambiado, y por lo tanto los lectores RSS dejan de funcionar correctamente.

Por favor, si utilizas un lector RSS, vuelve a suscribirte al blog. Puedes utilizar el feed RSS proporcionado por feedburner aquí:

http://feeds.feedburner.com/gobiernotic

o bien utilizar el feed Atom que proporciona Blogger aquí:

http://gobiernotic.blogspot.com/atom.xml

Gracias!! y una vez más, disculpen las molestias!!

27 de diciembre de 2006

Estamos de Obras

Con la entrada en funcionamiento de la nueva versión de Blogger, he dado el paso y he cambiado a la nueva versión... igual esto tardará un poco en volver a ser como antes, pero mientras tanto

Disculpen las molestias, estamos trabajando para usted.

21 de diciembre de 2006

Medir procesos no es tan simple

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

¿Y porqué tan poca calidad?

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

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

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

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

¡Felices y Mesuradas Fiestas!

19 de diciembre de 2006

Una de legalidad

Hoy tengo que hacer referencia al excelente blog de David Maeztu titulado "Del derecho y las normas", en donde ha publicado recientemente una serie de cinco artículos relativos a las obligaciones jurídicas de los blogs... me ha dejado con la boca abierta. A continuación los links a los 5 artículos, recomendables para todo aquel que quiera ponerse a escribir un blog y poner publicidad en él:

En definitiva, un excelente blog a añadir a tu lector de RSS.

18 de diciembre de 2006

Para leer en vacaciones

Me ha llegado hoy una notificación desde la gente de Dr. ITIL confirmando que el itSMF UK ha publicado ya todo el paquete de presentaciones de las conferencias de este año en Birmingham.

¿Quieres tener lectura para estas vacaciones? Un buen paquete de novedades aqui:

http://www.itsmf.com/events/event.asp?EventID=208

16 de diciembre de 2006

Lo que se nos viene en el 2007

Bueno, ya estamos acabando el año y toca esa sobreactividad que hay en las empresas en estas fechas. Por una parte esta esa sensación como de estar ya casi de vacaciones que te impulsa a dejarlo todo "para la vuelta", y por otra parte está el trabajo adicional de los planes de negocio, planes de formación, evaluación de personal, planteamiento de objetivos, análisis de resultados y todas esas cosas que se suman a tu jornada habitual para dejarte hecho caldo.

Así que creo que poco más voy a poder escribir en lo que queda de año: este post sobre mis "predicciones a lo Rappel" de lo que nos vamos a encontrar en el sector en el 2007 y otro post que estoy escribiendo sobre un asuntillo de métricas.

Así que vamos un poco al grano: mientras que el 2005 ha sido el año de la consolidación de ITIL y del itSMF en España, también ha sido el año en que ha nacido es escepticismo y  la crítica y se ha multiplicado el número de posts y artículos que ponen en duda algunos aspectos de las "sagradas best-practices". Es normal, porque a medida que crece la madurez de las implantaciones y de los propios profesionales, las ideas que tan buenas parecían al principio (ya sea en los 80 o ya sea en el 2000), se han ido quedando cortas.

¿Y qué nos vamos a encontrar en el 2007?

  1. Agitación en el mercado: creo que nos vamos a encontrar con más y más agregación empresarial, así que veremos cómo las grandes compran y compran a las medianas y pequeñas.
  2. ITIL V.3: Está previsto su lanzamiento para la primavera. Ya veremos si no hay más retrasos, pero no creo que salga más allá de Octubre de 2007.
  3. CMMI para servicios: Está cocinándose una nueva versión de CMMI que tiene que añadir un modelo para la provisión de servicios... ¡Al fin tendremos un modelo de madurez "como Dios manda"?! Está previsto su lanzamiento para Abril de 2007
  4. IT Governance Association: Los chicos del itSMF-NL están cocinando un framework completo para IT Governance. Viendo el nivelazo que tienen los holandeses, creo que durante el 2007 podemos esperar avances, publicaciones y un modelo de madurez paralelo (y según ellos basado en CMMI...¿Habrán tenido en cuenta la nueva versión?
  5. ISACA completará COBIT 4: Esto es una necesidad urgente, así que creo que lo tendrán que mover dentro del año. A COBIT 4 le faltan algunas cosillas como por ejemplo las guías de auditoría (presentes en COBIT 3, pero en fase de desarrollo para la versión 4 de los Objetivos de Control).
  6. itSMF Benchmark: Otra vez, los chicos del itSMF-NL nos sorprenderán con los primero resultados de sus estudios de benchmarking... primero un modelo de métricas, segundo un estudio "en real" de estas métricas y luego un modelo formal de benchmarking...¡Interesantísimo!
  7. La guerra abierta en el mercado de la formación: Para el año que viene, con la salida de ITIL V.3 veremos cambiados los esquemas de certificación, y por lo tanto aparecerán nuevos esquemas de formación y una gran necesidad de profesores preparados para impartir este nuevo temario. Además, veremos qué pasa con los nuevos esquemas de certificación pactados entre EXIN e ISEB en contra de los esquemas de APMG (aunque la verdad es que no creo que EXIN e ISEB se muevan tan rápido como para tener presencia en el 2007)
  8. ¿"Movida" con las patentes?: Después de leer el último artículo del IT Skeptic, mucho me temo que tendremos movida en el 2007 alrededor de las patentes de software. Siempre he estado en contra de esta estupidez, pero en el sistema mercantilista en el que estamos metidos hace que sea cierto aquello de "poderoso caballero es Don Dinero".
  9. Actividad alrededor de la ISO-20000: A pesar de que ya en el 2006 ha habido mucha actividad, en España no teníamos norma oficial, así que con la aprobación (esperamos todos) de la norma UNE en Enero del año que viene, veremos como hay mucho más revuelo acerca de este tema. Por lo pronto, supongo que las administraciones públicas comenzarán a exigir este tipo de certificación a aquellas organizaciones que se presenten a los concursos públicos y eso ocasionará efectos secundarios de todo tipo: escasez de profesionales, necesidades urgentes de formación, implantación y certificación, agregación empresarial, etc...

Y estas son las 9 predicciones para el 2007... en Diciembre haremos un repaso, a ver si acerté o no acerté. Mientras tanto, mi deseo navideño para todos aquellos que lleguen a este blog a leer

Que durante el 2007 encontremos lo que buscamos, mantengamos la ilusión y las ganas de trabajar y le sigamos viendo un sentido a todo esto que hacemos.

Ah! Y que en las Navidades del 2007 haga frío como siempre y no tengamos 3 grados adicionales de calentamiento global!

 

¡Feliz Navidad y Feliz 2007!

11 de diciembre de 2006

Al fin la palmó el asesino

Esta tarde sonó el teléfono y mi hermana me dijo que había descorchado una botella de cava. ¡Se murió el Pinocho!, me dijo y yo, al colgar, me fui directo a la nevera y en lugar de tomar café para merendar, saqué una botella de cava, abrí la ventana y la descorché. ¡Esta va por el asesino!

Le tuve que explicar a mi hija que no se debe uno alegrar de la muerte de las personas, pero que hay cuatro o cinco en todo el mundo por los que uno si que puede alegrarse, y este era uno de ellos. Cuando le expliqué qué era lo que había hecho, lo entendió y se tomó su sorbito de cava a la salud de la muerte del militar.

Lástima que haya muerto riéndose de sus víctimas, riéndose de los hijos, mujeres, maridos, amigos, amantes de sus víctimas y no haya muerto podrido debajo de un puente, comido por los gusanos, pero consciente del porqué le pasaba esto. Como una vez oí decir a uno de los que sufrieron en sus propias carnes las atrocidades de este personaje: "Da igual cómo muera, da igual si lo juzgan o no: nunca podrá pagar por lo que ha hecho. Nunca podrá pagar".

Sus hijos, mujer y familiares lo estarán llorando en estos momentos... el viejo asqueroso, dando por culo hasta el día de su muerte! ¡Vaya regalo de cumpleaños para la igualmente asquerosa de su esposa! El destino ha querido que fuera el Día Internacional de los Derechos Humanos, cuando el resto lloramos no por él, sino por todos los que el no dejo llegar a los 91 años, o por aquellos niños que no conocieron a sus padres, o por quienes fueron desterrados, desenraizados, trasplantados y nunca bien aceptados.

El único consuelo que nos queda es saber que era creyente, cristiano y "temeroso de Dios", así que seguramente irá su propio infierno y estará el resto de la eternidad pagando por sus pecados. Y si no existe el infierno, da igual: lo único que deja como recuerdo para la Historia es atrocidad, muerte, odio y locura... ¡qué bonito legado!

Si lees esto y eres pinochetista, "mala cueva, dijo el conejo y se cambió de hoyo". Y si no lo eres, escribe... escribe lo que piensas, escribe lo que sientes, escribe lo que opinas. Que su lápida no se cubra hoy de flores ni de buenas palabras, sino que se cubra del desprecio y los escupitajos de todos aquellos que despreciamos su nombre, su imagen y su recuerdo.

¡VIVA CHILE SIN PINOCHET! ¡VIVA EL MUNDO SIN ASESINOS!

En recuerdo de los muertos, los desaparecidos, los torturados, los desterrados, los relegados, los emigrados, los sufridores... una vela en recuerdo de todos

vela

PS:: Siento el off-topic, pero se lo merece.

8 de diciembre de 2006

Sobran las palabras

Despuñes de mi viaje a Sudamérica había pensado escribir un post llamado "La Brecha Digital", pero cada vez que me ponía a pensarlo resultaba que no me venían las palabras del todo. Quería hablar sobre lo importante que es no permitir que la brecha que separa el mundo desarrollado del mundo que no lo está siga creciendo, pero resulta que la velocidad de crecimiento es muy distinta en ambos extremos, así como en los "mundos intermedios"... esto hará sin duda que la distancia sea cada vez mayor y eso no me deja la conciencia tranquila.

Lo que yo vi en aquellos lares no se puede llamar subdesarrollo, desde luego! son paises con ganas, empuje y sobre todo ilusión e ingenio, y además están en una situación de "mundo intermedio"... y por eso este artículo sobre la "brecha digital" no llegó nunca a ser escrito: lo que yo vi no es nada comparado con lo que realmente es el tercer mundo, así que.. ¿de qué quiero escribir?

Para aquellos que viven en el primer mundo y no han tenido la oportunidad de conocer otras cosas, allá va un par de fotografías sobre la brecha digital en un "mundo intermedio"... la "banda ancha" es una línea de 256Kbps y lo que vemos es "el bucle de abonado al descubierto": Telefónica al otro lado del Atlántico. La señora María lleva 2 semanas sin teléfono porque se cayó un poste por un choque de un camión y todavía no saben recomponer el puzzle.

 

  

En el viaje de vuelta me pusieron "Una verdad incómoda" en el avión y, para terminar de redondearlo, me vine leyendo algunos artículos sobre la globalización en "Le Monde Diplomatique"... para qué decir que tengo los ánimos un poco revueltos últimamente y no me siento precisamente orgulloso de lo que estamos haciendo los "mataos" del hemisferio Norte. 

Ni la Tierra ni la Humanidad se lo merece. 

Actualización 11 de Diciembre:

Hoy me ha llegado la noticia: hacía días que no contestaban al teléfono o no se conectaban al messenger... ¡Han robado los cables! Como lo lees... han robado los cables de Telefónica para venderlos al peso por el precio del cobre... toda la calle sin cables... Cuál será el tiempo de recomponer el puzzle esta vez? Un mes? en estas fechas... quizás dos meses?

7 de diciembre de 2006

Las 15 grandes carencias de ITIL

ITIL v.2 es una virguería. Es una gozada trabajar, pensar, entender y relacionarse con este mundillo, pero muchas veces se puede caer en el equívoco de pensar que "con esto ya tengo suficiente". Además, últimamente se está creando una fuerte corriente de pensamiento crítico al respecto de ITIL, y me ha apetecido hacer una lista de las cosas que creo que le faltan, no con el ánimo de "destruir", sino con el ánimo de construir: con el ánimo de tener esa lista de otras referencias necesarias para darle una visión holística y completa a la profesión. Seguro que me dejo algunas, ya que es una lista subjetiva... es la lista de "lo que yo echo en falta de ITIL v.2" y que posiblemente se vea significativamente reducida con la aparición durante el año que viene de ITIL v.3

A ITIL V.2 LE FALTA:

1.- Un modelo de madurez. ITIL V.2 no tiene modelo de madurez. El itSMF ha propuesto a través de sus herramientas de assessment un modelo de madurez bastante extraño, pero no acaba de convencer. Sería bueno disponer de un modelo de madurez similar al de la Carnegie Mellon, como el de CMMI y COBIT, y en ello se está trabajando desde CMMI para la creación de un nuevo modelo de madurez en la provisión de servicios.

2.- Un buen paquete de métricas. Las que se proponen desde el "Planning to Implement" son bastante pobres y obsoletas. Se han hecho trabajos importantes desde el itSMF publicando el libro de métricas y desde el itSMF España se está trabajando en modelos interesantísimos de métricas e indicadores. Así mismo, COBIT es una buena fuente de datos.

3.- La gestión de los requerimientos. Sobre este tema casi no se habla en los libros de la versión 2, y podemos encontrar una amplia documentación y foco sobre este aspecto en TOGAF.

4.- Operaciones. Como dijo Jan Van Bon en su presentación: "Si no hay cambios, incidencias, problemas, nuevas versiones... ¿qué hace tu gente, se toca las narices? ¡No! Están garantizando el "business as usual", hacen que todo funcione bien" y sin embargo el proceso de operaciones no está contemplado en las Best Practices.

5.- Seguridad. Todo lo relativo a la gestión de la seguridad es ultra-pobre en ITIL, y el libro de seguridad es, además de arcaico, infumable. Cientos de referencias en la ISO 27000, el NIST y demás.

6.- Ciclo de Vida del Servicio. ITIL habla siempre de explotación de servicios ya existentes, pero el antes y el después no están contemplados. Lo veremos en ITIL V.3

7.- Gestion de Proveedores. No hay nada al respecto de la gestión de la relación con proveedores, evaluación de proveedores, compras, contratos de mantenimiento, etc... Algo veremos en la ISO 20000, pero hay otros modelos como el eSCM-CL

8.- Desarrollo. En todas las organizaciones donde he tenido el gusto de trabajar, siempre existe "la gran rivalidad", como un Las Palmas - Tenerife o un Barça - Madrid, el partido estrella es "Sistemas VS. Desarrollo" en un paso a producción. Sería bueno tener un modelo que favorezca el desarrollo no ya de apliaciones sino de Sistemas de Información (con la primera pata en Sistemas y la segunda en Desarrollo). ¡Qué bonito sería que pudieramos convivir juntos en beneficio de nuestro cliente! Aquí hay un modelo interesantísimo que es el ASL.

9.- Paso a producción Idem que el punto anterior, y posiblemente incluidos los dos en el mismo lote.

10.- Gestión de Proyectos A lo largo de todos los libros te "apuntan" hacia metodologías externas de gestión de proyectos, haciendo referencia a PRINCE2 (al fin y al cabo es "la de ellos", no?)

11.- Gestión de Personal A pesar de que el Personal es una de las 3 famosas "P"s de ITIL (aquello del People Process Products), no hay grandes aproximaciones a la gestión del personal, de los costes, de las motivaciones, del cambio cultural, de la formación, etc.. A estudiar fuera del mundo TIC y más en el mundo de los RRHH.

12.- Estrategia Poco, muy poco o nada se habla en los libros oficiales de ITIL al respecto de planes estratégicos del Departamento de Informática, de Planes de Sistemas o cosas similares. Podemos encontrar cosillas en COBIT y en eSCM.

13.- Gestión de Riesgos. ¿Mande? Eso está totalmente fuera del foco o del mundo ITIL y sin embargo poco a poco se está convirtiendo en algo central en las organizaciones. A consultar en las normas y modelos de seguridad.

14.- Finalización del Servicio. No hay (creo) ni una sola palabra al respecto de la finalización de un servicio, de la transferencia de personal, conocimiento, recursos o información hacia servicios sustitutorios o externalizados. Para más información, sólo he visto información sobre esto en los pliegos de la Generalitat y en el eSCM-SP

15.- Guías y Ejemplos de Implantación. Todo el mundo va loco detrás de este tipo de información, pero los que vivimos de este negocio no tenemos demasiadas ganas de compartirla, así que la solución ideal sería que desde la propia OGC se proporcionaran estas guías. Mientras tanto, o las compras, o trabajas de cerca en los grupos de trabajo del itSMF, o inventas o miras lo que hace el gobierno británico

Bueno, esto es todo. Voy a hacer como el amigo Jorge, así que no me dejes ningún comentario en este post con tus ideas o con lo que tu creas que le falta a ITIL, vale?

4 de diciembre de 2006

Factores Diferenciales

El itSMF publica periódicamente una revista llamada Service Talk. Esta revista, además de estar plagada de publicidad (como casi todas las revistas del sector), siempre tiene alguna joya: en cada uno de los números publicados hay al menos un artículo que justifica toda la revista (a diferencia de muchas de las revistas del sector).

En la edición de Octubre de 2006 la joyita es especialmente interesante: un artículo de Gene Kim, de TripWire, llamado "Hit and Hope approach?" que nos cuenta los resultados de un estudio estadístico realizado con el objetivo de encontrar cuáles son los factores que diferencian una organización TIC pobre de una buena, mejor o excelente. ¿Qué hacen los buenos que los hace diferentes?

La aproximación del estudio fue conseguir un conjunto de 21 controles fundamentales de un paquete inicial de unos 150, repartidos en las áreas principales de la BS15000 y posteriormente analizar cómo implementan las diferentes organizaciones cada uno de estos controles.

Las conclusiones del estudio son asombrosas: existe un conjunto de puntos de control que diferencia claramente las organizaciones TIC de alto, medio y bajo rendimiento y más concretamente: la diferencia entre una organización de medio y de alto rendimiento viene directamente relacionada con la existencia y aplicación de dos controles:

  1. Existe una política para evitar la realización de cambios no autorizados
  2. Se han definido y comunicado claramente las consecuencias para aquellos que realicen cambios no autorizados de forma voluntaria.

¡Caramba! ¿Así que esta es la clave? Lógicamente, haciendo esto sólamente no conseguiremos transformar nuestra organización TIC en una de alto rendimiento. Lo que viene a decir este estudio es que si no lo tienes, no lo conseguirás (son condición necesaria pero no suficiente, como decíamos cuando estudiábamos lógica)

Pero a mí lo que me ha llamado poderosamente la atención es el factor CONSECUENCIA. Recuerdo una comida hace años en el Castell de Mediona, en una reunión de hermanos, donde mi hermano Ricardo nos explicaba las bases del sistema educativo que él utilizaba para controlar a sus tres fierecillas:

Ellas saben que cada uno de sus actos desencadena una serie de consecuencias, y así funciona la cosa: ACTO --> CONSECUENCIA

¿Pasa esto en las organizaciones? ¿En tu organización TIC?

¿ACTO --> CONSECUENCIA?

El incumplimiento de las formas establecidas de trabajar (seguimiento de las pautas, de las actividades, de los procesos) es la parte más difícil de cambiar cuando implementamos un proceso cualquiera y yo siempre he dicho que esto sólo se consigue con disciplina, pero... ¿La disciplina siempre sale de dentro? ¿es voluntaria?

Este artículo del Service Talk me ha abierto los ojos: algunas personas, por su carácter, forma de ser, educación o por lo que sea son de por sí mismas ordenadas y disciplinadas, pero la mayoría tendemos a la comodidad, y la comodidad en estos casos es hacer las cosas "como siempre las he hecho y me ha funcionado" y no "como me estás diciendo que las haga ahora".

Así que las consecuencias del incumplimiento deben estar claramente definidas y comunicadas y deben ejecutarse cuando sea preciso.

¡Qué duro es ser padre!