Claves para entender buenas prácticas como PMI, ITIL

pmbokCon un objetivo común de mejora continua y calidad, veo un interés creciente en la adopción de buenas prácticas de gestión empresarial, y cada vez existen más organizaciones y cuerpos de conocimiento al respecto. El principal reto que se plantea es que las buenas prácticas suelen presentarse de una manera genérica y teórica, y están sujetas a múltiples interpretaciones, que hacen que la implantación requiera tiempo de análisis y gestión del cambio. En este artículo, con el que inaguro mi Blog, voy a presentar algunas claves para la parte de análisis, con ejemplos referidos a PMI e ITIL que son las que personalmente más conozco. Me gusta hacer una introducción para los que no tengan un conocimiento previo, pero también puedes ir directamente a los ejemplos.

Las buenas prácticas se pueden ver como un conjunto de procesos y herramientas que se utilizan exitosamente en un gran número de empresas y escenarios en relación con una mayor calidad. La idea principal es que aunque estén extendidas, no implica siempre que sean recomendables para nuestro caso concreto, y por ello en rigor tampoco son metodologías. Por otro lado, si creemos que ninguna nos aplica, o bien nuestra empresa es verdaderamente distinta al resto del mundo, o quizás está actuando inconscientemente la resistencia al cambio. Por su naturaleza genérica, pensando en una implantación, necesitamos seleccionar algunas de ellas y adaptarlas a nuestro caso, ya que la documentación nos va a proporcionar conceptos bastante abstractos y además muy numerosos. Es fácil perderse con todas esas siglas y organizaciones existentes.

itil

Para que se entienda, si estuviéramos hablando de alimentación, un libro de buenas prácticas no sería como un recetario de cocina, sino sobre los principios de la comida saludable: La importancia de la variedad, las calorías, quizás los tipos de aceites y algunas propiedades, la cocción, etc. Alguien que lea este libro dispuesto a cocinar una receta de manera inmediata quedará decepcionado, porque la receta la tiene que crear él, y posiblemente muchas cosas de las que dice el libro no apliquen a esa receta, o incluso ya las sabía de antes.

Macro Close-up of a tomato

La clave para interpretar una buena práctica concreta: Salvo excepciones, creo que al final las buenas prácticas lo que nos están hablando es de riesgos. El no seguir una buena práctica dada, incrementa la probabilidad de un riesgo negativo en términos de calidad o eficiencia. Y en ocasiones el seguirla incrementa la probabilidad del riesgo positivo (oportunidad). Normalmente nos preocupa más el riesgo negativo, por motivos que dan para varios artículos, dejo ese debate para otro momento. Para saber si una buena práctica nos conviene o no en nuestro caso concreto, lo que hay que analizar principalmente es el riesgo asociado. Quiero presentar un par de ejemplos concretos con los que va a quedar más claro:

Ejemplo 1 de ITIL: SPOC (Punto único de contacto para el cliente de un servicio). Se refiere a que desde el punto de vista del cliente de un servicio dado, conviene que sólo haya un punto de contacto único para incidencias, peticiones de servicio, etc. Que existan varios canales de contacto como un formulario web o un teléfono no contradice la buena práctica, si están sincronizados. Pero sí que lo contradice que según la hora o el tipo de consulta el cliente debe decidir qué canal utiliza, porque según el canal o la persona de contacto espera obtener un resultado completamente distinto.

Claramente nos está hablando del riesgo de la descoordinación, y concretamente del riesgo de duplicar peticiones y tener que trabajar más de la cuenta desde la perspectiva del proveedor de servicios. Y de la imagen de mala calidad de cara al cliente, que obtiene diferentes respuestas en diferentes puntos de contacto, lo que de hecho le anima a duplicar las peticiones para ver si en alguna le atienden mejor. Algo más sofisticado, lo que podemos ver es una amenaza para los niveles de servicio, y muy importante entender que es negativa para ambas partes (cliente y proveedor). Pensando en el mundo real, la experiencia nos dice que esto es una utopía (es imposible obtener siempre la misma respuesta ante la misma petición). Pero sigue siendo importante querer aproximarse a ello, aquí es donde entra lo de la mejora continua.

Vamos a la pregunta del millón. ¿Nos conviene adoptar o no esta buena práctica en nuestro caso concreto? Lo que tenemos que valorar es el impacto y la probabilidad de que este riesgo se materialice, que de hecho es la buena práctica para la gestión de los riesgos. En el ejemplo, se trata de saber si se puede dar  o ya se está dando la descoordinación  de los recursos ante la duplicación de peticiones, y si esto ha derivado en un problema para la calidad o eficiencia. Quizás los clientes conocen tan bien al personal que atiende los servicios que saben dirigir muy bien las peticiones a unos o a otros, posiblemente en una empresa de tamaño reducido y actividad estable. Puede que el número de peticiones sea limitado y que la duplicidad no resulte un problema real porque el proveedor ha aprendido a tratar con ello. En estos casos la buena práctica por el momento no es prioritaria. Pero aún así es importante tenerla en mente, porque quizás mañana haya una fusión empresarial, o hay rotación del personal, y cambie este escenario.

Al final se trata de hacer un análisis de coste beneficio entre lo que cuesta implantar la buena práctica, y el impacto del riesgo negativo que evita, dando por hecho que el riesgo se materializa frecuentemente y podemos preguntarnos por el coste que ya supone. También se abre la puerta a otro debate sobre lo que es el coste de la implantación, que se suele centrar en el coste de un proyecto tecnológico, obviando el coste de la gestión del cambio.

OLYMPUS DIGITAL CAMERA

Ejemplo 2 de PMIPMBOK: La técnica más precisa de estimación de tiempos y recursos de un proyecto es la llamada de abajo a arriba, frente a otras como la estimación análoga. Vamos a ver de manera muy resumida en qué consiste cada una:

  • De abajo a arriba o bottom-up: Se refiere a disponer de un desglose detallado de las tareas para conseguir unos entregables previstos, y hacer la estimación a nivel de las tareas más detalladas, para luego ir sumando en los niveles superiores.
  • De estimación análoga o top-down: Se estima el total del proyecto en base a la experiencia previa de proyectos similares, y luego se distribuye con un mayor desglose. Es decir, en castellano, a ojo de buen cubero.

Aquí el riesgo primario radica en que la estimación análoga se puede hacer de una manera más rápida y requiere menos información que otras, pero el margen de error es muy superior, además de dificultar un seguimiento realista de las desviaciones posteriores. Se podría decir que el riesgo se incrementa cuando realizamos la estimación análoga, y tomamos el resultado como algo bastante preciso (un contrato con precio fijo y fechas comprometidas), cuando en realidad a lo largo del proyecto seguramente ya tengamos información suficiente para hacer una estimación mejor.

Otro riesgo, más sutil, es el de no entender bien que hay una hipótesis fundamental para poder aplicar este tipo de estimaciones, sobre todo en el caso de abajo a arriba: Que los entregables están muy bien definidos y se sabe cómo generarlos. No descubro nada nuevo al decir que proyectos como los de desarrollo de software no lo suelen cumplir, lo que hace que una aparentemente buena práctica no lo sea, y que por lo tanto requiera alternativas más ágiles de las que espero comentar mucho.

Resumiendo, suele haber una relación muy directa entre buenas prácticas, riesgos y oportunidades, que hay que saber interpretar antes de decidirnos por implantar unas u otras. No tiene sentido empezar a implantar todo lo que dice un documento o todo lo que proporciona una herramienta informática sin entender lo que pretende resolver, si parte de alguna hipótesis, y sin pasar un filtro básico de coste beneficio. Hay que tener muy claro además que la gestión del cambio es el factor crítico del éxito en estas implantaciones, por encima del tecnológico. Tampoco tiene sentido pensar que nada nos aplica en nuestro caso, salvo que seamos muy excepcionales, más bien es un indicador de resistencia al cambio y de poco interés por mejorar.

Bueno, se trata de mi primer post. Ahora me gustaría conocer tu opinión. ¿Le ves alguna utilidad? ¿Discrepas? ¿Te ha parecido un rollo? ¿Te animas a mencionar algún otro ejemplo? Recuerda que con cada comentario y recomendación permites que otros puedan encontrar mi artículo, y me ayudas aumentando mi red de contactos. Espero que seas uno de ellos. Ten en cuenta que lo que me gustaría es el debate y no un monólogo, esto depende de ti. Un saludo y muy agradecido porque hayas llegado a leer hasta aquí.

Anuncios
Esta entrada fue publicada en Gestión, Tecnología y etiquetada , , , , , , , . Guarda el enlace permanente.

4 respuestas a Claves para entender buenas prácticas como PMI, ITIL

  1. Hola Julio, me gustó mucho tu artículo sobre todo la analogía con las comidas saludables, que tanto nos hacen falta. Creo que uno de los principales temas que tenemos con las buenas prácticas es que: No se conocen en la realidad en que consisten por diferentes motivos, como por ejemplo que estamos muy ocupados en lo que hacemos y no tenemos el tiempo, nos come el dia a dia en los trabajos. El otro punto, es el querer cambiar, el querer hacer las cosas mejor de las que las hacemos en estos momentos, pero eso ya pasa por un tema de personas, de no tener miedo al cambio, al sacarse las atadurías que llevamos por dentro y liberarnos internamente y eso nos permitirá mejorar e irradiar hacia afuera.
    Yo siempre me pregunto, como es posible que casos como ITIL, que son buenas prácticas de los años 80, aún no sean tan masivas como deberían, e incluso en los Ministerios Públicos de algunos paises no sean comunes, siendo que nacen de ahí mismo.
    Per bueno, como las dietas y los gimnasios, existen pero no son ocupados por todo el Mundo, esperamos si ir evangelisando cada vez mas. Una vez que descubres como hacer las cosas, de manera lógica y práctica, no lo olvidas y persistes.

    Un saludo.

    Cristian

    • José Julio López dijo:

      Hola Cristian Fernando, muchas gracias por animarte a comentar el primero. Y sí, lo de las comidas saludables, a mí me hace más falta que a nadie.
      Previo a la mejora hay que parar a reflexionar, evidentemente con cierto equilibrio que no nos paralice, pero hay que parar. Se entiende que hablamos de mejoras a medio o largo plazo. Por ello, en estos escenarios donde se nos pide mayor productividad, sobre lo que espero escribir otro artículo, es muy difícil parar y tomar una cierta perspectiva que no sea el resultado del próximo trimestre, siempre en mi opinión.
      Para un caso como un ministerio público, o de una empresa compleja en general que ya tenga una cierta trayectoria cultural, la cosa se complica más. Para que se pueda dar este tipo de cambio tienen que pasar varias cosas, algunas tomadas de tu comentario:

      – Hay que querer mejorar (plan)
      – Hay que saber qué riesgos o problemas se quieren abordar (plan)
      – Hay que centrarse en unas mejoras concretas para un cierto plazo temporal (plan)
      – Hay que concretar cómo se va a conseguir la mejora y cómo se va a medir, con un estudio de coste beneficio aunque sea básico (plan)
      – Hay que hacerlo de verdad, y esto implica vencer resistencia al cambio, comunicación, arrimar el hombro, a veces parar el día a día, etc. (do)
      – Hay que medir y chequear si se ha conseguido o no lo esperado (check)
      – Hay que decidir sobre los resultados chequeados, introducir cambios, y vuelta a empezar (act)

      No es que el plan lleve mucho más tiempo que el resto, es que he querido detallarlo más para que se vea que no estoy hablando únicamente de hacer un Project.
      Por no extenderme más, y de nuevo es una opinión muy personal y discutible, las mejoras planteadas a muy corto plazo y parciales no garantizan una mejora a medio o largo plazo.

      Un saludo.

  2. Juan Carlos Menéndez Manso dijo:

    Gracias José Julio por el interesante artículo.
    Yo, cada vez que me acerco a una nueva tecnología, intento siempre buscar las personas con experiencia en las mismas y las buenas prácticas que aconsejan. Qué mejor comienzo que empezar por hacer las cosas como las aplican los expertos en dichas materias.
    Y efectivamente, siempre me pregunto e intento comprender el porqué de las recomendaciones, aunque a veces peque de querer entenderlo todo antes de conocerlo en profundidad.

  3. José Julio López dijo:

    Gracias a ti también Juan Carlos por animarte a comentar. El factor crítico es encontrar un equilibrio entre llevar a cabo las tareas y gestionarlas en mejoras sucesivas. Recientemente me he certificado también en Scrum, que es un marco ágil, y que aboga por este refinamiento sucesivo en períodos muy cortos (sprints), profundizando en cada sprint en tareas muy concretas, sin perder la visión general.

Deje una Respuesta

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s