Talento Digital
TI

La gestión de proyectos y servicios, ¿mundos paralelos?

Considérese este la parte II del artículo "La evolución de la TI interna", donde se expuso el papel clave de gestionar la demanda de TI centralizada para evaluar: las peticiones del negocio, validar y priorizar las iniciativas que formarán parte del plan de sistemas anual de una organización.

 

En este artículo daremos continuidad a "La Evolución de la TI interna" (publicado el 6 de Abril), el cual trata sobre la gestión de los proyectos derivados de las peticiones demandadas por el negocio que se hayan validado, y su integración con la gestión de servicios. Comentar que la demanda operativa que incluye la gestión de incidencias y peticiones de los servicios en fase de mantenimiento, gestionadas directamente por la oficina de gestión de servicios (SMO) tal y como se puede visualizar en el diagrama adjunto, quedaría fuera del alcance.

Hoy en día es bastante habitual encontrar en las organizaciones una oficina de gestión de proyectos (PMO) que vela por garantizar que los proyectos sigan una metodología común, cumplan unos requisitos de calidad y evitar desviaciones en costes o plazos.

También existen organizaciones que adicionalmente a una PMO tiene una oficina para gestionar los servicios (SMO). Al fin y al cabo los proyectos tienen un inicio, un fin y suelen derivar en un servicio nuevo o en la modificación de uno ya existente. Será en este tipo de organizaciones las que nos vamos a focalizar en el presente artículo, para describir mecanismos de interrelación entre ambas oficinas PMO y SMO con la finalidad de garantizar la coordinación y gestionar eficientemente los proyectos y servicios, a veces “mundos paralelos”.

Ambas oficinas pueden compartir procesos como la gestión de cambios y entregas, haciendo la gestión global más eficiente, facilitando la coordinación. Por ejemplo, podemos definir en el plan de proyecto que en la fase de diseño se convoque un primer CAB (comité validación de cambios) donde el jefe de proyecto expondrá el alcance, beneficios, costes, riesgos y planificación del proyecto recogidos en un Business Case.

En el Comité deberán asistir los responsables de servicio y procesos afectados y se describirán por parte del jefe proyecto los requisitos no funcionales que se deben tener en cuenta en el proyecto. Destacando los requisitos de la gestión del servicio de seguridad, capacidad, disponibilidad, continuidad o requisitos de comunicación/formación o adaptación de la herramienta de itsm para gestionar las incidencias/peticiones que se deriven de la entrega del proyecto. El objetivo de revisar estos requisitos en la fase de diseño es evitar desviaciones en la planificación del proyecto, ya que dejarse fuera algún requisito no funcional puede conllevar en fases más avanzadas incluso rediseñar el servicio con lo que ello puede conllevar a nivel de costes y plazos.

Posteriormente si el proyecto tuviera más de una entrega, se recomienda realizar un segundo CAB antes de las entregas para validar que los requisitos que se describieron en el primer CAB se han considerado y se pueda evidenciar. Esto evitará situaciones como encontrar un proyecto casi a término sin haber realizado la transferencia de conocimientos necesaria al responsable del servicio que mantendrá el servicio una vez entregado el proyecto. O bien desplegar un servicio sin haber antes informado a los stakeholders implicados, entre ellos el service desk de modo que evitemos que les lleguen incidencias relacionadas con el despliegue sin haber sido formado e informado previamente para atender dichas incidencias adecuadamente.

En la fase de diseño del proyecto, para definir los requisitos de capacidad, seguridad, disponibilidad y continuidad se puede apoyar el jefe de proyecto con los responsables de proceso implicados. De igual modo al final del proyecto, tras la entrega, podemos evaluar las incidencias que puedan derivarse apoyándose con el proceso de la gestión de incidencias de modo que consigamos analizar posible el impacto e identificar las mejoras.

Las organizaciones que dispongan de un Sistema de gestión de servicios certificado bajo la norma ISO/IEC 20000, pueden utilizar el punto 5 de la norma (el proceso de diseño y transición) como mecanismos de vinculación entre la PMO y el Sistema de Gestión de servicios.

Apoyándose con la PMO para gestionar los proyectos derivados de altas o bajas de nuevos servicios o modificaciones de alto impacto.

Finalmente mostraré un diagrama que puede ayudar a visualizar la interrelación entre las fases de un proyecto (basándonos en los marcos PMBok ® y Prince2 ®) y los procesos mencionados de la gestión del servicio de ITIL ® e ISO/IEC 20000 . El diagrama muestra también en qué fase del proyecto se debería convocar al CAB para asegurar la coordinación entre la gestión del proyecto y del servicio.

Referencia bibliográfica:

Bauset Carbonell Mª Carmen. “Evolución TI interna”. Parte I del artículo disponible en http:red.computerworld.es/actualidad/la-evolucion-de-la-ti-interna. Fecha publicación 06/04/2016. Último acceso 18/05/2016

 

Mª Carmen Bauset-Carbonell

Doctora Informática por la Universidad Politécnica de Valencia (UPV). Más de 15 años de experiencia laboral en el sector TIC. Desde 2009, Gerente de Servicios TI de INDRA. ITIL Expert (EXIN), auditor y consultor ISO 20000 (EXIN). Profesor acreditado por EXIN. Profesor Master ITIO de la UPV. Microsoft Certified Systems Engineer. Miembro comité AENOR GT25. Alboraya, España.



TE PUEDE INTERESAR...

Revistas Digitales

DealerWorld Digital

 

También es noticia...

snowflake sede EMPRESAS

Documentos Computerworld

Documento Pure Storage y Kyndryl INFRAESTRUCTURAS
Registro:

Eventos: