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.

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.

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