sábado, 7 de junio de 2014

PMO y SMO. Diferencias, Similitudes y Colaboracion !!!


Aprovecho este articulo para transmitir que el pasado 3 de Junio tuve la oportunidad de poder participar como ponente en el IX Congreso Academico Internacional del itSMF,


En esta ocasion en concreto, la tematica del congreso mas alla de Gestion de Servicios TIC y del Gobierno IT, giró en torno a varios pilares claves, como se puede apreciar en la agenda:

- Tendencias (Cloud Computing, Movilidad y Big Data)
- Gestion TI
- Gobierno IT
- Compliance IT
- Legal IT

Personalmente ha sido un placer poder disfrutar tanto de su preparacion como de la realizacion del evento igualmente de forma compartida con todos los profesionales del sectos como con la organizacion del itSMF,

Como en anteriores ocasiones, dejo aqui la presentacion:


sábado, 15 de febrero de 2014

¿Es posible agilizar la Gestion de Servicios TIC?

La respuesta es que SI, claro que SI

Sin embargo, hay que matizar, que agilizar en el sentido de agilidad y no en el sentido de agilismo

En este sentido es mucho mas practico y pragmatico, no caer en los aspectos puramente teoricos de las metodologias agiles SCRUM ni en las buenas practicas de ITIL, sino apoyarse de forma activa en herramientas reales y palpables de mejora continua, como es el caso de los principios de productividad de Lean IT y la orientacion a servicio junto con la gestion conjunta de proyectos y servicios, como es el caso de DevOps

Como ya se indicó anteriormente en este articulo, la Gestion de Servicios TIC, habitualmente en Organizaciones IT con bajo nivel de madurez en la Gestion y Gobierno IT, se suele confundir y se confunde de forma constante con la gestion tecnica del mantenimiento de una u otra determinada tecnologia, ya sean tecnologias de la infraestructuras (incluidas las redes, las comunicaciones, la seguridad y el puesto de trabajo) y/o tecnologias de las aplicaciones (sean de la naturaleza que sean, desarrolladas a medida o personalizadas en base a productos de mercado)

http://4.bp.blogspot.com/-8zuWdIiaMTk/T_-qwbYcFxI/AAAAAAAAADk/dOk70p3MlBw/s1600/IMG+ITIL+y+Desarrollo+SW.jpg

No obstante, la Gestion de Servicios TIC, tiene un alcance mucho mas amplio y con un mayor recorrido ya que va desde la Estrategia, Diseño, Transicion (aqui se mapea con la gestion de proyectos), Operacion hasta la Mejora Continua. Esto sienta las bases para la gestion por procesos y la mejora continua, pero la experiencia nos demuestra que es completamente insuficiente e incapaz en la practica, es decir, que la Gestion de Servicios TIC debe y tiene que verse enriquecida y alimentada si o si con Lean IT y con DevOps

Lean IT en modo resumido nos va a permitir varias mejoras, lo primero de todo poder conocer la voz del cliente (VoC), para asi focalizar todas las actividades en aquello que aporta valor al mismo, lo segundo conocer la realidad visual de los procesos que se ejecutan (VSM), lo tercero depurar el "desperdicio" (waste), es decir lo que no aporta valor, de la ejecucion de los procesos y lo cuarto organizar de forma visual las tareas para una mayor y mejor coordinacion. El mayor reto aqui, no es llevarlo a la practica (que tambien) sino conseguir que la mejora continua se mantenga constante y con el mismo enfasis a lo largo del tiempo



DevOps igualmente en modo resumido, a parte de orientar a toda la Organizacion IT al servicio de forma trasversal, mitigando el pensamiento vertical tan implantado en la practica, va a permitir un ciclo real de mejora continua desde el desarrollo, hasta las operaciones (explotacion), pasando por las Infraestructuras. El principal desafio aqui es que desarrollo entienda y colabore con infraestructuras y operaciones, al mismo tiempo que infraestrucutras y operaciones entiendan y colaboren con desarrollo; creando un circulo de entendimiento permanente en base a la entrega continua-correcta y al feedback continuo-transparente. El mayor desafio aqui, no es llevarlo a la practica (que tambien) sino conseguir que la mejora continua se mantenga constante y con el mismo enfasis a lo largo del tiempo

http://24.media.tumblr.com/4342f297040167e23767677b8f2d1c9c/tumblr_mzlc6tnt881qk741to1_1280.png

Otra variable, menos conocida, pero igualmente efectiva en la practica, es el uso de la Arquitectura Empresarial como facilitador comun y nexo de union en la gestion conjunta de proyectos y servicios, tal y como ya se comentó en este anterior articulo

Queda aparte el Gobierno IT de los Servicios TIC, ya que este articulo se centra unicamente en los aspectos de gestion de los mismos

domingo, 17 de noviembre de 2013

Arquitectura Empresarial: Aspectos clave en la Gestión de Servicios TIC !!!

Habitualmente en las TICs (Tecnologias de la Informacion y Comunicacion), la Arquitectura se ciñe al diseño de los requisitos funcionales y los requisitos no funcionales (es decir tecnológicos), como nexo de union de ambos, tanto en los proyectos (Gestion de Proyectos) como en los Servicios (Gestion  de Servicios).
Sin embargo, en las Organizaciones IT, la importancia y relevancia de la Arquitectura se incrementa ya que el resultado de los proyectos consiste en la puesta en produccion de nuevos servicios, en los cuales es VITAL el cumplimiento de las calidades sistemicas [Manifiestas: Rendimiento, Fiabilidad y Disponibilidad; Operacionales: Manejabilidad, Calidad, Trazabilidad y Seguridad; Evolutivas: Escalabilidad, Flexibilidad, Portabilidad, Reutilidad, Extensibilidad y Mantenibilidad] desde su estrategia y diseño, como posteriormente en su mantenimiento.



No obstante, con la llegada de la Arquitectura Empresarial todo esto se eleva hasta el nivel estrategico [igual que la Oficina de Gestion de Proyectos (PMO) con el porfolio de proyectos y la oficina de Gestion de Servicios (SMO) con el catalogo de servicios] incorporando el diseño de los procesos de negocio.

Actualmente el marco metodologico mas extendido esta basabo en TOGAF, el cual pivota sobre 4 dominios o pilares fundamentales:

Arquitectura del negocio: define la estructura funcional, en términos de sus objetivos estratégicos, capacidades y procesos de negocio
Arquitectura de las aplicaciones: define la integración de las aplicaciones, garantizando su correcta alineación con los procesos de negocio
Arquitectura de los datos: define la integración y consolidación de datos, permitiendo la generación de informes, indicadores y tableros de control
Arquitectura de tecnología: hace referencia a todos los componentes y elementos tecnológicos que soportan los sistemas de información y los medios de comunicación. Estas tecnologías deben garantizar la continuidad del negocio


Mas alla de esto, propone un modelo operativo destino, el cual se puede quedar representado sobre la siguiente imagen:


Como critica constructiva, en el mismo, no aparece en ningun caso ni como funcion ni como proceso, ninguna responsabilidad sobre la estrategia y diseño de los Servicios, es mas, me atreveria a decir que denota su consideracion puramente operacional tanto de la Gestión de Servicios como de la Gestión de TI en general, lo cual es un error tan grave como común el cual ya se indicó en varios articulos anteriores (I y II). Asimismo no considera la Oficina de Gestion de Servicios (SMO) como responsable estrategico del Catalogo de Servicios (el cual es pieza angular de la oferta de la Organizacion IT a Negocio) lo que se hace especialmente critico en el caso concreto del nuevo modelo de entrega de servicios que supone el Cloud Computing en cualquiera de sus modalidades (SaaS, PaaS e IaaS) y tipologías (Publica, Privada e Hibrida).

Actualmente, a dia de hoy, en las Organizaciones IT, los departementos de Arquitectura que han comenzado a realizar de forma gradual y progresiva este enfoque de Arquitectura Empresarial no pasan mas alla que por documentar los procesos de negocio con mayor o menor detalle en relaccion con las aplicaciones. Confiemos que su avance y evolucion, se enfoque desde un punto de vista eminentemente practico, incorporando desde el primer momento en el diseño de los proyectos y de los servicios, los 4 pilares citados anteriormente y no se queden en una mera descripción teorica y/o formal desde el punto de vista documental.

Finalmente, anexo la relación de los errores mas comunes y recurrentes en la Arquitectura Empresarial, aquí.

domingo, 28 de julio de 2013

ERRORES comunes en la Gestion de Servicios TIC !!!

Habitualmente la Gestion de Servicios TIC es una responsabilidad de gestion y de gobierno poco madura en las Organizaciones IT. Sin embargo, aquellas Organizaciones IT que ya han tomado la decision de orientarse a Servicio, han podido constatar como fruto de la experiencia la mayoría de estos errores comunes:

1.- La Gestion Tecnica de Infraestructuras es similar a la Gestion de Servicios. ERROR
La Gestión Técnica de Infraestructuras se ciñe al aspecto tecnico de las areas técnicas tanto en los proyectos como en los servicios.
La Gestion de Servicios se ciñe a los procesos y a los aspectos organizativos que hacen posible la estrategia, el diseño, la entrega, el soporte, el mantenimiento y la evolución de cada uno de los servicios.

2.- La Gestion de Servicios se acota unicamente a las Infraestructuras Tecnológicas (ya sean Infraestructuras de Sistemas, de Comunicaciones o de Seguridad). ERROR
Es posible y de hecho es conocido en el mercado y existen servicios de operación y mantenimiento de aplicaciones (mayormente si son desarrolladas a medida) incluso Servicios Gestionados 24 x 7.

3.- La Gestión de Servicios unicamente compete el nivel operativo de la Organización IT. ERROR
La Gestión de Servicios debe ser el enfoque de la Organización IT y por tanto los servicios deben gestionarse y gobernarse de principio a fin, es decir, desde su Estrategia, Diseño, Transición, Operación hasta su Mejora Continua (Catalogo de Servicios).
Las Organizaciones IT con un alto nivel de madurez realizan una gestion conjunta de proyectos y servicios como detalla aqui.

4.- Que la Organización IT este orientada a servicio, no significa que el soporte, mantenimiento y evolución de su Producción sea un unico servicio. ERROR
La Producción se debe basar en un Catalogo de Servicios siendo responsable la Oficina de Gestion de Servicios (SMO) de su gobierno y un gestor como responsable de servicio por cada uno de los servicios que lo componen. Del mismo modo que hay un unico responsable de cada uno de los proyectos del porfolio de proyectos.

5.- Es lo mismo un Servicio que una Aplicación. ERROR
Un servicio como por ejemplo el correo electrónico normalmente esta formado el 100% de sus componentes por uno o varios productos de mercado bajo el alcance de la Organización IT (tanto su utilidad como su garantia).
Una Aplicación (maxime las desarrolladas a medida) habitualmente están fuera del alcance de la Organización IT tanto su funcionalidad como sus calidades sistémicas (punto critico de las aplicaciones desarrolladas a medida) por lo que es VITAL integrarlas e integrarlas de forma correcta en el Catalogo de Servicios, mediante los roles y responsabilidades adecuados (de ahi la figura de/de los responsable/s de aplicación/es). Por esto la importancia de los requisitos no funcionales como indica aqui.

6.- Orientación a producto del resultado de los Proyectos. ERROR
En las Organizaciones IT, el resultado de los proyectos (ya sean de Desarrollo de Aplicaciones o de Infraestructuras Tecnológicas) son nuevos servicios dentro del Catalogo de Servicios de la misma, es decir, que los proyectos aunque sean gestionados mediante metodologias agiles, esta gestión no es suficiente ya que estas metodologias están orientadas a la generación de producto (utilidad y/o funcionalidad) y por tanto las calidades sistémicas (garantias) permanecen fuera del alcance sin que nadie las gestione con el riesgo que esto supone, como especifica claramente aqui.

Finalmente, animar y apoyar a todas aquellas Organizaciones IT que no esten todavia orientadas a servicio a que lo esten cuanto antes y motivar a aquellas que ya han comenzado el camino (y por tanto han tomado consciencia de la importancia del servicio y de su madurez) ya que la mejora continua es el camino hacia la perfección...