lunes, 31 de marzo de 2014

Dibujando los procesos TI

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.
  1. 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.
  2. 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.
  1. 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 .

  2. 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.