martes, 4 de noviembre de 2014

Implementar ISO 20000 poco a poco: UNE 71020

Para ciertas organizaciones, ni muchas ni pocas, adoptar ITIL® y/o certificarse de ISO20000 implica la creación de un proyecto complejo, en el que decenas de personas están implicadas y deben ser coordinadas de la mejor forma posible.

El proyecto planificado, para estos casos, suele estar dividido en fases. Sin embargo, las fases deben ser flexibles y puede que solapadas, aunque depende de cada caso. Esto es debido a que los procesos dentro de ISO 20000 están muy relacionados entre sí, especialmente desde que ISO 20000:2011 da más importanca al ciclo de vida y no a los procesos, como la ISO 20000:2005.

Por ello, en Octubre de 2013 se publicó la norma UNE 71020: "Modelo de conformidad incremental basado en la Norma UNE-ISO/IEC 20000-1". Esta norma guía la implementación de la ISO 20000 dividiéndola en tres fases. Cada fase constituye un escalón de madurez más hacia la certificación, de forma paulatina y, para mi gusto, más eficiente que el modelo de "cada fase del proyecto tiene X procesos que hay que implementar".

Tenemos tres niveles:
  • Nivel Básico: asegura el funcionamiento operativo de los procesos a nivel más básico, más reactivo, definiendo políticas y planes iniciales.
  • Nivel Avanzado: los procesos y procedimientos implican proactividad, lo que permite tener un ciclo de Deming implementado, y unas políticas, procedimientos y procesos más maduros.
  • Nivel Completo: los procesos están integrados y hay cultura de servicio, lo que permite comenzar a recopilar evidencias de cara a obtener la certificación ISO 20000.
Espero que haya resultado interesante, y que las organizaciones con un mínimo de complejidad no se asusten a la hora de querer obtener la certificación. Al fin y al cabo, es pura competitividad.


miércoles, 29 de octubre de 2014

Las mejores métricas

He vuelto a encontrarme con la pregunta del millón: ¿cuáles son las mejores métricas para gestión de X (donde X es cualquier proceso)? No he podido resistirme y he querido escribir un pequeño apunte sobre ello en este blog, y así intentar contestar a la pregunta.

Es cierto que ITIL® menciona y propone una cantidad de métricas muy grande. Quizá haya tantas métricas propuestas que el profesional se vea confundido, lo cual es perfectamente comprensible, y ocurre muchas veces. El origen de la pregunta está en qué métricas elegir, y eso no es trivial, pues la métrica es en lo que se va a basar el gestor para optimizar la generación de valor del servicio.

Para elegir las métricas tenemos que saber cuáles son los objetivos del negocio y analizarlos para traducirlos al lenguaje técnico, un análisis TOP-DOWN hacia nuestro lenguaje. El primer análisis nos dará muchísima información, llegando a las primeras métricas básicas necesarias (3, 5, 10... no importa el número). Aquí comienza nuestro primer ciclo de Deming o PDCA (concepto básico para cualquier norma o estándar).

En cuanto midamos y analicemos resultados (A), veremos si hacen falta más métricas (o menos, pues puede haber métricas que no nos den información relevante), y así volveremos a diseñarlas y planificarlas (P). Con conocimiento del negocio y ayuda sobre cómo obtenerlas, en cada ciclo tendremos las métricas que aporten información relevante a la hora de tomar importantes decisiones.

viernes, 17 de octubre de 2014

Significado de conseguir la certificación

En una de las redes sociales en la que estoy registrado, soy seguidor de una academia de idiomas que organiza no sólo cursos, sino grupos de conversación y tándem de idiomas. Me ha llamado la atención que esta semana hayan publicado en su blog el logro de la certificación ISO9000, incluso han colgado el certificado en formato pdf en su web, con su el alcance bien definido.

Siempre estoy pendiente de casos de éxito a quien entrevistar, y revisando el correo por si alguien, de forma proactiva, quiere compartir su caso en este blog. Por ello, quiero hacer un llamamiento destacando que un caso de éxito que se publica es en realidad un éxito dentro de una organización.

Conseguir la certificación de la normativa o estándar ISO (u otro sistema de estándares) es el resultado de meses de trabajo, meses de implantación, en la que están implicadas la gran mayoría de las personas dentro de una organización, aunque ellas no lo sepan.

Con esta idea, queda gratamente justificada la publicación en la red social, intranet o página web corporativa de estos logros, acompañada de un agradecimiento a todos los participantes, insisto, aunque ellos no lo sepan. No obstante, la certificación nunca es el objetivo, sino el medio para conseguir la mayor rentabilidad, sea del tipo que sea (ver posibles respuestas en Primera pregunta para cualquier ISO).

jueves, 9 de octubre de 2014

Auditoria en Gestión del conocimiento

El proceso de gestión del conocimiento es uno de los que más ha incrementado su nivel de importancia en la nueva edición 2011 de ITIL®, y su implantación ha estado creciendo en los últimos años en muchas empresas. Esto es debido a que el objetivo de este cumple con los nuevos requerimientos de las empresas, especialmente en materia de recursos humanos, especialmente en la parte de TI.

A medida que pasa el tiempo, el proceso se va haciendo cada vez más maduro, pero para saberlo hay que medir su efectividad y eficiencia, y nada mejor para ello que incluirlo en el plan de auditoría interna.
Pero como no hay una norma certificable en sí (), podemos basarnos en la Guía europea de buenas prácticas para la gestión del conocimiento (CWA 14924), en la guía española UNE 412001, en la guía australiana AS 5037 Knowledge management: A guide o en la misma ITIL®, especializada en TI (y en la que está especializado este blog), entre los muchos ejemplos que puedo dar.

Escojamos la que escojamos (si escojemos), vamos a tener que medir el proceso, como siempre, en base a:
1. Alcance
2. Requerimientos
3. Frecuencia de actualización del proceso
4. Casos de éxito (definir "caso de éxito" en función del alcance del proceso)
5. Interfaz con otros procesos

Para más información sobre la gestión del conocimiento, recomiendo seguir, tanto este mismo blog como el blog Gestión del Conocimiento TI.

miércoles, 1 de octubre de 2014

¿Qué es el SAC?

SAC son las iniciales de "Service Acceptance Criteria" en inglés, en español es "Criterios de Aceptación del Servicio". Tenemos una definición oficial en ITIL®, en español, a continuación:
España: Conjunto de criterios utilizados para asegurar que un servicio de TI cumple con su funcionalidad y requisitos de calidad y que el proveedor de servicio de TI está preparado para operar el nuevo servicio de TI una vez ha sido implementado.
LATAM: Es un conjunto de criterios utilizados para garantizar que un servicio de TI cumple con sus requerimientos de funcionalidad y de calidad y que el proveedor de servicios de TI esté listo para operar el nuevo servicio de TI cuando este haya sido implementado.
En el SAC, como proveedores de servicio, escribimos cómo cubrimos los requisitos y cómo entregamos el servicio. El SAC lo tenemos en un documento, que está vivo durante todo el ciclo de vida del servicio, y está íntimamente ligado, al menos, con el SLR ("Service Level Requirements" o "Requerimientos de Nivel de Servicio"). Cuando cambia un requerimiento, el SAC debe ser actualizado para asegurar que estamos entregando el servicio como debe.
Es un documento muy importante que permite al cliente saber que podemos ofrecer el servicio, y no estamos "vendiendo humo". Le dice al cliente que cubrimos no sólo los requerimientos, también los tests que hagamos, nuestros proveedores, el soporte, el software, la documentación técnica disponible, personal y planes, tanto de implantación como de roll back; y que hacen que nosotros, como proveedor de servicios, somos una pieza sólida para el Negocio del cliente.

Puedes volverte loco/a escribiendo el SAC. Hay que estudiar bien los requerimientos y tener los procesos lo suficientemente maduros como para cubrirlos, y con esto lo diferenciamos de la oferta. El SAC es más formal, más técnico, menos comercial; es aquéllo que diferencia un proveedor de otro.

miércoles, 24 de septiembre de 2014

ITSM cerca de Negocio

El pasado día 11 de septiembre de 2014, tuvo lugar una presentación en el foro regional del itSMF del Norte de Alemania (itSMF Regionalforum Nord) en Hamburgo. En él, Mathias Stüben y Thomas Friese, jefes de proyectos de Otto GmbH & Co. KG, presentaron la idea de negocio y cómo ITSM es un aspecto clave en él.

Básicamente, su negocio consiste en la venta de artículos por Internet, dinamizando el precio de los artículos según la ley de la oferta y la demanda. Me he acordado de aquellos días de formación en los que se repetía hasta la saciedad: "En ITIL®, TI = Negocio, Negocio = TI". De hecho, si miramos sus ofertas de empleo, la mayoría son de perfil técnico.

Con el divertido nombre de la ponencia: "Mit Intelligenz zum optimalen Preis – Dynamische Preisgestaltung find‘ ich gut!" ("Con inteligencia hacia un precio óptimo - ¡Veo bien los precios dinámicos!"), nos dan una lección sobre cómo, de verdad, TI = Negocio y Negocio = TI. Lo consideraré un caso de éxito, no ya de implementación de procesos o de tecnología, sino de implementación de filosofía.

lunes, 8 de septiembre de 2014

Catálogo vs. Cartera de servicios

El título de este no es el más acertado, ya que uno no va en contra del otro, más bien al contrario. Pero muchas veces es necesario distinguir ambos conceptos, ya que en la mayoría de los casos se utilizan de forma incorrecta, basándonos en el estándar ISO 20000 o en el estándar de facto ITIL®.

La Cartera o Portfolio de servicios, traducido del inglés Service Portfolio, es la lista o conjunto total de todos los servicios que ofrece, ha ofrecido u ofrecerá la organización. Así, se compone de tres partes:
  • Service Pipeline: son los servicios que están propuestos o en desarrollo, pero que aún no se están ofreciendo.
  • Service Catalogue: es el catálogo de servicios, es decir, el conjunto de servicios que se están ofreciendo actualmente.
  • Retired Services: es el conjunto de servicios retirados, los que ya no se ofrecen por parte de la organización.

Por tanto, siguiendo el título de la entrada, el Catálogo de servicios es parte de la Cartera o Portfolio de servicios.
 
Es importante distinguir estos tres conceptos, ya que dependiendo de la estrategia de la organización, de la que toda persona involucrada en ella debe tener conocimiento, el Service Pipeline puede ser o no ser público: los servicios en desarrollo o planteados pueden ser clave para el futuro de la organización, especialmente en materia de distinción frente a la competencia.

Cuestión de Estrategia.


martes, 26 de agosto de 2014

Nivel de detalle de la CMDB

De los muchos debates que leo en las redes sociales, quiero escribir sobre uno que puede dar para horas y horas de debate en vivo: ¿Qué nivel de detalle es necesario para mi CMDB? Aprovechando el tema, quiero hacer una pequeña recopilación de respuestas, que he resumido en cinco, y la conclusión que nos da ITIL®. Creo que el debate es interesante:

Respuesta 1: "El nivel de detalle se determina a partir del uso que le quieras dar a la CMDB. Mayor nivel de detalle significa que algo no será usado y tendrá difícil mantenimiento. Menor nivel significa coste sin beneficios."

Respuesta 2: "Deben estar todos los datos que sean representativos de los componentes, unidades de negocio, de auditoría, de financiero, herramientas de infraestructura y monitorización. Debemos dejar de pensar en la CMDB de 1999 y empezar a pensar en las soluciones y el valor que traerá a la organización la CMDB de 2020".

Respuesta 3: "Mira las formas que tienes de alimentar la CMDB y comprueba cómo se relaciona toda la información, en lugar de perder tiempo en estar del lado de 'cuanta más información, mejor'".

Respuesta 4: "Céntrate en las unidades de arquitectura y las unidades de negocio, y olvídate de la microinformática: PCs y Switches".

Respuesta 5: "Ten en cuenta a las funciones de negocio específicas y a los usuarios específicos que están afectados cuando monitorizas los servicios. No tienes que complicarte si la CMDB va a ser usada para monitorizar desde el punto de vista del Negocio".

Respuesta ITIL® (pequeña parte): "La CMDB no es un inventario, solo contiene elementos de configuración necesarios o importantes para proporcionar un servicio. Se recomienda hacer un análisis TOP-DOWN para su diseño, partiendo del catálogo de servicios, y un análisis bottom-up para calcular el coste de un servicio".

El debate sigue abierto, pero el resto de respuestas viene a ser un diálogo entre dos comerciales, bastante interesante por otra parte. No obstante, todo el debate se centra en estas cinco.

Los debates de CMDB son de los más demandados y uno de los más complejos de abordar, ya que cada organización tiene sus requerimientos, sus necesidades y sus objetivos, además de que cada técnico tiene diferentes formas de hacer las cosas (ni mejor ni peor, sino diferentes).

lunes, 18 de agosto de 2014

Caso de éxito: ITIL® con OTRS en Teralco

OTRS es una herramienta alemana de gestión de servicios de código abierto que cubre muchos procesos ITIL®. En esta ocasión entrevistamos a Víctor Adsuar, CTO de Teralco, muy orgulloso de su equipo de trabajo especialmente por la implantación de OTRS internamente.

Pregunta: ¿A qué se dedica Teralco? ¿Cuál es vuestro negocio?

Respuesta: Teralco es una empresa ubicada en Alicante y fundada en el 2002. Nos dedicamos al desarrollo software principalmente, además somos especialistas en soluciones de BI, plataformas y comunicaciones. Nuestros sectores principales son banca y administración pública. Disponemos de diferentes productos propios para la gestión de la administración pública, gestión de proyectos de desarrollo y lanzamiento de campañas de marketing. Nuestro ámbito es nacional, aunque tenemos planeado un salto internacional a corto plazo. 


Actualmente estamos en plena inmersión en el mundo cloud con el desarrollo de nuevos servicios a través de esta tecnología y no paramos de innovar. Muchos de nuestros productos se licencian bajo términos de código abierto y somos muy proactivos en el uso de tecnologías Open Source. Mantenemos relaciones de socios con compañías como Red Hat, Amazon AWS y Cisco.

P: ¿Consideráis crítica una buena gestión de los servicios de TI para vuestro negocio? ¿Es directa la relación entre vuestro ITSM y el cliente? 
R: La gestión de los servicios es crítica para cualquier empresa del siglo XXI, independientemente del sector. En este aspecto hace unos cuatro años nos dimos cuenta que no era suficiente coger el teléfono, o contestar el correo de los clientes, necesitábamos algo más. Por ello pensamos que la adopción de ITIL® nos podría ayudar a cerrar el ciclo del servicio y no quedarnos únicamente en dar una respuesta a nuestros clientes. A través de OTRS pretendíamos establecer una relación más estrecha con nuestros clientes y generar una relación de confianza robusta.

A día de hoy estamos muy concienciados y realizamos un seguimiento constante del estado de nuestros servicios y de la satisfacción de nuestros clientes. Desde la implantación de OTRS hemos intentando centralizar toda nuestra gestión a través del iTSM. Nos gustaría, ofrecer nuevas características a través de él, ya que OTRS nos sorprendió muy positivamente en referencia a la cantidad de posibilidades que ofrecía.

P: ¿Cuánto tiempo lleváis con OTRS instalado y funcionando? 
R: Hace unos cuatro años comenzamos el estudio de una herramienta que nos diera una visibilidad sobre el estado de los servicios de operaciones. En dicho estudio nos hicimos conscientes que no sólo debíamos conformarnos con una herramienta que nos ayudara con la gestión de los tickets de soporte, necesitábamos algo más. Estudiamos herramientas como RT, eTicket, sin embargo estas herramientas únicamente se quedaban en la gestión de tickets, por aquel entonces OTRS sacó su módulo de Gestión del Cambio y vi un post en un blog que hablaba sobre OTRS y cómo estaba cerrando el ciclo de vida del servicio a través de sus módulos. Me quedé impresionado de las posibilidades que ofrecía esta herramienta y además bajo denominación Open Source. Comenzamos con una prueba de concepto, que no tardó en materializarse y convertirse en producción de manera interna en unos meses, para luego abrirla a nuestros clientes.

P: ¿Qué otras alternativas teníais? 
R: Debido a que somos una empresa de desarrollo estuvimos valorando el propio desarrollo de una herramienta, ya que en el mundo Open Source no encontrábamos un iTSM que cerrara todo el ciclo de vida del servicio. Estuvimos viendo SpiceWorks, eTicket, RT, pero ninguna era completa, por lo que se pensó adoptar una y desarrollar de manera independiente el resto de módulos que faltaban. 

También se valoró la adquisición de una solución propietaria cerrada. La primera opción nos disparaba los tiempos de adopción de la herramienta, y la necesidad era apremiante, por lo que no nos podíamos permitir el lujo de estar casi un año desarrollando y adaptando una solución. La segunda opción, la compra de un software propietario, era muy cara y la solución muy sobredimensionada para nuestras necesidades. Por lo que los costes de eran inasumibles por nosotros. Finalmente ambas opciones se descartaron al conocer OTRS. 

P: ¿Teníais experiencia en la herramienta? 
R: Por aquel entonces habían pocas soluciones completas iTSM y las que había no nos convencian. OTRS estaba avalado por Pink Elephant y era relativamente fácil de implementar. Además las otras dos opciones que barajábamos no se adaptaban ni en tiempo, ni presupuesto, por lo que nos pusimos a ello. En ese momento no teníamos experiencia como administradores en ninguna herramienta iTSM, sin embargo como clientes trabajábamos con varias de proveedores y sabíamos lo que queríamos. Necesitábamos agilidad en nuestros procesos y que la información del estado del servicio llegara a todos los participantes.

P: ¿Por qué os decantásteis por software libre? 
R: Por filosofía, somos una empresa que apuesta con el software libre como modelo de crecimiento sostenible. Nuestros desarrollos en administración pública se entregan bajo licencia GNU, especialmente nuestra Suite de Gestión de Administración Pública Gexflow. 

P: ¿Fue dura la implantación? ¿Quién se vio afectado? 
R: Toda implantación conlleva superar retos y requiere esfuerzo. En este caso comenzamos con una prueba de concepto que empleamos para la gestión de servicios internos. Durante este periodo tuvimos que realizar algunos ajustes en la configuración. OTRS es muy versátil y permite una personalización muy fina gracias a la herramienta de configuración de sistema. Gracias a la documentación y a la existencia de muchos foros activos los problemas que fueron surgiendo se solucionaron con relativa sencillez. Por otro lado la gestión del cambio se quedaba corta para nuestras necesidades, ya que finalmente somos una empresa de desarrollo.

Lo que hicimos fue integrar nuestra herramienta de gestión de proyectos con OTRS, de manera que podemos asociar servicios generados en OTRS con un proyecto concreto. Con este simple enlace conseguimos integrar la gestión de proyectos con la de servicios empleando el concepto de proyecto como metodología para la gestión del cambio. Esta implantación afectó prácticamente a toda la empresa, desde a los desarrolladores, agentes de soporte, administración, dirección de proyectos y servicios. Pero sin duda, el trato con el cliente fue lo que proporcionó una revolucionó en el servicio. Fue un cambio radical en nuestra gestión que implicó a todos. De hecho sino hubiera sido así no creo que se hubiera llevado con éxito. De hecho las personas son lo más importante para este tipo de retos.

P: ¿Qué formación necesitásteis? ¿OTRS, ITIL®, ISO20000, etc.? 
R: Soy certificado ITIL®v3 y dirigí la implantación de la ISO 27001. OTRS fue de ayuda en la obtención de la certificación, tengo que puntualizar que OTRS no tiene una gestión del riesgo, pero gracias a la creación de campos para cada CI en la CMDB pude catalogar cada CI según los requerimientos de la certificación. De momento no nos planteamos la ISO20000 en nuestros servicios, ya que creemos en la flexibilidad en la adopción de ITIL® como filosofía para la mejora de nuestros procesos y pensamos que esta característica es la que nos otorga más potencia para adaptarnos a los requerimientos de nuestros clientes. 

P: ¿Necesitásteis consultoría externa? Si no es así, ¿conocíais la herramienta? ¿recibisteis formación? 
R: No solicitamos consultoría externa, ni formación, ni conocíamos la herramienta. Tuvimos que asimilar la filosofía del OTRS con ITIL®, sin embargo esto fue fácil, ya que la herramienta está muy orientada a este conjunto de buenas prácticas. Para ello se realizó la prueba de concepto que empleamos de manera interna a modo entorno de preproducción. En dicho entorno fuimos modificando las configuraciones según necesidades. Por lo que la implantación se realizó a nuestra manera de trabajar y para dar el servicio que requerían nuestros clientes. El objetivo final era facilitar nuestra comunicación del estado de servicio con nuestros clientes y en ello nos centramos.

P: Entonces la adaptasteis y os adaptasteis a ITIL®.
R: ITIL® al fin y al cabo es un conjunto de recomendaciones que puedes adoptar en tus procesos. OTRS está orientado a ejecutar esos procesos. Por ello cogimos de OTRS aquello que nos hacía falta y lo pusimos a funcionar.

P: ¿Qué procesos implementásteis? 
R: Principalmente Servicios de Operación: gestión de incidencias, problemas y eventos. Además administración de SLA’s y la CMDB.

P: ¿Entonces tenéis CMDB? ¿También con OTRS? ¿Se implantó mediante un proyecto aparte o conjunto? 
R: La base de datos de configuración se implementó conjuntamente con OTRS. La intención inicial era integrar la CMDB con una herramienta de monitorización como Nagios para la que en el momento que una alarma saltará en algún CI asociado a un servicio, el estado del servicio cambiara. Finalmente no se llegó a implementar ese proceso y actualmente es un proceso manual. La CMDB se adaptó para que los servicios acogieran los despliegues de los clientes y dichos despliegues con diferentes elementos. Esta visión nos ayuda mucho y mejora los tiempos de respuesta a la hora de dar soporte y planificar cambios. 

P: Tenéis planificado un cambio de versión. ¿Lo haréis vosotros?
R: Si, ya tenemos experiencia en la herramienta y la documentación proporcionada sigue siendo clara y extensa.

P: ¿Aprovecharéis para implementar mejoras en los procesos? 
R: Por supuesto, queremos dar mayor servicio a los clientes y mejorar la calidad. Por lo que consideramos fundamental automatizar procesos que actualmente no podemos por limitaciones de la versión instalada. Además nos gustaría añadir la base de datos de conocimiento, gestión de OLA’s de nuestros proveedores, el uso de herramientas de calidad para evaluar la satisfacción de nuestros clientes y una mejora integración de nuestros SLA’s con las necesidades reales.

Gracias a Víctor Adsuar por contestar a las preguntas y por compartir con todos su experiencia. Destacaré dos cosas del equipo de implantación:
  • el riesgo que asumieron al adoptar una herramienta de código abierto y la notable buena  gestión del proyecto de imlantación, que minimiza ese riesgo. Demuestra la implicación del equipo con la empresa.
  • la conciencia que adquieren con la experiencia de que la gestión de los servicios de TI es muy necesaria para ofrecer unos servicios que se mejoran día a día.
Enhorabuena, y gracias de nuevo.

martes, 12 de agosto de 2014

ITIL® Lite de Malcom Fry

Allá por el año 2010, Malcom Fry (reconocido profesional inglés de ITSM con más 40 años de experiencia, su currículum es para dedicar una entrada de este blog) publicó un libro que dio que hablar, aunque lamentablemente no tanto como hubiera podido ser, al menos fuera de Reino Unido y Alemania. Su nombre: ITIL® Lite: Un Road Map para la implementación total o parcial de ITIL® (nombre original: ITIL® Lite: A Road Map to Full or Partial ITIL® Implementation).


Tal y como se presenta, parece un libro en el que se da a conocer una versión de ITIL® más reducida. Sin embargo, para versión reducida de ITIL® ya tenemos nuestra ISO20000. Lo que hace el autor en este libro es presentar conceptos como Lean ITSM, y describir una serie de pasos para implementar ITIL®, tanto desde cero como partiendo de la implementación total o parcial de ITIL®v2.  Luego actualizó el libro para adaptarlo a ITIL® ed.2011.

El núcleo de todo esto es que ITIL® es un framework muy grande, y no hay por qué implementar todos los procesos. Debemos identificar qué procesos aportan más valor a nuestro negocio, e implementarlos de tal forma que obtengamos el mejor ROI, utilizando la espiral de mejora contínua que es base de la filosofía ITIL® e ISO20000.

Cualquier consultor dirá que implementar un proceso complejo desde cero es como intentar suicidarse (en el sentido metafórico), por lo que se suele recomindar una implantación paulatina, y es el consultor el que sabe qué pasos hay que llevar con el mínimo presupuesto, sin caer en saco roto.

Este libro, como algunos otros publicados, es una recopilación de muchos años de experiencia. Esperemos que se sigan publicando este tipo de temas, y que este blog ponga su granito de arena, al menos en temas de actualidad.

lunes, 4 de agosto de 2014

Probando mi CMDB

No quiero irme de vacaciones sin dejar un post que nos haga leer en el verano. No es para reflexionar, sino para comprobar todo lo que podemos hacer con un mínimo de recursos. Y con esta introducción, de sobra se ve que este post va dirigido más a las PYMEs que a las gigantes.

He estado haciendo pruebas y modificaciones de una herramientra libre de CMDB (obligatorio para la ISO20000, y muy útil para quien le dé igual la certificación), y el resultado ha sido muy positivo, con sus pros y sus contras. La herramienta es la alemana i-doit, y sí, el principal problema es la nacionalidad, pues la herramienta "out-of-the-box" viene en alemán, inglés y (curiosamente) está disponible también en portugués. Afortunadamente estoy preparando una versión en español que estará lista a finales de agosto, para los interesados.

Hay varias versiones de la CMDB, pero nos centraremos en la versión open con licencia GPL, que no viene con soporte, pero que permite ser instalada, probada y utilizada en producción en un tiempo más que interesante.


La instalación la realizamos en servidor Unix, por lo que también he ahorrado la licencia de sistema operativo. El servidor es uno que tengo preparado para hacer mis pruebas, con lo mínimo instalado para que funcione el software, con un entorno gráfico rápido. Todo consume un mínimo de recursos, por lo que la CMDB tendría que ir muy rápido, y así ha sido.


En "out-of-the-box" viene con una serie de clases de elementos de configuración (CIs) ya definidas, pero que se pueden agregar o quitar, así como sus atributos. Se puede gestionar la infraestructura, el software y "otros", como teléfonos móviles, planes, etc.


Además, se pueden crear workflows (flujos de trabajo) y todo es exportable e importable por csv y xml; y al menos por csv funciona bien. 

Los grandes contras (para lo que es el coste de la licencia de la herramienta: 0€) son principalmente dos:
  1. No es trivial de aprender a usarla, aunque tampoco hay que hacer un Master. Hay que saber de gestión de configuración, de qué van este tipo de herramientas y saber en qué entorno funciona bien. Este punto es especialmente importante para las PYMEs, cuyo presupuesto, a priori, es más limitado que las gigantes.
  2. El idioma puede ser un inconveniente, a menos que el gestor y/o usuarios sepan mucho inglés o alemán. En este punto estoy trabajando para dar una respuesta optimista después del verano.
  3. No tiene las características de la versión pro o herramientas de pago, como por ejemplo el gráfico de estudio del impacto, por lo que se asemeja más a un inventario, aunque permite las relaciones entre CIs necesarias para que se llame CMDB.
  4. Evidentemente, no hay soporte.
Con el tiempo, intentaremos que otras herramientas de CMDB, comerciales o no, nos permitan ser comparadas para hacer un interesante estudio de mercado. De momento, ya sabemos cómo va esta primera.

Feliz verano 2014.

martes, 22 de julio de 2014

Documentación TI e ISO: forma y contenido

La documentación de todo sistema de gestión es lo primero que mira e auditor a la hora de realizar una auditoría. Esto se conoce como la primera fase de la auditoría, y es filtro para la segunda fase, que es la visita del auditor a la oficina o complejo físico donde se realizan las actividades de la organización a certificar.

Con este primer párrafo, dejamos en evidencia la importancia de tener una documentación bien formada del sistema de gestión, pues toda norma o estándar ISO a certificar tiene unos requisitos que se deben cumplir, y a los que se añaden dos que están, muchas veces, implícitos:
  1. Los documentos deben ser comprensibles por todos los miembros de la organización, y consistentes en su formato, para una buena legibilidad.
  2. Toda la información relevante, y sólo la información relevante, debe estar documentada, de tal forma que pueda ser accesible para todo miembro de la organización.
A todo esto, personalmente agregaría que el contenido debe estar escrito de forma clara y concisa, sin ambigüedad ni dudas, y de forma lo más compacta posible, para mejorar no sólo la legibilidad, sino también la comprensión. Es un criterio de calidad al que siempre intento apelar cuando hacemos consultoría o ingeniería inversa de software antiguo (o nuevo). El objetivo es siempre mejorar el conocimiento de las personas, que es el factor clave de toda organización.

He querido dedicar algunos post, entre ellos este primero que sirve de introducción, a la gestión de la documentación de TI, aprovechando que el próximo jueves 24 de Julio de 2014 tiene lugar un foro itSMF de Saar (Alemania) que se centra en la documentación de TI, donde habrá dos charlas.

La primera charla se llamará "Documentación de TI integrada" ("Integrierte IT-Dokumentation"), por Manuela Reiss, CEO de Dokuit y autora de "Guía práctica para la documentación de TI" ("Praxisbuchs zur IT Dokumentation"). En su charla nos hablará de cosas tan interesantes como los típicos problemas de la documentación de TI, del establecimiento de un sistema de gestión documental y de los requisitos de documentación de la ISO22301.

La segunda charla será un ejemplo práctico de la herramienta QuadrixShare de la empresa ZWF, y será presentada por Nora El Fayoumi, gestora de cuentas de ZWF.

Estaremos atentos sobre las conclusiones a las que llegan las ponentes en sus respectivas charlas, y sacaremos nuestras propias conclusiones.

miércoles, 16 de julio de 2014

ISO 21500 para una boda

Dicen que es el sueño de cualquier hombre, pero este sueño se ha vuelto realidad al menos para uno. Gracias a conocimientos básicos del estándar ISO 21500 sobre gestión de proyectos, una pareja anónima (veremos el porqué) ha utilizado esta herramienta para planificar y ejecutar su boda en 10 días.

Pregunta: ¿Cómo se os ocurrió utilizar la ISO 21500 para planificar vuestra boda?
Respuesta (ella): Nosotros vivimos en el extranjero, pero nos queríamos casar en España. El problema es que nuestras visitas deben ser muy rápidas, fugaces, porque donde estamos no tenemos los 15 días libres por boda, así que, digamos, tenemos que "ahorrar" días de vacaciones para poder irnos unos días de luna de miel. Él sabe de gestión de proyectos y me propuso todo esto.
Respuesta (él): Aunque no tengo certificados, conozco y he trabajado con estándares y marcos como ISO9000, ISO20000, ITIL®, PRINCE2... y la nueva ISO21500. Pensé que sería una buena idea utilizar ISO21500 para aprovechar lo máximo, ya que no podemos ir y venir todos los días... y era una buena oportunidad para leer la norma a fondo.

P: ¿Nos puedes dar una idea sobre cómo ha sido la experiencia?
R (él): Al principio nos costó porque yo soy de ciencias y ella es de letras, y yo nunca había explicado estos temas a nadie.
R (ella): Bueno, que sea de letras no significa que sea tonta.
R (él): Sí, pero tenemos diferentes formas de hacer las cosas y esto es un poco complejo de explicar, sin embargo lo cazaste todo a la primera, y eso que era el primer riesgo que teníamos que gestionar, jejeje.

P: Vamos, que también teníais un proceso de gestión de riesgos.
R (él): Por supuesto, los listamos en base a lo que nos contaron de otras bodas, y aún así nos salieron otros problemas... Gracias a ello, por ejemplo, tardamos 3 días en elegir restaurante, mitigamos ese riesgo haciendo sobre-documentación de algunos restaurantes de la zona, mirando precio, fotos y foros de internet.
R (ella): De esto me encargué yo, hice una lista de restaurantes candidatos, los llamé y planifiqué las visitas en dos días. Lo que más hice yo fue la planificación, planifiqué todo para que nos cupiera en 5 días: visitas a restaurantes, elección de las las invitaciones, mi prueba de peinado, compra de zapatos...

P: ¿Teníais un diagrama Gantt o similar?
R (ella): Sí, al principio, pero lo usamos sólo para hacer una lista de tareas, ya que iba a ser muy poco tiempo. Teníamos apuntado quién era el encargado de hacerlas y en qué momento tenía que hacerlo. Dividimos los 5 días en 3 partes: mañana, tarde y noche.

P: ¿Y la gestión de Stakeholders?
R (él): Sabíamos a la gente a la que íbamos a "molestar": mis padres y los suyos. Así podíamos delegar tareas, como la elaboración de la lista de invitados y la elección de mi traje [esboza una sonrisa]. Yo soy más sencillo...
R (ella): También delegamos la elección de los regalitos que se dan en las bodas, y a nuestras hermanas, la música, aunque para eso hay mucho más tiempo. Y en cuanto al resto... pensamos en los invitados, en su comodidad. Pero es nuestra boda [hace gesto de disculpa].

P: ¿Conocéis la gestión del alcance?
R (él): Creamos también una lista de requisitos que queríamos cumplir, y menos mal que somos gente sencilla... Desglosamos lo más importante: restaurante, vestimenta e invitados. No pusimos cosas que considerábamos superfluas, al fin y al cabo: teníamos 5 días. Si en adelante queríamos algo más, lo haríamos si tenemos tiempo, si lo podemos hacer "a distancia" o si lo podemos delegar. A partir de ahí creamos la lista de tareas que te decíamos antes.

P: ¿Y la gestión de costes? ¿Cómo lo habéis planteado?
R (él): Muy fácil, tenemos un presupuesto y de ahí no puede pasar.
R (ella): Repartimos ese presupuesto en varios mini-presupuestos: restaurante, fotógrafo, vestidos y "otros", por si se nos ocurría algo o tuviéramos algún contratiempo. Tuvimos que hacer malabares con alguna cosa, pero no salió mal.

P: ¿Cómo habéis gestionado los recursos?
R (él): Casi todo está hecho en listas, en un excel. Diferenciamos dos tipos de recursos: para la boda y para esos 5 días. Para la boda básicamente es el presupuesto y los padres, a los que podemos delegar algunas cosas. Para esos 5 días era fácil: un coche y un teléfono móvil con saldo. Lo difícil podría haber sido conseguir el coche, pero tuvimos suerte.

P: Supongo que la gestión de calidad...
R (él): No, eso sí que no hemos hecho. Bastante teníamos como para hacernos auditorías a nosotros mismos...

P: Bueno, no es sólo eso.
R (él): Lo sé, pero con tener la lista de tareas y su estado nos valía. No hacía falta informes [ríen los dos].

P: Vamos, entonces gestión de integración era bastante difícil.
R (él): Sí, pero integramos bien el equipo y coordinamos bien las tareas, no lo llevamos con rigidez pero creo que hubo menos problemas de coordinación entre personas (nuestros padres) y tareas de lo que esperábamos. No obstante, su hubiera algún cambio en lo que sea, nosotros somos los que finalmente tenemos que decidir, a menos que sean cosas pequeñas, como si es mejor regalar espejitos o alfileres a las mujeres en la boda.

P: ¿Algún plan de comunicación?
R (él): El plan es delegar la mayoría, con seguimiento semanal [carcajada] por si acaso se les olvida.
R (ella): Mis padres se lo comunican a mi familia y les entregan las invitaciones, sus padres a la suya, y nosotros a nuestros amigos.

P: ¿Creéis que habéis aprendido ISO 21500? ¿O gestión de proyectos?
R (ella): Hemos utilizado lo que nos ha servido, tal vez no la hemos aprovechado al máximo, pero siempre se aprende algo.
R (él): Yo conocía conceptos, y algunos proyectos sencillos ya he llevado. Pero lo importante es que he leído la norma y la hemos aplicado lo mejor que hemos podido. Tal vez algo un poco más ágil nos hubiera servido más, pero quería conocer la norma, y aprovechando el momento, la he leído a fondo.

Después de esa charla en tono medio broma, mi conclusión es que ahora ya lo tienen bien claro; os felicito tanto por vuestra boda como por la labor que habéis conseguido hacer.

Espero que esto sirva de ejemplo de uso, y si los dos respondéis "sí" al cura en septiembre (espero que sí), que sirva como caso de éxito. Y si después de publicar esta charla os suena el teléfono, no dudéis de que puede ser otra pareja que busque vuestro consejo.

lunes, 7 de julio de 2014

SLA y la gestión de proyectos

La primera vez que escuché el término Nivel de Servicio fue hace algunos años, cuando hice mi primer curso de ITIL®. Sin embargo es uno de los términos de los que más he oido hablar desde entonces, y es que cuando hablamos de la gestión de calidad uno tiende a necesitar ciertas herramientas, y nada mejor que utilizar las que ya funcionan en otros ámbitos.


Un SLA es un acuerdo, un contrato. Un nivel de servicio, según ITIL®, es un "resultado medido y reportado frente a uno o más objetivos de nivel de servicio. El término nivel de servicio se emplea a veces para referirse a un objetivo de nivel de servicio". Normalmente se ponen objetivos por tiempo. Por ejemplo, para un Help Desk se puede poner un SLA por tiempos de respuesta y/o por tiempos de resolución.


El tema viene porque este concepto se extiende a muchos niveles, y aunque un estándar ISO no lo requiera implementado, es algo que se está implementando "por defecto" en cualquier sistema, incluído, curiosamente, en la gestión de proyectos.


Los modelos de gestión de proyectos, como "proyeto cerrado + bolsa de horas" o "gestión ágil de proyectos", traen los SLA de serie, y es que tanto el proveedor como el cliente tienen la sensación de que necesitan una herramienta como esta para asegurar la calidad, tanto del proyecto como del producto. Puede que tengan razón cuando dicen que incrementa la calidad del proyecto: se obtienen mejores tiempos y una planificación más ágil. 

Pero dudo mucho que hablemos de una mejora en la calidad del producto. Para eso recomiendo un buen plan de auditoría y de aceptación del producto (ver Gestión de Calidad en ISO21500) o un estándar "de facto" como Seis Sigma o Six Sigma. Lo define muy bien Wikipedia [1]:
SIX SIGMA es una metodología de mejora de procesos, centrada en la reducción de la variabilidad de los mismos, consiguiendo reducir o eliminar los defectos o fallas en la entrega de un producto o servicio al cliente. La meta de 6 Sigma es llegar a un máximo de 3,4 defectos por millón de eventos u oportunidades (DPMO), entendiéndose como defecto cualquier evento en que un producto o servicio no logra cumplir los requisitos del cliente.
Referencias:
[1]  "Seis Sigma": Wikipedia [en linea], http://es.wikipedia.org/wiki/Seis_Sigma


lunes, 23 de junio de 2014

Caso de éxito en Avalon: ISO20000 e ISO27000

Recientemente he tenido el honor de conocer el caso de éxito de Grupo Avalon en su proceso de certificación de ISO 20000 e ISO 27000, y he aprovechado la oportunidad para hablar con Juan Carlos Torres Alvarez, Director de Calidad del Sotware, que ha tenido a bien contestar a unas preguntas clave en su proceso que son de gran interés para todos.

Pregunta: ¿Cuál es el negocio de Grupo AVALON?
Respuesta: AVALON es una consultora de TI de capital español y cuyo negocio es:

  • Prestación de servicios:
    •  Profesionales para el desarrollo, mantenimiento y operación de sistemas de información.
    •  De mantenimiento de aplicaciones y sistemas
    •  Factoría de sw mediante la atención de peticiones de órdenes de trabajo de diseño y/o construcción de software
    • Proyectos de desarrollo de software en los que se cubre todas las fases del ciclo de vida de desarrollo de SW.
  • Consultoría de procesos de TI

P: ¿Cuál es el alcance de las certificaciones? ¿Son el mismo alcance?
R: El alcance geográfico de las dos certificaciones es el mismo, Delegación de Madrid, difiriendo en el funcional:

  • ISO27001 el alcance son los sistemas de información que dan soporte al negocio de Avalon
  • ISO20000 los servicios profesionales y de mantenimiento que AVALON presta a sus clientes

P: ¿Por qué decidieron certificarse? ¿Cuál es su motivación?
R: Los motivos son los mismos para ambas certificaciones:

  • La importancia que la dirección de AVALON da a la gestión por procesos y la gestión de éstos.
  • La adopción de un modelo para la gestión de TI
  • El alineamiento de los procesos de AVALON con los estándares internacionales del sector.
  • La diferenciación de AVALON en el mercado.
  • El posicionamiento de AVALON en los puestos de cabeza cuando se haga efectivo el tan deseado fin de la crisis.

P: ¿Fue de las dos normas a la vez? ¿Decidieron ejecutar las dos en un único proyecto?

R: Aunque las dos normas se auditaron a la vez, la adaptación de los procesos a sus requisitos se abordaron en dos proyectos paralelos, aunque relacionados en algunos puntos. El motivo de esta decisión fue el diferente alcance funcional: interno en la ISO27001 y los servicios prestados a los clientes, por tanto externo,  en la ISO20000.


P: ¿Recibieron ayuda de consultoría externa? ¿Formación tal vez?
R: No se contrató ningún servicio de consultoría externa. 


P:
Entiendo entonces que, como director de calidad, tienes buen conocimiento de las normas ISO, o hay un experto en AVALON que sepa interpretarlas y tratarlas con agilidad, para así planificar un proyecto de forma clara. ¿Es así?
R: Como Director de Calidad de Software tengo una amplia experiencia en la Mejora de Procesos y en la Gestión de Servicios, lo que me ha permitido, como tú bien dices, interpretar las normas y "aterrizarlas" a las peculiaridades de AVALON
 
P: ¿Qué es lo que más les costó durante el proyecto, desde su concepción?
R: Aquí me gustaría añadir que buena parte del éxito de la certificación viene dada por diseñar la implementación de las iniciativas de mejora de procesos, y estas certificaciones lo son, con un proyecto estándar, con su planificación, seguimiento, gestión de riesgos e incidencias tan formales como lo son en cualquier proyecto, por ejemplo, de desarrollo de software. La peculiaridad de estos proyectos, bajo mi punto de vista, es que lo fácil es el diseño de los procesos, con unos requisitos claros, las normas, y escasa gestión de cambios de requisitos motivado por la estabilidad de las normas, y lo difícil es la implantación de los mismos, es decir la gestión del cambio cultural que se produce en las organizaciones. Mi receta para gestionar el cambio es:

  • Formación, formación y más formación.
  • Buscar aliados entre los referentes de la organización que favorezcan la implantación de los procesos. 
  • Evitar, en la manera de lo posible, la confrontación que se produce ante las fuerzas inerciales que producen el cambio. 
  • Empleo mayoritario del principio de "auctoritas", aunque en ciertas ocasiones no haya más remedio que recurrir al principio de "potestas". 
  • Predica con el ejemplo, adoptando el proyecto de mejora los procesos que se van diseñando.

P: ¿Qué esperan conseguir con las nuevas certificaciones?
R: Creo que ya lo he indicado en las motivaciones: 

  • Diferenciación en el mercado
  • Posicionamiento destacado en el futuro relanzamiento económico.
Te agradezco Juan Carlos que compartas con nosotros vuestra experiencia, y mi enhorabuena por el objetivo logrado. La manera que habéis tenido de enfrentaros al cambio ha sido muy positiva, lo que seguro ha sido clave para el éxito de ambos proyectos.

martes, 17 de junio de 2014

No conformidades

Uno de los temas más polémicos que hay en cuanto a la adaptación de estándares en una organización es el cómo encajar las No conformidades, y esto es algo general para todos los sistemas de gestión de calidad. Para comenzar, definiremos una No conformidad como un “Incumplimiento de un requisito” [ISO 9000:2005, definición 3.6.2]. Hay de dos tipos:

Las mayores: son ausencias o fallos al implantar y mantener uno o más requisitos del sistema de gestión de la calidad. Si el auditor ha detectado una No Conformidad mayor, al menos una, no entregará el certificado de conveniencia a la organización.

Esto quiere decir que el equipo implementador no ha tenido en cuenta todos los requisitos, y ha ido al proceso de certificación sin prepararlo. Para ello, siempre recomiendo un consultor que esté preparado, que sepa de lo que habla y que sepa guiar a la organización en todo el proyecto.

Las menores: son aquellas en las que se ha detectado un fallo puntual en algún proceso. En términos legales, podemos tener infinitas No Conformidades menores y obtener el certificado de calidad, siempre y cuando no haya ninguna mayor.

Está claro que nadie quiere tener No Conformidades, pero el tipo de no conformidad menor puede verse como algo positivo. Esto quiere decir que alguien externo (el auditor) ha caído en que algo que se puede mejorar. Es independiente de las propuestas de mejoras, que son algo extra, pero que conviene tener en cuenta para el siguiente ciclo PDCA.

lunes, 9 de junio de 2014

Estudio de situación de ITIL

Para conocer el estado del arte de las implantaciones de los procesos ITIL en las organizaciones, es necesario una evaluación. Hace unos años (cómo pasa el tiempo!), el itSMF España, de la mano de un estudiante que realizó un completo proyecto de fin de carrera, lanzó unas encuestas para evaluar el estado de implantación de los procesos ITIL y de gobierno TI en las organizaciones.

El resultado de este proyecto se puede encontrar en el e-archivo de la Universidad Carlos III de Madrid, y se llama "Análisis y estudio sobre el gobierno y gestión de los servicios TI en el mercado español".

Y al igual que est eproyecto, el itSMF Alemania ha lanzado una encuesta parecida, junto con las universidades de St. Gallen (Universität St.Gallen, Suiza), Berín (Humboldt-Universität zu Berlin, Alemania) y el centro de negocios de Copenhage (Copenhagen Business School, Dinamarca).

La encuesta se puede realizar en inglés, alemán y danés, y se puede realiza ra través de la URL http://itil.selfsurvey.org. Estaremos al tanto de los resultados, pues será objeto de comparación entre las organizaciones centroeuropeas y las españolas que, adelanto, no estarán muy dispares.

lunes, 2 de junio de 2014

Creación un catalogo de servicios

El pasado 22 de Mayo se impartió en Alemania un curioso seminario web, o webinar, llamado "Diseño de servicios - desde la especificación al concepto de servicio" en el que el ponente explicó un procedimiento para crear un catálogo de servicios.
Y digo curioso por la relación que tiene con este blog, en el que intento describir los estándares ISO sobre TI más demandados. Uno de mis estándares favoritos es ISO20000, y si el lector ha leído la norma sabrá que tiene un catálogo de servicios como requisito, pero no pide un proceso de gestión del catálogo, algo que sí propone ITIL®, y que tiene las actividades (sin ser puristas):

 - Definición de las familias principales de servicios a prestar, registro de los servicios en activo y de la documentación asociada a los mismos.
 - Mantenimiento y actualización del Catálogo de Servicios.

El ponente describía varios pasos, un poco más sistemáticos que lo que nos propone ITIL®. No olvidemos que ITIL® no nos dice el cómo, sino el qué. Los pasos que se describieron en el seminario son muy detallados y, aunque me quedo con la explicación para el futuro, todo depende de la organización.

Los pasos descritos, grosso modo, son:
 - Identificación de servicios: ver qué servicios estarán dentro.
 - Especificación de servicios: identificación de atributos.
 - Diseño de servicios: borrador de mapa de servicios.
 - Orquestación: elaboración del mapa de relaciones entre servicios.
 - Catalogación de servicios: descripción detallada.
 - Service-Kommittierung (no sé cómo traducir esta palabra xD): descripción de las necesidades del cliente para cada servicio y de los SLA (Service Level Agreement).
 - Aprobación: se aprueba el catálogo y se publica (o se modifica).
 - Facturación: se diseña y crea el método de facturación.

Me parece interesante comentarlo en este blog, ya que ofrece un punto de vista muy procedimentado para cubrir una necesidad que tienen muchas organizaciones a la hora de implantar un sistema de gestión de servicios.

Ni que decir tiene que yo lo probaré.

martes, 27 de mayo de 2014

Breve descripción de ISO 38500

Read in english
Quiero dedicar una pequeña entrada al tan querido por muchos estándar ISO 38500. ¿Por qué es tan querido por muchos? Porque su objetivo es enmendar aquél enfoque en el que las tecnologías de la información (TI) falla o ha estado fallando históricamente hasta hace razonablemente poco: su enfoque al negocio. Esto crea el llamado "gobierno corporativo de TI", y no está inventado por la ISO 38500, sino que tiene historia, como CobIT.

El estándar ISO 38500 trata de alinear TI con el negocio, por lo que está hecha para el gobierno o dirección de las organizaciones. No obstante, los lectores no tienen que ser sólo directores, sino que todo el mundo debe saber de qué va la historia. Y es que en TI no hay (casi) nada aislado.

Tratando de dar una pincelada a su descripción, diremos que el gobierno de las TI se fundamenta en seis principios: Responsabilidad, Estrategia, Adquisición, Rendimiento, Conformidad y Conducta humana.

Para acabar, quiero destacar lo que considero más bonito de la norma: el punto 3.1. En él se describe cada principio en base a tres tareas fundamentales: Evaluación, Dirección y Monitorización, y comienza diciendo, básicamente, que cada organización debe implementar sus propias tareas para cubrir estos principios, y que cualquier variación de las tres sugeridas será bien considerada.

Read in spanish
I want to dedicate a small entrance to a so loved by many people ISO 38500 standard . Why is it loved? Because its purpose is to fix something that the information technology (IT) fails (or has been failing) historically: their approach to business. That creates the "IT governance", and it has not been invented by the ISO 38500, it has history, like CobIT .

The purpose of the ISO 38500 standard is to align IT to the business, so it has been made for government or organization management. However, the readers are not only directors, everyone should know what the story is about. And in IT there is (almost) nothing isolated .

Trying to give a piece of cake of description, we say that IT governance is based on six principles: Responsibility, Strategy, Acquisition, Performance, Conformance and Human Behavior .

Last but not least, I want to highlight something I consider the most beautiful thing of the standard: 3.1. It describes each principle is based on three fundamental tasks: "Evaluate", "Direct" and "Monitor", and it begins saying, basically, that each organization must implement their own tasks to meet these principles, and that any variation should be well considered.

jueves, 22 de mayo de 2014

Los procesos y la CMDB

Read in english

Recientemente he debatido con algunas personas sobre la CMDB (Configuration Management Data Base, o base de datos de gestión de la configuración) y su automatización, y aunque no haya acuerdo definitivo, podemos llegar a conclusiones interesantes. Quiero exponer las mías, que por supuesto puede evolucionar a lo largo del tiempo, usando CMI (Continual Mental Improvement) :-D

El uso de herramientas que pueblen la CMDB es de gran utilidad, especialmente cuando el número de CIs (Configuration Items, o elementos de configuración) es bastante grande. ¿Nos atrevemos a poner un número? Aquí sí que hay debate. Yo diré 100 CIs, por poner un número redondo. Si hay más, yo sí recomendaría invertir en una herramienta de población de la CMDB, pero si hay menos puede costar más que hacer inventario manual.

No obstante, es importante quedarse con dos ideas fundamentales:

  1. Ningún estándar ISO (a día de hoy) obliga a tener una herramienta para poblar la CMDB de forma automática. Hay que tener presente sus ventajas como la automatización, ahorro de tiempo y exactitud; así como sus desventajas como el coste de licencia, instalación y revisión.
  2. Esté o no automatizada la población de la CMDB, cualquier cambio que haya en sus datos debe pasar por el proceso de gestión de cambios. Esto sí es obligatorio, y supone una No Conformidad en una auditoria, en este caso, del estándar ISO20000 o ISO27001.

Read in spanish I recently talked with some people about the CMDB (Configuration Management Data Base) and automation , and although we got no final agreement, came into interesting conclusions. I want to expose my own , which of course can improve, using CMI (Continual Mental Improvement) :-D

Using tools to populate the CMDB is very useful, especially if the number of CIs (Configuration Items) is quite big. Should we say a number? Here there is a good debate. I will say 100 CIs, for example, only to give a round number. If there are more, I do recommend investing in a tool to populate the CMDB; but if there are less, it could cost more than do manual inventory .

Anyway, it is important to keep two fundamental ideas :
  1. No ISO standard (nowadays) ask for a tool to populate the CMDB automatically. We must keep in mind its advantages such as automation, time saving and accuracy; and its disadvantages, like the cost of license, installation and maintenance.
  2. Whether or not the population of the CMDB is automatic, any changes in its information stored must go through the change management process. This is mandatory, and would be a nonconformity in an audit, in this case, of the standard ISO20000 or ISO27001.