Una reflexión sobre servicios y proyectos

La Gestión de Servicios de TI, bajo ITIL o ISO 20000, suele verse como algo ajeno a la Gestión de Proyectos, bajo PMP o ISO 21500. ¿Podemos encontrar algún punto de contacto?

La relación con los clientes de Proactivanet pasa por dos fases tras la compra del producto: un proyecto de implantación (instalación del software, servicios de parametrización, jornadas de formación, etc.) y, posteriormente, un servicio de soporte renovable periódicamente. Estas dos fases suelen verse como totalmente ajenas y se guían por prácticas y marcos de referencia distintos.

En este sentido, como Director de Ingeniería de Procesos de Espiral MS, fabricante de Proactivanet, mi objetivo es reflexionar sobre nuestra organización, procedimientos y procesos para buscar oportunidades de mejora y, por tanto, estoy buscando maneras de alinear estas dos fases con el objetivo de prestar un mejor servicio a nuestros clientes.

Quiero dejar claro que en este artículo sólo comparto una reflexión con los lectores, ni siquiera tengo una propuesta en firme que mostrar a la dirección y resto de departamentos involucrados y, menos aún, una decisión tomada. Permítame que les utilice para “pensar en voz alta” y, si tienen alguna sugerencia u opinión que ofrecer al respecto, estaré encantado de recibirla en los comentarios.

Partamos de la siguiente pregunta: ¿el servicio de soporte puede considerarse como un proyecto? Yo creo que sí porque un proyecto se define por un alcance, un plazo y unos recursos, cosas que también comparte el servicio de soporte que comercializamos.

Pensemos que el servicio de soporte tiene un alcance (existe una definición en el catálogo de servicios), un plazo (habitualmente se contrata con una duración anual) y unos recursos (tiene un coste que debe sufragar básicamente las horas dedicadas por los ingenieros de soporte).

Es cierto que el alcance no tiene unos hitos y entregables específicos y que es más bien reactivo los ingenieros resuelven los tickets que reportan los clientes, pero aún así creo que hay similitudes razonables.

Teniendo en cuenta que en nuestro caso los recursos que se utilizan para prestar el soporte participan también en los proyectos de implantación, existe “competencia entre proyectos” por los recursos y esta competencia debe gestionarse para poder atender las necesidades y compromisos.

La dificultad para gestionar los recursos es que el servicio de soporte es responsabilidad de un departamento que no tiene vinculación con los jefes de proyecto de las implantaciones. Si tiene una organización con una estructura matricial seguro que conoce las dificultades de gestionar equipos de trabajo con dependencias jerárquicas y funcionales distintas.

Creo que una posible solución para esto es que la PMO actúe como gestor centralizado no sólo de los proyectos de implantación, sino también de los servicios de soporte contratados (parece lógico si los consideramos un proyecto) y, por tanto, sea la PMO quien tenga una visión centralizada de los recursos y pueda hacer una gestión que resuelva los conflictos.

Como ya les adelanté en este artículo sólo quería plantear una idea a la que le estoy dando vueltas durante las últimas semanas. ¿En su organización tienen que hacer convivir proyectos convencionales con prestación de servicios dentro de una estructura matricial que obliga a compartir recursos? ¿Cómo lo resuelven? ¿Qué opinan de la idea de acercar ambos mundos bajo la responsabilidad centralizada de la PMO?

José Luis Fernández Piñero