ITIL®, COBIT®, PMBOK®, entre otros frameworks

Sabemos que para gestionar las TI existen diferentes framework o marcos. Están también los viejos conocidos como COBIT® y el PMBOK®.

Recordemos que un marco es una estructura real o conceptual destinada a servir como un soporte o guía para la construcción de algo que expande dicha estructura en algo útil. Es necesaria para evitar re-inventar la rueda (la tecnología, y su eficiencia) y enfocar esfuerzos (recursos, capacidades, presupuestos, entre otros) en las reglas del negocio. La necesidad de emplear un marco es variable, y hasta cierto punto. No olvidemos que hay que adoptar y adaptar las cosas a nuestra realidad.

Por ejemplo, ayer un exalumno estaba esperando rendir su examen de certificación en ITIL® Fundamentos, el cual aprobó, y me contó mientras esperaba, que recién con el curso que le di entendió todo lo que en su empresa existía desplegado referente a ITIL®.

Bueno, lo cierto es que ITIL® estaba desplegado, implantado, pero no estaba interiorizado, no había sido adoptado. Este mismo exalumno lo reconoció. Los usuarios internos no tienen conciencia de por qué hacen las cosas; simplemente las hacen -cumplen. Los que apoyan o administran los servicios, tampoco, ya que se preocupan por que sus ‘indicadores’ no arrojen resultados negativos. En general, la empresa no entiende lo que es una apropiada gestión de servicios –y este ex alumno me comenta que hay varios certificados en ITIL. Esto último es una mala propaganda y por ello muchas empresas no confían en las buenas prácticas de ITIL (no ahondaré si es la empresa la que ocasiona esto con su cultura o es producto de una adecuada aplicación). Los usuarios utilizan las herramientas principalmente para controlar tickets. Aparte de utilizarla mal, encima desconocen las verdaderas capacidades de la herramienta. Los nuevos usuarios no son capacitados; la capacitación utiliza el método Inca (de boca en boca); y otras situaciones que me enteré. Una pena, por la empresa y por sus clientes –mi opinión, ya que no importa cuán brillante es el producto o si hace mil cosas; si no estamos proporcionando el resultado que el usuario final espera (el valor del servicio que está pagando), estamos fracasando. Una noticia al respecto aquí (ojo, no es la empresa de la que hablo) que generan costos innecesarios de compensación y remediación, querellas judiciales, pago de moras, auditorías inopinadas, pérdida de beneficios, demandas judiciales, entre otros aspectos negativos. No es de extrañar saber de proyectos ‘de éxito reservado’, por asignación inadecuada o inoportuna de recursos, plazos excesivamente agresivos –algunas veces exigidos sin base o beneficio para el negocio, costos subestimados, requisitos olvidados –o mal identificados, complicaciones imprevistas –que no faltan, un mal gobiernos, y los [consabidos y omnipresentes] errores humanos como código defectuoso.

Lo anterior nos hace preguntarnos ¿para qué me servirá aplicar el marco tal o cual? Ojo, aplicar, no imponer. Resulta obvio revisar nuestra necesidad concreta y el enfoque de nuestra necesidad, alternativas –reales- de solución, compromiso con la adopción correctamente elegida, no mero cumplimiento –o moda.

Recordemos que hay una herramienta correcta para cada necesidad, la cual debe utilizarse en el momento preciso y por quien conoce cómo utilizarla –desde la primera vez.

Al igual que con cualquier proyecto, siempre se debe mantener las líneas de comunicación abierta entre las distintas partes, medir y monitorear el progreso de la implementación y buscar ayuda externa si es necesario.

¿Me comentas?