En ProactivaNET vamos a incorporar a dos personas para cubrir el puesto de técnico de tercera línea de Service Desk para trabajar en nuestras oficinas de Gijón (Asturias). Si cumples con el perfil, envíanos tu cv a rrhh@espiralms.com.

Leer más

ITIL propone que el Service Desk actúe como punto único de contacto para los usuarios. Algunas personas cuestionan este enfoque y sugieren que tener múltiples puntos de contacto es una solución más eficiente. Pero, ¿acaso no están proponiendo lo mismo?

Recientemente he visto varias propuestas para mejorar la propuesta que hace ITIL de articular los Service Desk como un punto único de contacto (SPOC) permitiendo múltiples puntos de contacto (MPOC) según la necesidad que tenga el usuario.

Leer más

Lo que en su momento nos parecía innovador, todo un avance, con el tiempo, acaba volviéndose de lo más cotidiano, o incluso imprescindible, un must-have. Razonamiento aplicable a muchos ámbitos, os cuento mis negativas experiencias como usuario de un Service Desk…

Por una vez me voy a poner del otro lado, y en lugar de estar del lado del Service Desk (técnico, consultor, fabricante de herramientas,… casi siempre estoy del mismo lado), esta vez me toca ser el usuario que llama al Service Desk. ¡¡ Bien !! O quizá no tanto…

Leer más

Muchas veces se confunden y se consideran iguales,  pero lejos de ser lo mismo, los cambios (RFCs) y las solicitudes de cambio no son lo mismo. Sin entrar en grandes tratados ni estudios “ITILicos” detallados, a continuación trataremos de aportar un poco de luz al respecto…

Aunque no me considero ni ejerzo de consultor de procesos ITIL, sí es verdad que mi vida profesional gira en torno al ese marco de gestión de servicios TI, y de la mano de ProactivaNET me toca orientar y asesorar a clientes y potenciales sobre cómo enfocar la implantación de algunos procesos utilizando nuestra herramienta. Uno de los procesos sobre el que más dudas surgen y sobre el que más preguntas recibo es sobre la gestión de cambios,  y al profundizar en el tema,  en muchas ocasiones descubro que realmente estamos hablando de peticiones,  no de cambios.

El proceso de gestión de peticiones es un proceso ejecutado la mayoría de las ocasiones por el Centro de Servicios, típicamente de manera muy cercana al de gestión de incidencias (aunque son cosas totalmente distintas), que recepciona las nuevas solicitudes realizadas por parte de los usuarios finales,  conforme al un catálogo de servicios que deberíamos tener definido y publicado. Las peticiones pueden ser de muchos tipos: peticiones de compra, solicitudes de nuevos servicios, peticiones para adaptar informes, consultas técnicas, resolución de dudas, asesoramiento,… En ningún caso el servicio se ve comprometido (todo debería estar funcionando bien).

Uno de esos tipos de peticiones puede ser precisamente una petición expresa de cambio (por ejemplo en un informe), pero en otras ocasiones una petición podría derivar en un cambio sin que el usuario realmente sea consciente de ello. La solicitud del usuario es el mecanismo por el cual nos piden las cosas, de manera pública, y que puede desencadenar (o no) una RFC en la gestión de cambios, que quizá ya no sea visible para el usuario final,  al ser un proceso interno de las TI.  Es más, en muchas organizaciones las peticiones que derivan un cambio incluso salen del ámbito del Service Desk, pasando a equipos de gestión de proyectos externos gestionados por PMOs (no digo que sea lo más recomendable ni mucho menos, pero la realidad es esa en muchos casos…)

Una regla que ayudará a determinar de qué estamos hablando, podría ser la siguiente:

• Si lo que necesitas es gestionar el flujo de peticiones de cambio por parte de tus usuarios (establecer un mecanismo para que te pidan cosas) , estamos hablando de gestión de peticiones,  no de gestión de cambios (aunque derivado del primero quizá necesites al segundo); muchas peticiones se resolverán sin necesidad de realizar ningún cambio.
• Sí lo que necesitas es gestionar el propio cambio en sí (no tanto la propia solicitud y comunicación con el usuario, si no más bien el “proyecto”) , haya llegado a partir de una petición de usuario o de cualquier otro origen, estamos hablando de gestión de cambios; un volumen importante de cambios vendrán derivados de orígenes muy diversos,  no de ninguna petición del usuario.

Como casi siempre en ITIL, todo es cuestionable y “depende” de cada caso, pero espero que esta sencilla reflexión sirva para sacar de la duda a algún que otro despistado 😉

Jandro Castro.

Leer más

Con esas palabras cerró ayer Ramón Álvarez Veiras, especialista en Comunicaciones y Sistemas del Ayuntamiento de A Coruña, el Desayuno de Trabajo organizado por Aldaba y ProactivaNET en La Coruña.

El desayuno comenzó con la presentación de Javier Iglesias, Responsable de Consultoría Tecnológica de Aldaba Servicios Profesionales, quién centró su discurso en la Continuidad del Negocio. Por su parte, Alejandro Castro, Director Técnico de ProactivaNET, explicó cómo integrar una gestión de servicios TI con una buena monitorización para conseguir un proceso completo. 

Con este evento, Aldaba y ProactivaNET, cumplen con su compromiso de ayudar a las empresas a alinearse a las buenas prácticas, mejorar su gestión de servicios de TI, lograr una buena visibilidad del departamento de TI y garantizar que su organización esté preparada para imprevistos. 

No se pierda los próximos eventos de ProactivaNET.

Mavi Fdez. de Vega, Responsable de Marketing

Leer más

El próximo martes 29 de octubre tendrá lugar en Coruña, un desayuno de trabajo bajo el título “Descubra como gestionar sus servicios de TI y cómo asegurar su negocio ante contingencias”.

El desayuno está organizado por Aldaba y ProactivaNET y con la colaboración del Ayuntamiento de A Coruña que contará en su caso de éxito como mejoraron su gestión de servicios de TI, automatizaron sus procesos, lograron una buena visibilidad del departamento, se alinearon con los objetivos estratégicos y garantizaron que su organización estuviera preparada para imprevistos. 

Descúbralo el martes en este desayuno de trabajo. ¡Regístrese ahora!

Mavi Fdez. de Vega, Responsable de Marketing

Leer más

¿Qué le pasaría al negocio si nuestros servicios de TI se vienen abajo por un desastre? (o incluso no por un desastre, simplemente si dejan de estar disponibles) ¿Podría nuestro negocio seguir funcionando, o deberíamos recuperar a la mayor brevedad una infraestructura mínima y básica que permita seguir con la operación ? Estas, y otras preguntas parecidas son las que nos plantearemos a la hora de construir nuestro Análisis de Impacto del Negocio, y serán la base para construir nuestro Plan de Continuidad para los servicios de TI (comenzando claramente por aquellos de mayor criticidad para el negocio).

Jandro Castro

Leer más

Para proveer servicios el departamento de TI requiere de suministradores externos y de áreas o equipos de trabajo internos. Si quiere pactar un SLA con sus clientes ¿puede asegurar que sus suministradores externos e internos están en condiciones de ayudarle a cumplir ese acuerdo?

Un SLA es un acuerdo que el proveedor de servicios -el departamento de TI- establece con sus clientes (por ejemplo otros departamentos de la organización). Este SLA (Service Level Agreement) detallará para cada servicio y cliente las condiciones de prestación, incluyendo aspectos como los horarios de atención, tiempos de resolución o de primera respuesta, etc. Sin embargo, el departamento de TI presta servicios apoyándose en otras entidades, externas e internas, que deberán ser capaces de participar de manera tal que sea factible cumplir el SLA.

Pensemos por ejemplo que el departamento de TI proporcione un servicio de conectividad de redes y acceso a Internet que se apoya en un proveedor externo que se encarga de garantizar la operación de los routers y demás electrónica de red. Si el departamento de TI pacta un SLA en el que se compromete a que ante una fallo en la conexión de red el servicio se restaura en menos de una hora pero el contrato con el proveedor externo establece que resolverá cualquier incidencia en un máximo de tres horas, ¿cómo podemos garantizar que vamos a cumplir el SLA? Es simplemente imposible y, por tanto, o bien modificamos el SLA o bien modificamos el acuerdo con el proveedor.

Por otra parte el departamento de TI no es un ente único, sino que está formado por distintos equipos de trabajo que interactúan entre sí. Por ejemplo podemos tener un equipo de trabajo que se encargue de atender las incidencias relacionadas con un ERP que se ofrece como servicio. No obstante, este equipo es formalmente un grupo de segunda línea y, por tanto, primero las incidencias son registradas, clasificadas y atendidas en primera línea por personal del Service Desk o Mesa de Ayuda.

Si el SLA pactado con el cliente incluye, por ejemplo, un tiempo de resolución, el compromiso de resolución de la incidencia en el ERP afecta desde que se registra por la primera línea hasta que se resuelve con la colaboración del grupo de segunda línea. Este grupo de segunda línea tiene que comprometerse a participar en la resolución con unas condiciones tales que permitan cumplir el SLA.

El acuerdo con el proveedor externo se denomina según ITIL Underpinning Contract (UC). El acuerdo al que se llega con el grupo de segunda línea para que realice sus actividades se denomina, según ITIL, Operational Level Agreement (OLA).

Antes de pactar un SLA debemos identificar los proveedores externos e internos y acordar con ellos los UC y OLA oportunos. Con los datos de estos UC y OLA tendremos los márgenes reales que podemos acordar en un SLA. La alternativa, si no consideramos los UC y OLA antes de firmar el SLA, es asumir el riesgo de incumplimiento del SLA.

José Luis Fernández Piñero Leer más