Read in english
Hace dos post hablamos de dos puntos críticos favoritos (o curiosamente más preocupantes) para los responsables de las organizaciones a certificar. En el anterior post hablamos de uno de ellos: las Personas. Del otro hablaremos ahora: los Procesos.
No es casualidad que hablemos de otra de las cuatro P's del Diseño del servicio ITIL®, y es que vamos a dar por obvio que aquellas organizaciones que ya están certificadas tienen estas dos patas de la mesa bien sujetas desde la implementación del SGS (Sistema de Gestión del Servicio). Como consultor, no daría nada por sentado, pero como divulgador, confiaré.
Si su organización se quiere certificar en ISO20000, debe diseñar/descubrir y documentar los procesos debidamente. Para ello hay que dibujarlos y explicarlos. Para explicarlos, procuro hacer matrices RACI, son muy cómodas y deja bien claro quién hace qué (sí, sigo con que el "quién hace qué" es importante: nuestra P de Personas). Además, suelo explicar cada paso textualmente para que no queden dudas.
Para dibujarlos, intento recomendar no más dos lenguajes o métodos, en mi gusto personal: IDEF0 y UML.
- IDEF0: Integration Definition for Function Modeling, es un lenguaje de modelado para la representación gráfica de un sistema dentro de una organización, en nuestro caso, de procesos.
Los lleva usando la parte de Negocio desde los años 70 (bueno, especialmente en USA), así que puedo decir que me gusta porque está muy cercano al Negocio, es entendible por él. Y como se basa en diagrámas jerárquicos, su lectura puede ser razonablemente sencilla para nosotros, gente de TI.
- UML: Unified Modeling Language™, es un lenguaje de modelado para la representación gráfica de software. UML tiene muchos tipos de diagrama, así que hablaremos específicamente de los diagramas de actividad para dibujar los procesos.
Tal vez haya muchos detractores, pero estos diagramas son fácilmente interpretables por el personas de TI, y si el proceso no es extremadamente complejo, puede ser razonablemente sencillo para la gente de Negocio.
Tengo la conclusión de que uno no es mejor que el otro para todos los casos; siempre se elige según los Stakeholders, los gustos y la orientación que se le quiera dar a la ISO20000. Pero lo que sí aseguro es que hay que maximizar la comprensión de los procesos por todas las Personas.
Leer en español
Two post ago we talked about the two favorites critical points (or, curious, more disturbing) for the responsible of the organizations. In previous post we talked about one of them: the People. About the other we talk now: Processes.
It
is no coincidence that we talk about another of the four P's of ITIL® Service Design, and we are going to consider that those
organizations that are already certified have these two legs
of the securely fastened since the implementation of SMS (Service Management System) . As a consultant, I would not give anything for granted , but as a writer, I will trust.
If your organization wants the ISO20000 certification, you should design/discover and document the processes properly. In order to do this, we draw and explain them. To
explain, I normally do RACI matrices: they are very comfortable and makes it
clear who does what (yes, still with the "who does what " is important:
our P of People ). Also, I usually explain each step with texts for the avoidance of doubt.
To draw the processes, I try to recommend no more than two languages or methods, in my personal opinion: IDEF0 and UML.
- IDEF0
: Integration Definition for Function Modeling is a modeling
language for the graphical representation of a system within an organization, in our case, process.
The
Business has been using it from the 70s (well, especially in the U.S.), so I can say I like it because it is very close to the business; it is understandable for it. And based on hierarchical diagrams, reading can be reasonably easy for us IT people .
- UML: Unified Modeling Language™, is a modeling language for the graphical representation of software. UML has many types of diagram, so we'll talk specifically about activity diagrams to draw processes.
There may be many detractors, but these diagrams are easily interpretable by the IT people, and if the process is not very complex, can be reasonably simple for Business people.
I
conclude that one is not better than the other for all cases; always
chosen according to Stakeholders, tastes and guidance you want for the ISO20000 . But what I can assure is that you have to give full understanding of the processes to all People.
Read in english
En el anterior post vimos que hay dos puntos críticos favoritos de todo responsable de un SGSTI basado en ISO20000 en cuanto a la documentación. En este post veremos el primero, muy especial, que solidifica una de las 4 P's del Diseño del servicio ITIL®: Personas
(People). Esta es una pata de la mesa que, como no esté bien, la mesa
cojea. Y sin esto no sólo la organización no se certifica de la
ISO20000, sino que su gestión se hace muy difícil.
Tal
es así, que por mucho que lo tengamos documentado, si los Stakeholders
no están al tanto de sus roles y/o responsabilidades, es una No
Conformidad Mayor para el auditor. Por tanto, el consultor y el jefe de
proyecto tiene (o tienen, si son dos personas diferentes) que estar muy
atento/s a todos ellos y hablarlo detenidamente.
¡Ahá! ¡En el párrafo anterior ha salido el concepto "Stakeholder", pero... la ISO20000 no lo define! Usaremos la definición que da la ISO21500, que se acerca mucho a la que nos dice ITIL®, pero que considero un poco más completa en su forma.
Satkeholder: [1] Persona, grupo u organización que tiene interés o puede afectar, ser afectada, o que percibe que puede ser afectada por cualquier aspect o del proyecto.
Con esto, el consultor/jefe de proyecto sabe lo que tiene que hacer: identificarlos. Es crítico no sólo para el servicio, sino para el proyecto de implantación del SGSTI basado en ISO20000.
¿Por qué es crítico? Imagine una organización en la que hay personas que no sepan lo que tienen que hacer...
Leer en español
In the last post we saw that there are two critical points, that are the favourites of the person who is responsible of the ITSMS based on ISO20000, if we talk about documentation. In this post we will see the first one, very special for us because makes solid one of the 4 P's of ITIL® Service Design: People. It is a "leg of the table", and if it is not OK, the table won't be stable. Without this, the organization won't be able to get the certification
ISO20000, and what is more important, the service management will be... not very good.
With this, no matter how much documented is out ITSMS, if the Stakeholders don't know what
they have to do, which role and responsibility they have: it is a Non-Conformity for the auditor. So, the consultant and/or project manager must be observing, defining and identifying all of them.
Aha! In the last paragraph we got the concept "Stakeholder", but... ISO20000 doesn't define it! Let's use the definition given by ISO21500, which is very near to the definition given by ITIL® (more complete, under my point of view).
Satkeholder: [2] Person, group or organization that has interests in, or can affect, be affected by, or perceive itself to be affected by, any aspect of the project.
With this, the consultant/project manager knows what he/she have to do: identifying. It is critical not only for the service, also for the project to implement a ITSMS based on ISO20000.
Why is it critic? Try to imagine an organization where the people doesn't know what they have to do...
[1]
Análisis ISO 21500 [en línea]. [España]: Grupo de Análisis para la
implantación de la norma ISO 21500 [ref. de 18 de marzo de 2014].
Disponible en Web: <http://www.iso-21500.es/guia-iso-21500>
[2] ISO 21500:2012, point 2.14.
Read in english
Toda ISO necesita de documentación. Nosotros, que somos de TI, nos dividimos en dos grandes grupos: los que les encanta documentar y los que odian documentar. Lo mejor? Siempre un término medio, y prueba de ello son las metodologías ágiles que se están poniendo tan de moda (aunque surgieran hace muchos años).
No existe una estructura fija para documentar nuestro Sistema de Gestión. Sin embargo, poniéndo el ejemplo de la ISO20000 procuro tener, en una primera implementación, un mini-documento por proceso y otro del Sistema de Gestión del Servicio TI. No obstante, el objetivo siempre es tener el menor número de documentos posible, equilibrandose con la cantidad de contenido (vamos, que ni queremos la Biblia, ni queremos multitud de fichas inmanejables).
El consultor que eche una mano a una organización debe guiar en cómo crear la política del SG y de cada proceso (importante!), pero sobretodo, debe ayudar en dos temas clave:
- Identificar y documentar roles y responsabilidades
- Identificar, adaptar y documentar los procesos.
Siendo estos dos de los puntos favoritos en la ISO20000 para mucha gente, merece que les dedique un post a cada uno. Por ello, las dos siguientes entradas hablaran sobre la criticidad de estos temas y cómo hacerles frente, sin rodeos.
Leer en español
Every ISO stardard needs documentation. We, the IT people, have two main big groups: the documentation-lovers and the documentation-haters. The best thing? I always recommend a middle position, and the agile methodologies (becomed fashionable, but quite old) are the evidence.
There is no fixed structure to make documentation about our MS (Management System). However, taking ISO20000 as an example, I try to have, as a first implementation, a little document for each process, and another document for de SMS (Service Management System). Nevertheless, the purpose is allways to have the less-as-possible number of documents, keeping a balance with the content (I mean, we don't want the Holy Bible, but we don't want thousand little cards).
The consultant must give guidance in the process of the creation of polices, the documents of each process (important!) and other documents. But specially, he/she must help in two key therms:
- Identify and document roles and responsibilities
- Identify, adapt and document the process
As these are the two favourites points in ISO20000 of a lot of people, I will write a post for each one. They will be the next two post, and we will talk about their criticity and how to face them.
Cualquier consultor lo sabe, pero no siempre se deja claro desde el principio. Para dejarlo de forma muy esquemática, las auditorías de calidad tienen dos fases: en la primera fase se envían al Auditor Líder todos los documentos relacionados con el diseño del Sistema de Gestión (SG). El Auditor Líder los revisa para ver si, teóricamente, el SG cumple con los requerimientos de la norma en cuestión.
Si todo está bien, se accede a la segunda fase de la auditoría, y a la que todos "temen": la visita. El Auditor Líder hace una visita a las instalaciones de la organización que se quiere certificar y comprueba que todos los Stakeholders realizan el trabajo acorde al diseño del SG. Cuando termina esta fase, el Auditor Líder entrega el informe de auditoría al responsable dentro de la organización.
Este post quiero dedicarlo a la primera pregunta que hace en Auditor Líder al CEO, CIO o Persona de mayor rango: ¿Por qué queréis certificaros? Dependiendo de la respuesta, se seguirá con la auditoría de una forma o de otra, por lo que hay que preparársela muy bien.
Posibles respuestas:
- Porque la ISOXXXXX es clave para conseguir nuevos clientes.
- Porque es requisito para los concursos.
- Porque nos diferencia de la competencia en las ofertas.
- Porque si no, la competencia se diferencia de nosotros.
- Porque la tropa hace un gran trabajo y con la certificación subirá su moral.
- Porque me han convencido de que siguiendo el esquema, vamos a dar un mejor servicio/producto al cliente y eso mejora nuestra imagen.
- ...
¿Qué respuestas has escuchado tú?
