Causa raíz de fracasos en implantaciones de nuevos Proyectos

Hoy día es difícil encontrar una Organización que no se encuentre en fase de implementar algún proceso organizativo nuevo (ISO 9001, 27001, 20000, 21500, ITIL, LEAN, SIX SIGMA, EFQM...). La lista es interminable.
Todos estas implantaciones suponen una transformación. Un cambio.

En todas las Organizaciones donde he tenido la suerte de colaborar, se han producido procesos de transformaciones y cambios inherentes al sector o a la propia Empresa particular. Como Analista de Negocio me he visto involucrado en las fases Estratégicas, de Diseño y en algunos casos incluso Operativas, y en todas ellas sin excepción me he encontrado con los problemas que son clásicos en este tipo de implantaciones, como resistencias a los cambios, compromiso de la Dirección, etc.

En la mayoría de los casos, nos centramos en esos problemas para resolverlos, sin caer en la cuenta de que son simples manifestaciones de un problema mayor. Síntomas de que algo más profundo ocurre en la organización.

El primer problema raíz del que dependen todos los demás es el relacionado con el estado en que se encuentra la Organización dentro de su ciclo de vida.

Desgraciadamente no se advierte de esta realidad en el PMBOK, en PRINCE2 ni en la ISO 21500.

Por otro lado, el estándar OPM3 desarrollado por el PMI es un modelo de mejores prácticas para evaluar y desarrollar la Madurez de una Organización para gestionar Proyectos específicamente, lo cual no es el objeto de este artículo. Sería otro factor a tener en cuenta pero desde luego eso ya sería para nota. De momento nos conformamos con conocer el nivel de Madurez Empresarial global.

Madurez Empresarial

El elemento que delimita la dificultad que encontraremos en una Organización para implantar un cambio significativo es su Nivel de Madurez (resistencias a los cambios, compromiso real de la Dirección, flujos deficientes de comunicación, escasa calidad de documentación etc)

Para los efectos de este artículo, definiremos cambio significativo como aquel que afecta transversalmente a la casi totalidad de la Organización. Es decir un cambio horizontal, no vertical. Los ejemplos a los que me refería más arriba son todos de este tipo, ya que no afectan a un Departamento o Área Funcional concreta, sino a varios o a todos.

El nivel de Madurez de una Organización es especialmente relevante cuando se trata de implantar un software ERP (SAP, Dynamics, Odoo, etc), ya que un error común es tratar de mejorar la productividad implantando un software de gestión transversal. Un software puede mejorar los flujos de información, así como la calidad e integridad de los datos de toda la Empresa, pero difícilmente mejorará procesos que están mal diseñados o son ineficientes. Eso solo se le ocurre al Comercial que trata de vender el Producto.

Si una Organización funciona con procesos ineficientes, lo único que conseguirá será automatizar la ineficiencia. Al final lo que acaba ocurriendo es que el proceso de implantación se convierte en una tortura y para colmo al final no se cumplen las expectativas planeadas con el ERP.

Cómo evaluar la Madurez

Por tanto, hay que realizar tres pasos fundamentales antes de embarcarse en una operación de cambio transversal importante, y predecir así de forma mucho más aproximada el grado de éxito que tendrá un proceso de implantación transversal y qué tipo de dificultades se encontrarán. Todo lo invertido en estas tres fases será recompensado cuando desarrollemos el Proyecto de implantación del nuevo modelo organizativo (ISO, ERP, etc)

1. Identificar todos los Procesos que se llevan a cabo en la Organización. Para ello es fundamental contar con un Mapa de los Procesos de la Empresa (Financiero, Comercial, Compras, Fabricación, Calidad, etc).
   Los procesos deben tener definida su Misión, Alcance, Inputs, Outputs, Propietarios, Indicadores y vinculación a los procedimientos documentados relacionados. Aquí tienes un ejemplo perfecto.
   Puedes descargarte una magnífica Guía Completa editada por el Instituto Andaluz de Tecnología aquí. En su página 46 tienes otro ejemplo de Ficha de Proceso, y en la 102 tienes un ejemplo del Mapa de todos los Procesos del IAT.
   
   
2. Realizar una evaluación objetiva del Nivel de Madurez de la Organización y sus Procesos.
   Existen muchos modelos de Assesment (evaluación) que nos ayudan a medirlo. Personalmente he utilizado 4 en mi experiencia profesional:

• PEMM: Desarrollado por Michael Hammer y publicado por Harvard Business Review en 2007. Consiste en dos tablas donde se indica el nivel Muy Bajo, Bajo, Medio y Alto de 4 indicadores básicos (Liderazgo, Cultura, Experiencia, Gobernanza), así como de 5 indicadores básicos sobre los procesos (Diseño, Responsable, Propietario, Infraestructura y Métricas).
• CMM: Originalmente diseñado para Empresas desarrolladoras de software, es perfectamente aplicables a cualquier tipo de Industria y Organizaciones.
• TOGAF: Orientado a Empresas relacionadas con Tecnologías de Información, pero perfectamente útil para el resto.
• LEAN Assesment Tool orientado a Organizaciones que han implantado o pretenden implantar el modelo de gestión LEAN.
  
  
  Los he utilizado indistintamente a lo largo de mi carrera profesional, en ocasiones más de uno a la vez, ayudado por una Consultoría externa de apoyo, en función de particularidades como magnitud de la Organización y del cambio a implementar, número de trabajadores o distancia geográfica entre sedes.
  
  
  Para obtener las puntuaciones, la metodología más lógica es realizar entrevistas con mayoría de preguntas indirectas a los mandos intermedios, así como a diversos trabajadores claves y también recién incorporados. Además es posible que sea necesario revisar documentación de procedimientos y de carácter estratégico.
  Esta evaluación la puede realizar personal de la propia Empresa (Oficina de Proyectos o Área de Calidad) o encargarse a alguna Consultoría Externa como ATAI Consulting a quienes conozco y son bastante expertos. Es importante que los evaluadores sean objetivos y no se sientan presionados por ningún entrevistado ni por la Dirección. Mientras más realistas sean los resultados, más fiable será esta evaluación.
  
  
  Los propietarios de Empresas o Consejos de Administración deberían obligar a los CEOs a realizar al menos una de ellas como mínimo de forma bienal.

3. Revisar los indicadores que se encuentran por debajo del nivel 2 y ejecutar un plan de mejora que puede incluir talleres, formación, mejora en documentación e incluso rediseño completo, con idea de incrementar los niveles afectados antes de pasar a implementar un cambio significativo.

El Nivel de Madurez de Procesos más bajo aceptable para minimizar los riesgos de fracaso en Proyectos de implementación de procesos transversales significativos es de 2  en las evaluaciones PEMM o CMM, en el 100% de los Procesos, o una calificación similar en cualquier otro modelo de Assessment. Con similar me refiero a:

• Los procesos de la Organización deben estar definidos, documentados, gestionados y medidos. 
• La documentación debe ser sencilla de leer y estar a disposición de todos los interesados (stakeholders)
• Debe existir un procedimiento bien documentado de solicitud e implantaciones de cambios a disposición de toda la Organización.
  
  
  Una "prueba de algodón" de que un proceso cumple estos requisitos, es poner a una persona que se acaba de incorporar a la Organización y pedirle que lea la documentación que le corresponde y a continuación la explique y diga con sus palabras como funciona ese proceso. Si tiene dudas, hay que revisar la documentación.
  Estar certificado en la ISO 9001 o similares no garantiza que los procesos cumplan esos requisitos. He visto procedimientos que eran jeroglíficos en Empresas certificadas.

En relación al Nivel de Madurez Empresarial, el nivel más bajo aceptable debe ser también de 2 en la evaluación PEMM o similar.

Relación entre la Madurez Empresarial y el éxito de un Proyecto

Aquí es muy importante no engañarnos a nosotros mismos con tal de comenzar el Proyecto de Implantación lo antes posible. Las consecuencias serían terribles a nivel de plazos y costes. Por ejemplo la implantación de un nuevo ERP no debería comenzar jamás antes de que todos los procesos de la Empresa se encuentren en un nivel 3 PEMM o CMM de madurez.

El porcentaje de éxito en la implantación de un nuevo proceso transversal es directamente proporcional a su grado de madurez e inversamente proporcional a los riesgos.

Es a partir de conocer el Nivel de Madurez cuando se pueden plantear determinadas implantaciones que supongan cambios significativos o descartarlos hasta alcanzar el que se considere adecuado.

Sé que este importante paso previo a cualquier implantación es casi una utopía en la inmensa mayoría de las Organizaciones. La Dirección suele hacer caso omiso a este tipo de advertencias porque considera que no es necesaria tanta complejidad, y se lanza al Proceso de implantación de un nuevo Proceso, ERP o Certificado de Calidad acuciado por los clientes o el Mercado y encomendándose a la sencillez que le trasladan los Comerciales de Marketing del proveedor o Consultoría con interés en vender la implantación.

Pero al menos que nuestra recomendación quede por escrito y sirva para no repetir el mismo error más de una vez.

¿Se puede aplicar realmente ITIL en una PYME?

Directores y Técnicos que se han formado o hasta certificado en ITIL olvidan sus principios a las pocas semanas ante la imposibilidad de aplicación en sus Departamentos, o simplemente por aplazarla hasta llegar a olvidar qué aspectos podrían mejorar en sus servicios de Soporte utilizando estas Mejores Prácticas.
Los cientos de certificados que se expiden anualmente en España, no se corresponden con el número de Empresas donde se aplica. Las razones suelen ser una o varias de las siguientes:

1. Demasiadas urgencias que aplazan su planificación e implantación

2. Dirección no convencida de su utilidad y poco proclive a apoyar en la práctica su implantación.

3. Efecto parálisis por análisis. ITIL ofrece tantas posibilidades que no se sabe por donde empezar y se aplaza eternamente, hasta que se olvidan sus conceptos.

Yo mismo he sufrido las 3 alguna vez durante mis 25 años de Dirección de Equipos de IT, En muchas ocasiones donde se primaba por las Direcciones el mantener profesionales certificados con objeto de ganar concursos de adjudicación de Proyectos y nada más.

Donde mejor podemos comprobar implantaciones de ITIL adecuadas es en los equipos de soporte de empresas fuertemente tecnológicas como DELL, HP, APPLE o Microsoft, cuyo nivel de madurez en atención a usuarios está muy por delante del resto, que continúan utilizando metodologías obsoletas de resolución de incidencias.

Y eso que los principios de ITIL pueden aplicarse en cualquier Empresa o Departamento que preste servicios internos o externos, estén relacionados o no con Sistemas de Información. La hoja de ruta, según el marco ITIL, consiste primero  en definir la Estrategia con la que orientaremos nuestros servicios, después realizaremos el Diseño que utilizaremos para llevarlos a cabo, y a continuación definiremos la táctica (Transición/Gestión de Cambios y las Operaciones para llevarlos a cabo). Todos estos pasos son susceptibles de mejorarse mediante el Proceso de Mejora Continua.

La aplicación de ITIL en las empresas españolas aparte de escasa, es bastante deficiente, al menos desde la experiencia de usuario: Sólo hay que llamar a cualquiera de las 3 operadoras de Telecomunicaciones más importantes de España para reportar cualquier incidencia y comprobaremos como tendremos que hablar primero con un contestador automatizado de opciones, y luego hasta con 3 técnicos de nivel 1, sin que se escale al siguiente nivel hasta hacernos perder 20 o 30 minutos. En todas las interacciones deberemos indicar nuestro problema desde cero, una y otra vez.

Si la llamada se corta y volvemos a llamar, comenzamos desde cero de nuevo.

Este escenario español se salta el principio fundamental de ITIL, que se basa en la satisfacción del cliente/usuario, y no en el interés particular de la Empresa de Servicios de que no agobien de llamadas a su reducido número de especialistas de Soporte, poniendo barreras de contestadores automáticos IVR  y personal sin cualificación 

Es importante recordar que ITIL es un conjunto de Mejores Prácticas y que puede ser implantado parcialmente, no necesariamente como un todo, dependiendo de las dimensiones de la Empresa, el Departamento de IT, el número de Clientes/Usuarios y el número de Servicios soportados.

En los equipos de soporte IT que he dirigido, nuestra implantación progresiva mientras manteníamos temporalmente el modelo anterior, fue así:

1º Definición del Portfolio y del Catálogo de Servicios (Estrategia y Diseño del Servicio)

Dejar bien claro por escrito a disposición de la Dirección y de los técnicos de IT, cuáles son exactamente los servicios que se atenderán por mucha presión que se reciba (nada de softwares sin licencia, portátiles personales de usuarios, etc) En caso de intentos de colarnos servicios no soportados, los técnicos deben escalar el caso  a la Dirección IT y comprobar si se pueden soportar e incluir en el Catálogo o rechazar "amablemente"

2º Definición de Niveles de Servicio (SLA). (Diseño del Servicio)

Dejar bien claro por escrito a disposición de cada Empresa o cada Departamentos internos afectados cuáles son exactamente los servicios que se atenderán. Es posible agrupar clientes y Departamentos en un mismo SLA, típico y por tanto mantener un número reducido de ellos.

En Departamentos de IT internos, no es necesaria la firma de aceptación del resto de Departamentos, si obtenemos la del Director General o del Comité de Dirección. Tampoco hace falta incluir penalizaciones ya que los servicios no tienen coste directo.

(Es interesante incluir en los mensajes de cierre de incidencias un coste "virtual" del servicio según los minutos empleados, para concienciar a los usuarios de que no es gratuito e inducirles así a no abrir incidencias indiscriminadamente sin reiniciar antes sus equipos, por ejemplo).

3º Definir el proceso de Gestión de Incidencias y Problemas y definir los roles de sus gestores.(Operación del Servicio)

Diferenciar las Incidencias de los Problemas es el paso más importante de la gestión del Departamento de IT. Todos los mensajes que se reciban son incidencias por definición y la misión nº 1 del equipo es cerrarlas cuanto antes. Para ello hay que reparar el fallo o avería como prioridad principal, o bien utilizar un "parche" que permita seguir trabajando al usuario mediante una solución alternativa temporal mientras hallamos la causa de su incidencia (por ejemplo sustituyendo su ordenador por otro mientras reparamos el suyo).

Esos cierres de incidencia con "parches" temporales dan lugar a la apertura de un Problema por el gestor de incidencias que debe ser resuelto, ya con menor urgencia, por el gestor de problemas.

Lógicamente, para poder soportar este modelo, es necesario disponer de alternativas, como por ejemplo:

- Dispositivos de repuesto

- Contratos de mantenimiento externos

- Base de Datos de Conocimiento (Transición del Servicio) o de Errores Conocidos (Operación del Servicio)

Un error común es confundir al gestor de Problemas con el gestor de Incidencias de nivel 2. Las incidencias no se escalan a Problemas sino que se cierran adecuadamente o con un "parche". En ambos casos se cierran, pero en el segundo además se abre un Problema, que es una criatura completamente distinta (su resolución no es urgente, puede suspenderse hasta la mejora de versión del recurso, etc). Las incidencias y los problemas pueden tener gestores de varios niveles, en función a la especialización que requiera cada servicio,

Otro error común es pensar que cada rol es un individuo diferente. Por el contrario, una misma persona puede ejercer varios roles, aunque es cierto que algunos roles no es aconsejable que recaigan en la misma persona.

3º b. Considerar las peticiones igual que las incidencias. 

Aunque la resolución de incidencias debe ser prioritaria, en la práctica las peticiones pueden simplificarse gestionándolas de la misma manera y por los mismos roles.

4º Externalizar el soporte externo para los recursos clave.

Muchos Departamentos de IT cometen el error de tratar de arreglarlo todo ellos solos. Intentan formarse o certificarse en tecnologías tan dispares como servidores HP iLO, Windows Server, SAP o Navision, Project, etc, 

A medio plazo la actualización de conocimientos y la especialización es inviable y acaba generando el fracaso del equipo de soporte, o el sobredimensionamiento de profesionales en nómina.

Una opción mucho más viable y sencilla es contratar el soporte de cada recurso que requiera especialización o que sea clave para el Negocio.

Lo sé, Esto convierte al equipo de Soporte en un Service Desk de gestores de tráfico que se encarga de dirigir cada incidencia o petición al servicio externo que corresponda. Y...?

Siempre me gusta poner a mis equipos el ejemplo de un Controlador Aéreo, que es capaz de gestionar todo el tráfico del aeropuerto y las comunicaciones con los pilotos teniendo a su disposición los equipos necesarios de controladores de torre, "aparca-aviones", conductores de escaleras, camionetas encargadas del equipaje, etc, sin tener que bajar ellos mismos a pista a hacer todos esos trabajos.

5º Service Desk

Con las definiciones anteriores preparadas, es importante tener en cuenta lo siguiente para poner en marcha un CAU (Centro de Atención a Usuarios):

- Disponer de una herramienta de gestión de tickets (peticiones e incidencias). Si es un software específico como ManageEngine, mejor. Si no, una base de datos ACCESS o una hoja EXCEL. Lo que sea, pero hay que llevar un registro de tickets.

- Disponer de los procedimientos de resolución de incidencias y problemas bien documentados, y en formato de listado de pasos uno a uno.

- Disponer de Check-Lists de comprobación de incidencias, problemas e incluso peticiones, para evitar olvidos y garantizar la estandarizacicón en la resolución por parte de todo el equipo.

- En Departamentos de IT internos, a partir de un número de usuarios superior a 20 o 30 es imprescindible evitar la atención telefónica o presencial sustituyéndola por e-mails o por un software de tickets. De esta forma, es el mismo usuario quien abre la incidencia o petición mediante su mensaje y se evita el mayor ladrón de tiempo del Planeta: el teléfono.

- Si el Service Desk va a dar soporte a Clientes externos vía telefónica, hay que tenerlo en cuenta durante el Diseño del Servicio para dimensionar adecuadamente la infraestructura y el SLA en relación a horarios de atención y por supuesto al precio.

Es posible ampliar la implantación ITIL hasta toda la extensión que define el modelo, aunque son muy pocas las Empresas en el Mundo que llegan a ese nivel, ya que la metodología abarca prácticamente todas las posibilidades necesarias para cualquier Empresa de cualquier servicio en el mundo, (tanto de Sistemas de Información como otros, insisto), Sin embargo rara vez encontraremos una Empresa donde se necesite implantar todo el modelo.

Si somos capaces de arrancar con estos mínimos, en el plazo de 6 meses tendremos una implantación ITIL básica pero eficiente, que podemos ir actualizando y perfeccionando con ayuda de todos los integrantes del equipo de IT, en base a la experiencia diaria, dando así sentido al proceso de Mejora Continua.

Francisco Navarro

ITIL v4 Foundation Certificated
ITIL v2011 Foundation Certificated
ITIL v2011 Service Operation Certificated