La Frontera más peligrosa de la Tecnología

La fronteras más peligrosa y controvertida del mundo tecnológico se encuentra justo en el punto de intersección entre el “Cambio en el Negocio” y el “Negocio Habitual” es decir, el punto exacto en donde los resultados de los proyectos son puestos en operación y donde es transferida la responsabilidad de los resultados del proyecto a los equipos de soporte.

Atendiendo las definiciones de proyecto de la mayoría de las metodologías comúnmente aceptadas por la industria, los proyectos cuando entregan sus resultados (o servicios) transfieren completamente su responsabilidad, pues el equipo de proyecto una vez finalizado este debe extinguirse. Una de las características típicas de un proyecto es que tiene una fecha de inicio y fin definido, otra cosa es que se cumpla, pero una vez se acaba el proyecto se extingue.

Dependiendo de cada metodología existirá un plazo definido durante el cual el equipo de proyecto “convivirá” con los responsables del servicio dentro de una denominada transición, post implantación o “Early Life Support” que intente garantice que todo funciona adecuadamente y no hay problemas pero, no nos equivoquemos el pescado está vendido y el equipo de proyecto lo más habitual es que tenga la cabeza en otro sitio y esté pensando en la ejecución de su próximo otro proyecto, es ley de vida.

Además, seamos honestos, la inmensa mayoría de los proyectos no acaban bien, es decir acaban con importantes daños en el alcance, el presupuesto, el plazo, la calidad, las expectativas, etc. y por tanto los equipos de proyectos están más preocupados de entregar lo que sea y salir huyendo lo más rápidamente posible que de rematar adecuadamente el resultado del proyecto.

Esta es la cusa del enfrentamiento entre ambos mundos, el mundo de la operación diaria, el mundo del Business As usual, y el mundo del “Change the Business”, el mundo del cambio en el negocio, el mundo de la Gestión de Programas (Programme Management) y Proyectos (Project Management)

Si hacemos un ejercicio de asertividad y empatía e imaginamos estar en el rol de un responsable de Servicio o Service Manager, el cual posiblemente habrá logrado con el tiempo estabilizar el servicio no con poco esfuerzo y con mas que otro disgusto, la mera idea de a volver a tener que abrir su entorno de responsabilidad a una nueva funcionalidad o a un nuevo servicio probablemente nos sacuda en forma de escalofrío por todo el cuerpo desde la cabeza a las uñas de los pies.

Entonces, ¿Como podemos ordenamos esta coreografía entre ambos mundos? Pues lo que parece evidente es que el negocio precisa de cambios, está sometido a constantes presiones, abierto a nuevas oportunidades, debe mitigar sus riesgos, mantener rigor normativo y cumplir con la legislación, es decir, vivimos en una época de cambios donde no podemos disfrutar de demasiada tranquilidad respecto ni uso de las tecnologías ni de los procesos de negocio de las organizaciones los cuales siempre tienen que estar potenciados por la mejora continua.

Seguro aquellos lector más tecnológicos ya estarán pensando en que la solución empieza por “Dev” y acaba por “Ops”, acrónimo que se refiere a una metodología de desarrollo de software que se centra en la comunicación, colaboración e integración entre desarrolladores de software y los profesionales de sistemas en las tecnologías de la información (IT) pero ojo, no es esta la solución por si mismo, DevOps puede ser parte de la solución pero fracasa estrepitosamente cuando obvia u olvida a los usuarios afectaos por el cambio que ni son desarrolladores de software ni son profesionales de sistemas TI y a los cuales no involucra en la solución.

Los cambios que se introducen desde el “Change the Business” en el “Run the Business” afectan a grupos de interés muchos mas amplios que los profesionales de uno y otro mundo, los servicios deben conceptuarse desde el origen con una serie de procesos que garantizaran o no una correcta operación en el futuro. Es demasiado frecuente ver servicios en operación que no han tenido en cuenta ni contemplan como atender las incidencias más usuales que generara la nueva aplicación o funcionalidad dejando solo ante el peligro al área de operación y provocando en la mayoría de los casos innumerables problemas durante la operación.

Encuentro en demasiadas ocasiones servicios puestos ya en operación que no cuentan ni han contado jamás con ninguna estrategia de crecimiento, plan de capacidad, estrategia de disponibilidad ni mucho menos un plan de continuidad que siempre y ante la tormenta perfecta ha causado importantes pérdidas económicas a la organización pues los equipos de proyectos en vez de anticiparse a problemas han causado problemas mucho mayores que los que pretendían resolver.  No hay que olvidar que aportar valor a la organización es tanto generarlo como evitar perderlo.

Un panorama desolador en muchas organizaciones donde predominan las entregas incompletas, las soluciones cortoplacistas y las puestas en operación apresuradas cuyo ruido parece justificar “que se hacen cosas” cuando la realidad es que se confunde precipitación con agilidad y ese ruido en la mayoría de las ocasiones es debido a fallos, problemas que evidencia que las cosas posteriormente funcionan mal, se funciona sin estrategia, generando conflictos y problemas innecesarios, definitivamente desgobierno organizacional.

En lo que llevamos de año he llevado a cabo siete intervenciones relacionadas con crear una Cultura As-a-Service que permita a las organización adoptar una estrategia “end to end” de operación y mejora del servicio de manera gil, ordenada, eficaz y con el foco en el valor y en todos los casos el éxito lo han producido dos medidas basadas en el mas absoluto sentido común.

• Gestionar el Servicio como un Programa (Programme Management) y no como un Proyecto (Project Management)
• Formar adecuadamente a Programme Managers y Project Manager en Gestión del Servicio (Service Management)

Lo primero permite a la organización adoptar el enfoque adecuado ya que lo que se pretende conseguir a través del servicio son beneficios y no meramente resultados, es decir usar el modelo de Gestión adecuado, para ello siempre me baso en las metodologías Open Source de la Comisión Europea OpenPM² (PgM) y en la Norma Internacional ISO 21503 para Gestión de Programas y en la Metodología OpenPM² (PjM) y la Norma ISO 21502 para la Gestión de Proyectos.

Lo segundo permite siempre a la organización que todos los profesionales implicados tanto en la estrategia, como en el diseño, la construcción, incluso en las pruebas, por supuesto el despliegue y puesta en operación,  entiendan con rigor y tengan conocimientos suficientes sobre todo aquello que necesita tener un servicio, todo lo que implica, todo lo que hay que tener presente para generar servicios realmente valiosos, resilientes, capaces y disponibles que de verdad aporten valora a la Organización, para lograr en absolutamente todos los casos cuento con la Metodología Open Source de la Comisión Europea de Gestión de Servicios FitSM y la Norma ISO 20000 de Servicios de Tecnologías de la Información

En definitiva, preocúpese de que profesionales proporcionen los conocimientos y las herramientas necesarias a cada uno para que entienda a su vecino, fomente la colaboración, use un idioma común, asese en estándares de código abierto no propietarios, establezca puentes y mejore las relaciones entre ambos mundos que se necesitan y se complementan logrando unirlos alineando la tecnología al negocio y no viceversa.

Como me dijo en una ocasión un director general de una importante organización que citando sus palabras nunca me agradecerá bastante que le ayudara a poner en sintonía su organización con el fin de poder competir en la era digital: Esta tan claro el camino que hasta causa dolor.