Twitter ProactivaNET LinkedIn ProactivaNET Vimeo ProactivaNET RSS ProactivaNET Facebook ProactivaNET Youtube ProactivaNET Google+ ProactivaNET

ProactivaNET Blog

Visita el blog de referencia en el mundo de TI, ITSM, ITIL y descubre como aplicar las mejores prácticas a tu organización

En él podrás ver casos de éxito, artículos de opinión, eventos del sector y hasta un glosario de términos ITIL que te ayudarán a ver desde una perspectiva práctica como mejorar la gestión de servicios de TI

7 Nov

La Gestión de Problemas y la mejora continua

La Gestión de problemas es el único proceso que proporciona herramientas específicas para la mejora continua. ¿Pero, si cualquier organización quiere mejorar, por qué es tan difícil implantarlo?

El proceso de Gestión de Problemas es el proceso más específico para la mejora continua que propone ITIL. Es un recurso que se relaciona con muchos otros, como la Gestión de Incidencias, Gestión de Capacidad y Gestión de Cambios. Es un procedimiento clave que formaliza la sistemática de identificar fallos reales o potenciales y materializarlos en oportunidades de mejora.

Un motivo por el cual resulta difícil de implantar, es el que se refiere a toda la variedad de procedimientos con los que debe interaccionar. Por ejemplo:
  • Un análisis reactivo del histórico de incidencias permite identificar patrones de repetición que sugieren la creación de un registro de problema para anular esa repetición.
  • Un análisis proactivo de la evolución de los recursos necesarios para prestar un servicio a partir de los datos, permite identificar tendencias que, si no son corregidas o tenidas en cuenta, terminarán provocando incidencias, lo que también sugiere la creación de un registro de problema.
  • Las revisiones post-implementación de los cambios (PIR) también son otro punto de entrada para el proceso. ¿Qué se podía haber hecho mejor en la gestión de los cambios para ser más efectivos? Por ejemplo añadir más hitos de control o mejorar los planes de comunicación.

Este gran número de interfaces con otros procesos es un motivo de la dificultad para implantar la gestión de proglemas ya que suele haber muchos participantes en todos estos procesos y, por tanto, las responsabilidades terminan diluyéndose. Por esto es fundamental que se establezcan recursos específicos para la Gestión de Problemas que asuman la responsabilidad y el liderazgo en busca de la calidad y la mejora continúa.

El segundo gran problema es que los recursos que se asignan a la gestión de problemas normalmente, son compartidos con otros procesos. Por ejemplo, los técnicos que investigan la causa raíz de un problema suelen ser técnicos de segunda o tercer línea de Gestión de Incidencias. Sin embargo, cuando el corto plazo aprieta -por ejemplo por la gran carga de incidencias existentes-, el medio plazo se ve postergado indefinidamente. Lo urgente (resolver las incidencias) no deja tiempo para lo importante: atajar los problemas. La única medida posible en este punto es intentar asignar recursos propios a la Gestión de Problemas que no se compartan, al menos en su mayoría, con otros procesos. Mientras no contemos con estos recursos que puedan dedicarse prácticamente a la Gestión de Problemas sin especialmente atender tareas de Gestión de Incidencias, la implantación será fallida y no logrará sus objetivos. José Luis Fernández Piñero
Leer más
31 Oct

¿Puedes ofrecer un buen servicio sin gestionar el catálogo?

Image

Con los avances de la ciencia, los procesos de nuestro negocio dependen cada vez más -o incluso totalmente- de la tecnología, lo que hace que los servicios ofrecidos desde TI sean progresivamente más numerosos, más grandes y más complejos, pero sobre todo: más críticos.

Para ofrecer un buen servicio de TI a nuestros usuarios y sustentar los procesos que nuestro negocio requiere, ya no es suficiente con centrarse únicamente en la Gestión de Incidencias o en la Gestión de Peticiones, sino que es necesario contar con otros procesos de apoyo, tales como la gestión de la configuración (CMDB) y, sobre todo, con un buen Catálogo de Servicios.

Nadie duda de la criticidad e importancia que juega la tecnología a día de hoy en nuestras organizaciones. Y es que son pocos los procesos de negocio capaces de ejecutarse sin apoyo explícito de la Gestión de Servicios de TI. Dado que uno de los objetivos de cualquier organización es ir creciendo cada vez más, dichos procesos de negocio también irán en aumento, tanto en número como tamaño. Ello deriva en una colección de servicios de TI cada vez más grandes, cada vez más complejos y cada vez más críticos para el correcto funcionamiento del negocio.

Obviamente, un aumento en la criticidad de un servicio de TI debe venir acompañado -obligatoriamente- de un incremento en la calidad con que se presta. Para ello no basta con centrarse sólo en cómo gestionamos las incidencias o peticiones; debemos ir un paso más allá, analizando su capacidad, su disponibilidad y su continuidad. Todo ello sin olvidarnos de que un buen Catálogo de Servicios y una buena CMDB, funcionarán como “herramientas de apoyo transversales” que darán soporte a todos las anteriores.

Si cada vez nuestros servicios son más y más grandes, es lógico pensar que ya no todo pueda estar en nuestras cabezas, con lo que será imprescindible contar con un repositorio central donde documentarlo todo. Y para eso, nada es mejor que un buen Catálogo de Servicios y una CMDB actualizada: ambos en sintonía, trabajando en conjunto y de la mano.

¿Qué ofrece cada servicio? ¿A quién? ¿Cuándo? ¿Cómo? ¿Con qué niveles de servicio? Parece difícil que en TI podamos tener todo esto en la cabeza, pero más difícil todavía es que los usuarios finales lo entiendan o, por lo menos, tengan un sitio en donde consultarlo. Clarificar al usuario lo que le ofrecemos y cómo se lo ofrecemos, ayudará -sin duda- a que le prestemos un servicio de mayor calidad o, al menos, con menor coste de provisión. El usuario sabrá :

  • Qué se puede pedir: evitando peticiones innecesarias que hacen desperdiciar tiempo y recursos.
  • Cómo pedir: minimizando pérdidas de tiempo y malos entendidos.
  • Qué niveles de servicio puede exigir: evitando prisas o retrasos no justificados.
  • Qué costes tiene lo que pide: pudiendo realizar un primer análisis de coste-beneficio en términos de valor aportado al negocio.

Si conseguimos que el usuario tenga contestación a todas las preguntas anteriores, sin duda, será en una pieza clave en la cadena de provisión del servicio y, sin darse cuenta, se convertirá el primer eslabón en la cadena de calidad.

Jandro Castro
Leer más
23 Oct

Caso de éxito: “Mantequerías Arias”

El “caso de éxito de Mantequerías Arias” -en la aplicación práctica de los procesos de ITIL® dentro de su organización-, fue dado a conocer por primera vez en un seminario organizado en Madrid entre ProactivaNET®, Tecnofor y Mantequerías Arias. En aquel seminario fueron los propios profesionales de la empresa de lácteos quienes lo expusieron de primera mano: todo un ejemplo plenamente en vigor a fecha de hoy.

El Director General de Tecnofor, Marlon Molina, explicó a la audiencia cómo los procesos necesarios en la Gestión de Servicios de TI, de acuerdo con las mejores prácticas recomendadas por ITIL®, aunque independientes, tienen un cierto grado de interrelación, necesario para que todos puedan funcionar de manera óptima. Alejandro Castro, Product Manager de ProactivaNET®, mostró el producto desarrollado para la Gestión de Activos y Recolección de Inventarios, herramienta utilizada por Mantequerías Arias como plataforma para la implantación de los procesos de ITIL® dentro de su organización. Valentín García, Jefe de Sistemas de Información de la empresa, tambien detalló los pormenores del proceso.

Todo ello se puede consultar y descargar -con presentaciones en formato PDF-, en los siguientes enlaces:

Tecnofor ha implantado también una de las soluciones desarrolladas por ProactivaNET®, al objeto de apoyar los procesos de Software Assest Management (SAM).

Leer más
18 Oct

¿Gestión de peticiones sin gestión de seguridad? ¡Error!

Image

Aunque enfocadas para la gestión de servicios de TI, las mejores prácticas ITIL se podrían aplicar a otros muchos ámbitos, como en el ejemplo que veremos a continuación.

Haciendo unas gestiones telefónicas con una importante compañía eléctrica, necesitaba que me facilitasen el duplicado de un contrato del suministro eléctrico, con la peculiaridad de que el contrato no estaba a mi nombre, pero la finca de suministro sí lo estaba. Muy amablemente la señorita tomó todos los datos y, ante mi comentario de que era urgente, se disculpó porque el envío de los duplicados solicitados tardaría unas 3 semanas. Como no podía esperar tanto, decidí acudir in-situ a las oficinas y, cuál fue mi decepción, cuando me confirmaron que, si no era el titular, no podía hacer la gestión: toda una pena.

 Pero lo más gracioso es que la semana pasada -dos meses más tarde- y, para mi asombro, recibí en el correo postal la maravillosa copia del contrato, obviando por completo si éste estaba a mi nombre o no. Sin salir todavía de mi asombro, mi mente “itílica” se llenó de inmediato de infinidad de preguntas:

  •  ¿Por qué el proceso de gestión de peticiones funcionó de manera distinta ante una petición in-situ y la misma petición vía teléfono? ¡Error!
  • ¿Por qué in-situ sí se ha tenido en cuenta la gestión de seguridad y acceso a la información, pero telefónicamente no? ¡Error!
  • ¿Si una petición urgente se tarda en gestionar 2 meses, cuál sería el SLA para una petición no tan urgente? ¡Error!

Sin duda, hay mucho margen de mejora, pero sobre todo, una gran evidencia de cómo los procesos y procedimientos deberían funcionar de manera homogénea y todos ellos conectados entre sí.

¿Imaginas que semejante fallo de seguridad se produjese, en lugar de acceder a un duplicado de contrato, para acceder a un duplicado de una nómina o un historial médico?

Aunque siempre pensemos en ITIL® como mejores prácticas para la gestión de servicios de TI, también es totalmente aplicable para otros muchos otros mundos no tan tecnológicos.

Jandro Castro
Leer más
5 Nov

Un problema no es una incidencia grande

Aunque los nombres puedan llevar a confusión, ni un problema es una incidencia grande, ni tampoco una incidencia resulta complicada de resolver. Quizá sea culpa del uso que damos a las palabras y, muchas veces, llamamos problemas a las incidencias. Pero haciendo gala del lenguaje “ITILico”, lo uno es lo uno y lo otro es lo otro. Sirva el siguiente ejemplo para ilustrar las diferencias.

Como supongo, muchas empresas de hoy en día y tambien ProactivaNET, tenemos alojadas todas nuestras webs con un proveedor externo -supuestamente especializado en el diseño y construcción Web-, con su alojamiento en sistemas redundantes de alta capacidad, máxima escalabilidad, y todas esas cosas que le pediríamos a cualquier proveedor especializado en estos servicios.

Sin embargo, de vez en cuando, las incidencias ocurren. Sí, incidencias, que no necesariamente problemas. Y podría llegar un día en el que, de repente y al entrar en la web, toda la home haya desaparecido (dejemos en el aire la veracidad del suspuesto). Aspectos de seguridad que no vienen ahora al caso, la reacción inmediata es llamar al proveedor y pedirle que, por favor, resuelvan la incidencia -de nuevo incidencia que no necesariamente problema-, a la mayor brevedad posible. Yo me esperaría escuchar como respuesta: “ahora mismo nos ponemos a ello”. Pero sin embargo, la contestación fue: “no sabemos cómo ha ocurrido, vamos a investigar por qué”.

¡Error! Me parece muy bien que quieran saber el porqué, sobre todo para que no vuelva a ocurrir; pero lo urgente ahora (aunque quizá no más importante) sería restaurar el servicio a la mayor brevedad posible. Después y con el servicio restaurado, ya investigaremos por qué, cómo y cuándo.

Es precisamente ahí donde radica una de las diferencias básicas entre la gestión de incidencias y la gestión de problemas: las incidencias se deben centrar en restaurar el servicio de inmediato y lo antes posible y, no enfocándose tanto en el esfuerzo de conocer lo porqués. Es la gestión de problemas la que debe investigar y conocer la causa raíz, para luego proponer los cambios o acciones correctoras oportunas para que no vuelvan a producirse incidencias como la anterior.

Claro está que los tiempos son distintos, porque mientras la gestión de incidencias debe “correr lo máximo posible” para restaurar el servicio cuanto antes, a la gestión de problemas (muchas veces) no le interesa tanta prisa, ya que una vez solucionada la incidencia, no siempre es fácil investigar su causa. Ésta, entre otras muchas, es la razón por la que no siempre es conveniente que los equipos que implementan ambos procesos sean el mismo; así nos evitamos conflictos de intereses, aunque otras veces interese. Pero ese ya es otro tema, en otro día, y en otro post.

Moraleja: ITSM aplica para cualquier proveedor de servicios TI, y da igual si ofreces webs, correo electrónico, alojamiento on-line, o si eres un banco: la gestión de incidencias, la gestión de peticiones, así como el resto de procesos, también aplican para tí. ¿Te imaginas que en lugar de la web de tu empresa, hubieses dejado de ver tu dinero en la banca on-line, y al reclamar al banco, en lugar de resolverlo de inmediato, te dicen que se van a poner a investigar? ¡Yo me hubiese puesto muy nervioso!

Jandro Castro

Leer más
29 Oct

Sistemas de Gestión y software ITSM

Image

Las organizaciones de TI que buscan aportar valor a su negocio implantan metodologías, normas o buenas prácticas que les ayudan a conseguir este objetivo. Un enfoque muy habitual es la implantación de un Sistema de Gestión de Servicios de TI basado en la norma ISO/IEC 20000-1.

Un Sistema de Gestión es una estructura para el tratamiento y la mejora continua de las políticas y los procedimientos que sustentan los procesos de la organización. Una organización de TI implanta la norma ISO/IEC 20000-1 para mejorar los servicios que presta a sus clientes (tanto externos como internos). Pero si quiere poder evidenciar esta implantación hay que superar un proceso de auditoría externa e independiente.

La norma ISO/IEC 20000-1 establece un conjunto de requisitos a cumplir que serán verificados durante la auditoría. La verificación de los requisitos se basa en la búsqueda de evidencias que, resultan más fáciles de proporcionar y tienen más relevancia, cuando son parte consustancial al Sistema de Gestión en base de registros de operación. Por ejemplo, del apartado 8.1 de la norma ISO/IEC 20000-1 se extrae que debe existir un procedimiento para la gestión de incidencias. En una auditoría deberíamos ser capaces de mostrar este procedimiento, así como evidenciar que éste está siendo aplicado en el día a día de la Gestión de Incidencias.

Si la organización de TI utiliza ITSM software se facilita la existencia de evidencias y por tanto la superación de auditorías, pero su mayor beneficio es facilitar el cumplimiento de lo establecido en el Sistema de Gestión de Servicios de TI. Al fin y al cabo, el beneficio de cualquier Sistema de Gestión no debe ser superar una auditoría, sino conseguir los objetivos que pretende para beneficiar al negocio.

Consideremos, por ejemplo, el proceso de Gestión de Incidencias que establece la norma. Deberemos establecer ciertos procedimientos, como el método de priorización de las incidencias. Pero para que las incidencias se prioricen correctamente no basta con definir prioridades (alta, media y baja), ya que el auditor intentará validar que todos los técnicos utilizan el mismo criterio para asignar el valor de prioridad.

En este punto tenemos dos opciones posibles. La primera es definir un procedimiento documentado al que tengan que recurrir los técnicos, lo cual puede dar lugar a errores u olvidos. La segunda, plasmar el criterio de priorización en el ITSM software utilizado como apoyo para la Gestión de Incidencias, de manera que su uso garantice el cumplimiento del criterio por parte de todos los técnicos. Un ejemplo sería cuando la prioridad se asigna automáticamente en base al usuario notificador de la incidencia.

Si el ITSM software utilizado en la organización permite representar en él los requisitos exigidos por la norma y facilitar su uso, de manera que los técnicos no requieran consultar documentos externos ni memorizar criterios para realizar sus tareas. De este modo, no sólo conseguiremos evidencias del cumplimiento de la norma, sino que se simplificará enormemente la operativa del día a día y se hará más evidente el aporte de valor al negocio.

José Luis Fernández

Leer más
23 Oct

CMDB: Objetivo

Una CMDB (Configuration Management Data Base) -por sí sola-, sería como una gran enciclopedia que nadie consulta: no aportaría nada. El objetivo final es que pueda ser consultada, servir de ayuda y dar información al resto de procesos que necesiten conocer cómo se  realiza la Gestión de Servicios de TI.

¿Cuál es el resultado final que buscamos con ella y cuál su objetivo? Visto desde un punto de vista secuencial, el resultado final de una buena CMDB no es más que servir de ayuda al resto de procesos de TI que, a su vez, deberían contribuir a proveer servicios de TI de calidad para poder garantizar que todos los servicios y procesos en nuestra organización funcionan, ayudando a generar más y mejor negocio para nuestra corporación. ¿Fácil, no? Si lo miramos de extremo a extremo, esta herramienta debería ser “algo” que contribuye a generar valor a nuestro negocio y, por el medio, quedaría todo lo demás.

Como cualquier otro proceso, no debemos obsesionarnos por tener la mejor y más grande CMDB desde el primer día, sino más bien todo lo contrario. Deberíamos avanzar paso a paso y poco a poco. Lo ideal sería crear una inicial, que sólo contenga uno o dos servicios que, o bien sean los más críticos para la organización, o bien los que estén causando más problemas.

El paso siguiente es ir modelando dichos servicios sin un excesivo nivel de detalle (controlando sobre todo el nivel de detallado tecnológico). A partir de ahí, en función del retorno o feed-back obtenido por el uso de esa CMDB incipiente, hay que ir haciéndola crecer poco a poco, incluyendo más servicios y ampliando el detalle de la información.

En la situación final está claro que deberíamos tener todos los servicios de nuestro catálogo incorporados, pero antes de llegar a este punto será necesario considerar varios aspectos individualmente de forma que la CMDB crezca controladamente y sin perder de vista su objetivo: ser consultada y dar información útil.

A lo largo de las próximas semanas, iremos desgranando estos aspectos en sucesivos posts.

Alejandro Rayón

Leer más
15 Oct

Gestión de peticiones para todos, no sólo para TI.

No es la primera vez que hablamos sobre la relación de mejores prácticas ITSM en otros sectores no tecnológicos. Y es que está más que claro que, una buena gestión de incidencias o gestión de peticiones, no sólo se aplica a TI, se aplica realmente a cualquier centro de atención a usuarios/clientes.

Y para ejemplo, nada menos tecnológico que una gran superficie de bricolaje a la que vas a comprar material para tus chapuzas domésticas o incluso a pedir presupuestos para una encimera, un armario o muebles para un baño. Pues eso es lo que yo llevo intentando hacer desde hace tres semanas, simplemente pedir una oferta para un vestidor, aunque parece misión imposible: y todo, por no tener una herramienta para gestionar peticiones. Después de explicarle con todo detalle a una amable señorita -durante casi una hora-, qué es lo que necesitaba, ella quedó en llamarme al cabo de 3 ó 4 días.

Pero tras 10 días de espera y al no tener noticias, fui yo quien les llamó telefónicamente. El problema es que no pude hablar con la misma persona que me había atendido el primer día, sólo con una de sus compañeras y, claro, desconocía totalmente mi petición, con lo que no me quedó más remedio que esperar a que estuviese disponible la primera empleada que me atendió. Después de enterarme de cómo funcionaban los turnos de trabajo de este centro, por fin, logré hablar con la chica y conocer de primera mano que no me había llamado, simplemente, porque se le había olvidado tramitar mi petición. Así que, a día de hoy, volvemos a  empezar la espera.

¿No hubiese sido más sencillo anotar mi petición en algún sistema de gestión de peticiones o -en este caso presupuestos-, que tampoco tienen por qué ser tan distintos?

Con esta sencilla práctica se hubiese conseguido:

  • Que nadie se hubiese olvidado de mi petición, ya que el sistema lo recordaría.
  • Que cualquiera de los compañeros de sección podría estar al tanto de la petición y atenderme convenientemente
  • Optimizar el uso de los recursos, ya que cualquier empleado podría atender peticiones de otro compañero.
  • Acortar tiempos de espera y mejorar la satisfacción del cliente, lo que aumentará las probabilidades de venta, y por tanto, aportará valor directo al negocio: se venderá más.

Muchas veces pensamos que ITIL es sólo para TI y, que somos los departamentos TIC los que vamos a la zaga y debemos aprender de otras disciplinas. Pero otras muchas veces no es así y no estaría de más que el resto, mirasen de vez en cuando cómo funcionan los departamentos TI.

Jandro Castro
Leer más
2 Nov

Aplaude los aciertos, celebra los errores

Image

Quien niegue que ha cometido algún error en su vida -sin duda- miente, porque es de humanos equivocarse. Pero el problema no es sólo mentirse a uno mismo, es que además, con ello se están cerrando los ojos hacia un camino de mejora y una puerta que conduce hacia el éxito.

Cierto es que nos da mucha más alegría un acierto que un fracaso y que todos nos sentimos mucho más satisfechos cuando algo sale bien, pero no por ello debemos dar la espalda a los errores. Darse cuenta de un error, de algo que hemos hecho mal, nos hace estar mucho más cerca del camino correcto. De este modo, entre todas las posibles opciones de hacerlo bien, ya estamos más cerca de saber cuál es la acertada. La siguiente vez que debas tomar una decisión similar, sin duda, sabrás por dónde no debes ir, con lo que habrá muchas más posibilidades de acierto.

Los errores no son malos en sí mismos, lo negativo es no reconocerlos cuando se comenten y no darse cuenta de la oportunidad de mejora que se abre ante nuestros ojos. Ser consciente de un error, demuestra que sabes hacia dónde ir, conoces perfectamente lo que quieres y eres capaz de discernir entre lo correcto y lo incorrecto, cuestión que no siempre está tan clara en la cotidiana gestión de problemas.

Por eso, está muy bien aplaudir los aciertos, pero cuando aparecen los errores tampoco nos debiéramos martirizar con ellos, celebrémoslos, porque cada error que cometamos -bien identificado e interiorizado-, nos colocará un paso más cerca del éxito.

Jandro Castro

Leer más
26 Oct

Consejos para empezar a definir una CMDB

Image

La CMDB debe ser un mapa que ayude a relacionar los activos de TI con la capa de negocio de la organización. Pero este mapa no debe ser demasiado detallado o podría resultar inútil. Tiene que tener el tamaño mínimo necesario para que pueda servir de utilidad, de lo contrario su mantenimiento consumiría más esfuerzo del que se necesita.

Para conseguir esto debe hacer un diseño de “arriba” hacia “abajo”, es decir, desde la capa de negocio (los servicios) hasta la capa tecnológica. Por lo tanto se debe comenzar definiendo unos CI que representen los servicios y continuar definiendo los demás CI que sean necesarios para evidenciar los activos tecnológicos que soportan dichos servicios. El punto en el que deba parar de continuar “bajando” es aquel en el que la información que representa ya no aporta nada. Para identificar este punto se pueden valorar tres referencias:

  • Todas las modificaciones de lo que se represente como un CI deben gestionarse como un cambio. Si no se está dispuesto a realizar el esfuerzo de gestionar esa modificación como un cambio, entonces habría que plantearse no incluir esa información como un CI de la CMDB.
  • Se deben incluir sólo los CI que esté seguro que son necesarios. Aquellos que resulten dudosos o que se crea que no hacen falta, no se deben añadir. Siempre se podrá hacerlo más tarde.
  • Muchos CI que representan activos tecnológicos y se necesiten tener en la CMDB, pueden crearse automáticamente desde ProactivaNET Inventario.

A continuación, hay que definir un catálogo de relaciones a utilizar que sea el mínimo necesario para que sea útil. Ejemplos de relaciones son: “contiene” (un servidor contiene carpetas compartidas) y “ejecuta” (un servidor ejecuta una aplicación). Para identificar las relaciones necesarias, la segunda recomendación es que se definan las relaciones a la vez que los CI.

En este punto es fundamental insistir en que la CMDB debe representar lo necesario para organizar la Gestión de Incidencias, Gestión de Peticiones, Gestión de Problemas, Gestión de Cambios y Entregas, de manera que los técnicos tengan claro qué elementos intervienen en la prestación de los servicios. Por lo tanto, el tercer consejo es no limitarse a poner en la CMDB conceptos tangibles (como servidores) porque en la organización hay muchas más cosas que son necesarias para prestar los servicios y que también deberían figurar. Por ejemplo, los CI que representen sistemas de backup relacionados con CI de tipo servidor, base de datos o documentos del sistema de gestión.

Alejandro Rayón
Leer más
18 Oct

La importancia de la certificación de software

PinkVerifyprocess+3

El mundo de las herramientas software para la gestión de servicios de TI (ITSM Software) se ha convertido en un sector con una amplia diversidad, con muchos tipos de aplicaciones disponibles -cada una con sus bondades y defectos-, pero en general, con un elevado grado de calidad y madurez.

Aunque esta calidad y madurez resulta ser tremendamente heterogénea, ya que la creciente demanda de prestación de servicios de calidad hace que el mercado de este tipo de herramientas sea cada vez más amplio y, por lo tanto, cada vez más apetitoso para todo tipo de fabricantes de software.

Esta creciente oferta tiene puntos muy positivos para el usuario y cliente final, pero también puede convertirse en una pequeña trampa si no se sabe distinguir el grano de la paja, o lo que es lo mismo, si no se logran distinguir las aplicaciones contrastadas y específicas para ITSM Software, de las aplicaciones generalistas sin un gran respaldo en el mercado.

Para hacer esa distinción, sin duda, una de las mejores opciones que está al alcance del “comprador” es la certificación de la herramienta, que servirá para hacer un primer filtro inicial: lo certificado vs lo no certificado, permitiendo discriminar aquello que no tiene ningún sello que lo acredite como “ITIL Compliant”. Lo mismo que le pedimos el título de arquitecto a quien nos construya la casa o de doctor a quien nos vaya a operar, tendríamos que pedir el título “itílico” a la herramienta en la que confiemos la implementación de nuestros procesos ITSM.

De entre todas las certificaciones, destacan dos muy por encima de cualquier otra:

  • PinkVERIFY, estándar de facto en el mercado -recientemente avalada por APMG-, que permite certificar un elevado número de procesos como “ITIL Compliant” utilizando como marco de referencia ITIL v3 o incluso la reciente revisión ITIL 2011.
  • ISS (ITIL Software Scheme), aprobación entregada directamente por APMG en representación de The Office Cabinet, que amplia la anterior PinkVERIFY, ya que no sólo se centra en una “revisión teórica”, sino que también revisa escenarios en los que la herramienta se encuentre en producción de manera eficiente en clientes reales (requisito imprescindible para obtener los niveles más alto de aprobación, ISS Gold Level).

Sea cual sea la herramienta que busquemos, ya no sirve con que el fabricante nos asegure su “alineación a ITIL”, será necesario que esa supuesta alineación se garantice con certificados oficiales, PinkVERIFY y/o ITIL Software Scheme.

Jandro Castro

Leer más
11 Nov

Bienvenida

Hola a todos!

Desde aquí nos gustaría manteneros al día en los temas relacionados con la gestión de servicios de TI, ITSM, ITIL, etc, así como eventos del sector. Esperamos que os guste nuestro blog y que nos visitéis a menudo 😉

ProactivaNET Blog es el blog de referencia en el mundo de TI, ITSM, ITIL y descubre como aplicar las mejores prácticas a tu organización

En él podrás ver casos de éxito, artículos de opinión, eventos del sector y hasta un glosario de términos ITIL que te ayudarán a ver desde una perspectiva práctica como mejorar la gestión de servicios de TI

También os ofreceremos frases célebres y motivadoras para que os animen la semana y la lectura del blog os sea más amena.

Un saludo!

Leer más

© 2000-2017 ProactivaNET es un producto de Espiral MS

ESPAÑA · Equipo I+D+i. Espacio Tecnológico Molinón

Tel. (0034) 985 099 215

comercial@proactivanet.com

itil pink verify ITSMF España>
</p>		
</div></div></section>
			
		</div>
	</div>
	
	
		<div id=