Gestión de Problemas práctica

6

Cuando una organización de TI toma la determinación de apostar por un modelo ITIL en la gestión de sus servicios, casi siempre suele enforcar sus primeros esfuerzos en la gestión de incidencias.  El motivo es claro, es la que proporciona un ROI más rápido, la que menos cambios suele suponer y la que menor resistencia tiene por parte del personal. Es un quick-win claro. Posteriormente se enfoca en los cambios y en la gestión de la configuración. Obtener un catálogo de servicio y controlar la explotación de sus servicios para que no entren en riesgo. Estos procesos ya no son tan fáciles de implantar como la gestión de incidencias, pero sigue siendo alcanzable y relativamente llano el camino. El siguiente paso natural es la gestión de problemas. Aquí es donde muchas organizaciones se quedan y que no consiguen superar. Ya no hay tanta experiencia ni es algo tan natural el hecho de diferenciar problemas de incidencias. Entre la falta de conocimiento del equipo y la poca ganancia que se percibe, al final es fácil que se quede sin implantar.

Pero considero que realmente su implantación no es tan difícil, pero que conviene seguir una serie de pautas o aplicar determinados consejos si no queremos caer en una tarea burocrática que no aporte nada. Este artículo nace de una pregunta que me he encontrado en linkedin a la que dí una breve respuesta. Tras ver la aceptación de la respuesta me decidí a ampliarla un poco más.

Bases de la gestión de problemas

Antes de entrar en materia quiero recalcar unos cuantos aspectos clave en la gestión de problemas, que aunque todos conocemos la definición, no todos lo tienen completamente claro.

Primero de todo es que en la gestión de problemas no sólo se tratan problemas, sino también otros conceptos. Los conceptos que se tratan en la gestión de problemas son:

  • Problema: Técnicamente un problema es una situación que está generando incidencias. Por ejemplo nuestro sistema de gestión de identidades hace caducar las contraseñas a los tres meses, bloqueando la cuenta y obligando a los usuarios a poner una incidencia. Por ejemplo, todos los días entre las 9:00 y las 10:00 suele caerse la conexión a internet. Por ejemplo, si intentamos crear una factura con importe total 0 €, el sistema la graba, pero luego no aparece listada en ningún sitio. Son situaciones en las que sabemos por qué pasa o no lo sabemos, pero que van creando incidencias. Es decir, hay usuarios que notarán que algo no va bien. Hay que distinguir un problema de una incidencia masiva, que no es que cause incidencias, sino que es una única incidencia que aplica a mucha gente.
  • Defecto de software: Un error en un software es un tipo de problema. No es una incidencia. Cada vez que alguien usa el programa y le falla, se genera una incidencia. Por ejemplo, podemos tener un sistema de gestión que al tramitar un expediente de un determinado tipo no nos deja pasar del estado “Pendiente” a “Aprobado”. El usuario tiene que llamar a TI para que ejecuten una instrucción SQL y lo pase a “Aceptado”. Cada vez que llama alguien, tenemos una incidencia, que la resuelve TI. Lo que sucede es que los defectos de software tienen sus propias características que los diferencian del resto de problemas, por lo que algunas organizaciones los tratan como elementos separados. Pero todas las buenas prácticas para la gestión de problemas, aplican a los defectos de software.
  • Causa Raíz: Una causa raíz es el motivo que genera el problema. Por ejemplo, en el caso de las contraseñas que caducan a los tres meses, esa es la causa raíz del problema. En el problema de la conexión a internet que se cae de 9:00 a 10:00 a priori no se conoce la causa raíz, pero al investigar sí que se descubre que debido al elevado tráfico de esa hora, un router se calienta y se cuelga. Posteriormente se reinicia solo y a los 5-10 minutos se recupera la conexión.
  • Solución temporal: Es una solución a una incidencia asociada a un problema. La solución temporal de un problema es la solución que se recomienda aplicar a las incidencias que genera el problema. Por ejemplo la solución temporal al problema de la caída de Internet es reiniciar manualmente el router sin esperar a que se reinicie automáticamente, y así minimizar el tiempo de caída.
  • Error conocido: Un problema para el que se conoce la causa raíz y la solución temporal, es un error conocido. En el caso de la caída de Internet, en el momento que se sabe que se produce por calentamiento del router y se sabe como actuar cuando pasa, ya hablamos de un error conocido.
  • Solución definitiva: Es la solución al problema, que hace que desaparezca y que no se creen nuevas incidencias. Normalmente se trata de un cambio. Por ejemplo, en el caso de las caídas de Internet, la sustitución del router por otro modelo, soluciona el problema de forma definitiva.
  • Pregunta frecuente: Cuando existe un sistema de auto-ayuda o un service desk automatizado es común contar con una parte de preguntas frecuentes o soluciones al usuario. Estas preguntas frecuentes, o FAQ en inglés, incluyen en muchos casos soluciones temporales. Es decir, las soluciones temporales se documentan para ser usadas por el usuario final a modo de FAQ.

Por lo tanto vemos que la complejidad del proceso es superior al de gestión de incidencias, en el que sólo hay incidencias. En la gestión de problemas, hay muchos más elementos a gestionar.

Recomendación 1: Separar la gestión de incidencias de la de problemas

El objetivo de la gestión de incidencias es recuperar el servicio. El de la gestión de problemas es investigar la causa raíz. Esto lleva a un conflicto de intereses en la organización, ya que investigar la causa raíz puede requerir dejar la incidencia activa, lo que va en contra del objetivo de gestión de incidencias.

Si en una organización la gente que realiza la gestión de incidencias es la misma que la que realiza la gestión de problemas, tenderán a priorizar uno de los dos lados. Y normalmente, lo urgente no deja espacio a lo importante, con lo que la gestión de incidencias suele pasar por encima de la de problemas. La de problemas, quedará desatendida. Esto es muy común en las organizaciones de TI en España en donde lo habitual es tener un responsable de explotación o un gestor de servicio en cabeza, pero en los que no se define un gestor de incidencias o de problemas.

Mi recomendación es definir los roles de gestión de incidencias y de problemas y asignarlos a personas diferentes. Cada uno tendrá sus objetivos y velará por ellos. En su trabajo deberán colaborar y “negociar” continuamente, cada uno por sus propios intereses, o los de sus procesos. Esta negociación será el conflicto sano que estamos buscando.

No estoy hablando de tener equipos completos independientes para la gestión de incidencias y de problemas. Estoy hablando de tener una cabeza de ambos procesos independiente, pero el equipo naturalmente será compartido. No obstante cada grupo de soporte, dependiendo de su posición en las capas de soporte, será más afín a incidencias o a problemas. Los niveles más bajos de soporte (call center, CAU, CSU, …) prácticamente no participan en la resolución de problemas, más que en identificarlos. No obstante utilizan todos los productos de la gestión de problemas para poder hacer su trabajo de gestión de incidencias de forma más efectiva. En el otro extremo, las capas más altas de soporte (equipos de desarrollo, administradores, expertos, …) tienen poca dedicación a la resolución de incidencias, y se dedican mucho más a la gestión de problemas. Esto es algo a lo que el gestor de problemas podrá sacar partido, ya que podrá comunicar a los niveles superiores la idea de que mejorando en la gestión de problemas, reducirán la cantidad de incidencias que llegan hasta niveles de soporte elevados. Es decir, a los niveles superiores les interesa documentar soluciones temporales, identificar problemas y difundirlo a los niveles inferiores, para que estos niveles puedan liberarles de gran parte de la carga de gestión de incidencias.

Recomendación 2: Separar los distintos conceptos de la gestión de problemas

Es muy habitual encontrar sistemas de gestión de servicios TI (SGSTI o ITSMS en inglés) en los que existe el concepto de problema, y sirve de cajón de sastre para todo lo que tenga que ver con la gestión de problemas. Yo recomiendo separar, como mínimo, los siguientes conceptos:

  • Problemas
  • Errores conocidos
  • Soluciones temporales

Cada uno tendrá su propio ciclo de vida y objetivos. Los problemas tienen como objetivo, averiguar el “por qué” y dar una o más soluciones temporales. Los errores conocidos tienen por objetivo resolver el problema para siempre. Y las soluciones temporales el difundir a técnicos y usuarios las soluciones a problemas comunes.

Un problema puede resolverse sin llegar a ser error conocido nunca. Y un problema puede llegar a convertirse en más de un error conocido.

Separar los conceptos ayuda a:

  • Que los técnicos entiendan mejor la filosofía que hay detrás del proceso de gestión de problemas, ya que el ciclo de vida de cada pieza es más sencillo que el completo.
  • Que los técnicos estén forzados a seguir el procedimiento, porque tienen que crear distintos elementos.
  • Que la información y estado se difunda de forma más clara.

Recomendación 3: La relación, la base de la información

En la gestión de incidencias podemos sobrevivir sin relacionar elementos. Podemos tener una incidencia que sea duplicada de otra, y  por ende estar relacionadas. Podemos tener incidencias relacionadas con CI o con servicios. Pero podemos sobrevivir sin declarar estas relaciones.

En la gestión de problemas es imposible. Hay que relacionar los distintos elementos de la gestión de problemas entre ellos y con otros elementos externos a la gestión de problemas. A priori considero básico:

  • Problemas -> Errores conocidos
  • Problemas o Errores conocidos -> Soluciones temporales
  • Problemas , Errores conocidos y Soluciones temporales -> Servicios
  • Problemas -> Incidencias
  • Errores conocidos -> Cambios
  • Soluciones temporales -> Incidencias

A nivel personal me gustan las relaciones con significado. Es decir, es importante relacionar una solución temporal con una incidencia, pero es posible que esta relación sea por varios motivos:

  • Porque la incidencia fue la que creó la solución temporal, ya que la solución que se encontró fue la que se decidió aplicar al problema.
  • Porque la incidencia fue resuelta aplicando la solución temporal.
  • Porque la incidencia se intentó resolver, aunque no se consiguió, aplicando la solución temporal.
  • Porque la incidencia se resolvió, en parte, gracias a la solución temporal.

Sinceramente es un gustazo abrir un ITSMS, abrir una solución temporal y ver el histórico de incidencias relacionadas y el tipo de relación. El gestor de problemas puede hacer un gran trabajo con esta información. Sin esta información, el gestor de problemas está ciego.

Para conseguir esto hay que hacer un triple trabajo:

  • Conseguir que nuestro ITSMS disponga de un mecanismo para documentar estas relaciones. Casi todos lo tienen, pero habrá que configurarlo y darle un sentido.
  • Concienciar al personal en documetnar las relaciones: Desde mi experiencia, lo más difícil de conseguir.
  • Automatizar la creación de relaciones: Hay que minimizar la necesidad de crear relaciones a mano. Así si un técnico está mirando una solución mientras documenta una incidencia tiene que tener un mecanismo fácil para decir “he aplicado esta solución” y que se creen las relaciones.

Recomendación 4: La difusión, 50% del trabajo

La gestión de problemas existe para aligerar la gestión de incidencias en dos vías:

  • Reducción del número de incidencias: Si un problema se soluciona definitivamente, se crearán menos incidencias.
  • Reducción del coste de resolución de una incidencia: Si un problema documenta una solución o ayuda a la misma, el coste de resolución se reduce.

Para cumplir el segundo objetivo el personal de la gestión de incidencias  debe estar correctamente informado de los problemas existentes y de las soluciones. Es muy común documentar una solución y que los primeros niveles no la apliquen. Por ello hay que montar algún sistemas que permita a los técnicos de los primeros niveles identificar cuándo se trata del problema y localizar la solución temporal en poco tiempo.

Esto se hace extensible a los usuarios y al sistema de autoayuda. De hecho cuando hay sistema de auto-ayuda es cuando más se saca partido a la gestión de problemas porque conseguirnos:

  • Que la incidencia que sufre el usuario se resuelva sin coste para TI.
  • Que el tiempo de resolución sea mínimo
  • Que el sistema establezca automáticamente todas las relaciones con la acción del usuario.

Para conseguir esta difusión es muy útil clasificar los problemas, errores conocidos y soluciones por servicio de forma que el técnico o incluso el usuario final puedan ver esta información en un cuadro de mando del servicio y que dicho cuadro de mando esté accesible mientras se crea una incidencia.

Es decir, en el momento que creo una incidencia y digo que sobre el servicio de correo electrónico, el técnico debería ver en pantalla un cuadro de mando sobre el servicio de correo electrónico con los problemas que le afectan y las soluciones publicadas. Este cuadro no sólo contendrá la información de gestión de problemas, sino las incidencias y cambios más recientes.

Sin difusión de la información o herramientas que la permitan la gestión de problemas sirve de poco y sus ventajas no superarán a los inconvenientes. Resumiendo, si no hay un mecanismo para difundir la información, olvídate de gestionar problemas.

Recomendación 5: Procedimentar la revisión de incidencias

Uno de los objetivos de la gestión de problemas es identificar problemas. Es decir, si detectamos que cada semana nos llegan unas cuantas incidencias parecidas, es posible que compartan una causa raíz común. Hay dos maneras de hacer esta identificación:

  • Trabajo implícito a los técnicos: Decir a los técnicos que si lo detectan creen un problema.
  • Trabajo explícito de los gestores: Revisar periódicamente la lista de incidencias buscando repeticiones.

Mi recomendación es implantar ambas. Pero raras veces veo que se haga la segunda, la revisión explícita de incidencias.

Recomendación 6: Incluir la aprobación en los ciclos de vida

Sí, sé que suena raro, pero los problemas deben aprobarse. Un problema tiene que tener un ciclo de vida que incluya algo similar a lo siguiente:

  • Propuesto: Alguien ha visto un patrón en incidencias y cree que podría haber un problema.
  • Confirmado: Alguien con capacidad técnica suficiente sobre el servicio (el admin normalmente) confirma que existe el problema. También lo clasifica para apoyar a la decisión de qué hay que investigar.
  • Aprobado: Alguien con autoridad ha autorizado a investigar el problema.
  • Investigando: El problema está en investigación.
  • Resuelto: El problema ya se ha solucionado definitivamente o ha generado uno o más errores conocidos.

De la misma manera los errores conocidos deberá ser aprobados para invertir tiempo en hallar la solución definitiva y aplicarla. Y de la misma manera las soluciones temporales deben aprobarse para que sean la que debe aplicarse en incidencias futuras.

La aprobación de los problemas y errores conocidos debe estar fundada en el impacto de las incidencias que genera, el volumen que genera y el coste que estiman los técnicos en su investigación o resolución. No tiene sentido aplicar criterios de urgencia e impacto para priorizar los problemas o errores conocidos.

Esta aprobación debe ser ágil y en ningún momento convertirse en un retraso. La aprobación permite al gestor mantener el control sobre la gestión de problemas. Pero si el gestor de problemas está saturado, los inconvenientes pueden superar a las ventajas, ya que se convertirán en una carga para el gestor. Debes evaluar si te es rentable o no.

Mi consejo es incluir la etapa de aprobación porque te permitirá enfocar mejor los recursos de tu organización y priorizar mejor los problemas. La gestión de problemas es una asignación de recursos que en muchas ocasiones se realiza a nivel de toda la organización. Así no podemos esperar que sea un grupo de técnicos los que evalúen qué problemas son los más graves o proporcionan más coste a la organización.

Recomendación 7: Mimar de forma especial a los errores de software

Según ITIL los errores de software son problemas. Y de hecho lo son. Pero los errores de software son un nexo de unión con los equipos de desarrollo. Los equipos de desarrollo no suelen estar muy alineados con ITIL. Ellos ven entregas, no ven cambios. Sus prioridades son resolver el error, no resolver la incidencia. Resumiendo: están hechos de otra pasta.

Por lo tanto es habitual que utilicen otros sistemas de gestión y no se sienten cómodos dentro del ITSMS. Si la organización de TI está dominada por el desarrollo de software, el ITSMS escogido no será muy ITIL. Veremos como han cogido un Redmine o un Jira para la gestión. En cambio si la gestión de TI está más orientada a la explotación, veremos un sistema más ITIL, como Remedy, Easy Vista, Service Manager u OTRS. En este segundo caso, los de desarrollo no suelen querer entrar y no es raro ver como ellos quieren utilizar su redmine y que se integren ambos sistemas.

Por ello mi recomendación es no forzar al equipo de desarrollo y no ser tan ITILiano. Perfectamente podemos crear un tipo especial de problema que sea el defecto de software, o bug. Y podemos tener un ciclo de vida que, aunque respete los conceptos básicos de la gestión de problemas, también se adapte a la forma de entender la vida de los desarrolladores.

Por ejemplo, un error de software, según ITIL, primero necesita una solución temporal, antes de una definitiva. Eso obliga al desarrollador a por ejemplo crear un script de SQL que arregle los datos cada vez que salen erróneos en vez de crear un parche que solucione el problema. Para el desarrollador será antinatural eso, y para él lo principal será arreglar el fallo y crear un parche. Muchas veces no lo verán la creación de la solución temporal como responsabilidad suya.

Mi recomendación es que el gestor de problemas tenga especial atención a este tipo de problemas y que sea capaz de encontrar un punto en el que tanto él como la gente de desarrollo se encuentren cómodos. ¡Desde aquí te doy ánimos para conseguirlo!

Comentario: Gestión ágil de problemas

Hoy en día cada vez suena más esto de la gestión de servicios ágil. La gestión de problemas es una pieza angular de la gestión ágil. La gestión ágil de servicios se centra muchas veces en la inter-relación entre los equipos de desarollo y de soporte (como las DevOps por ejemplo). La gestión de problemas, como ya he dicho, es uno de los puntos de unión, por lo que será una de las piezas angulares de la gestión ágil. El proceso de detectar una incidencia, identificar un fallo de software (problema), desarrollo de la solución y aplicar el cambio puede hacerse en menos de un día bajo una gestión ágil y el centro del éxito estará en la gestión de problemas.

Conclusión final

El proceso de gestión de problemas no es tan directo como el de gestión de incidencias o de cambios. El rendimiento de este proceso no es fácil de medir y no es directo. El beneficio repercutirá en la gestión de incidencias, y sólo será así si el proceso realmente se implanta correctamente. Mira mis consejos que nacen más de fracasos que de éxitos y espero que te ayuden a conseguir un proceso de gestión de problemas exitoso.

¿Tienes más consejos? ¿No estás de acuerdo conmigo? ¿Te ha servido lo que he dicho? Por favor, compártelo con nosotros con un comentario.

About author

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y Master in Advanced Studies, pero se ha metido de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert y va en camino de certificarse como PMP. Actualmente trabaja en Idiso, empresa de servicios de distribución hotelera, como responsable de desarrollo y soporte del área de proyectos web e integraciones.

6 comments

  1. Carlos 12 Abril, 2015 at 08:32 Responder

    No estoy deacuerdo con el post. La gestion de incidentes y de problemas estan tan relasionadas que en el fondo son lo mismo. Si dos personas lo llevan solo conseguiras que lo anden todo el dia peleando. A mas si el staff de soporte es compartido. Si lo que prentendes es andarlos a todos peleando, asi lo conseguiras.

    • Jose M. Huerta 12 Abril, 2015 at 09:07 Responder

      Hola Carlos, primero de todo gracias por comentar. Siempre se agradece otro punto de vista.

      Es verdad que es posible que poniendo objetivos diferentes a ambos roles se puede llegar a crear conflicto. Pero creo que si ambos roles son profesionales, no llegará la sangre al rio y se puede mantener un muy buen ambiente de trabajo. Siempre que se comparte un mismo recurso para dos objetivos diferentes se crea un conflicto en una organización. Pero es un conflicto sano que permite mantener ambos objetivos vigilados sin olvidar ninguno de los dos.

      Pero en cualquier caso, gracias por comentar.

  2. Francisco Gamaliel Arias 16 Abril, 2015 at 18:11 Responder

    Excelente aportación José Manuel.

    Ojalá puedas compartir mucha más de tu experiencia para aquellos que vamos empezando en el mundo de ITSM y que nos cuesta aún identificar casos prácticos.

    De forma particular tengo muchos problemas para clarificar algunos temas, ojalá con tu apoyo y guía pueda identificar más fácilmente prácticas en Gestión de Servicios para aportar en el ámbito académico en el que me desenvuelvo una nueva cultura de Administración de Tecnologías de Información.

    Saludos!!

  3. Jorge Carlos Trujillo 10 Marzo, 2017 at 19:06 Responder

    Qué tal José M. Huerta.

    Me da gusto saludarte y felicitarte por tu compartir tu experiencia con el foro.
    Actualmente estoy en el staff del proceso de Gestión de Problemas y quiero expresarte algo que siempre he tratado de entender y desde luego solucionar.
    Sabemos que se pueden implementar SLA tanto para la Gestión de incidentes como para la Gestión de Problemas, pero la gran pregunta es: cuándo aplicar uno y cuándo aplicar el otro en un problema recurrente, me explico:
    Día 1.
    • Se presenta un incidente.
    • Gestión de Incidentes asigna un ticket en la herramienta de Gestión al proveedor de servicios de TI.
    • Se inicia la contabilización del SLA definido.
    • Se inicia el procedimiento de atención por parte del proveedor de servicios.
    • Se reestablece el servicio de TI sin que se haya identificado su causa raíz.
    • Se detiene la contabilización del SLA definido.
    • Por política y mejor práctica de ITSM, Gestión de Problemas registra un problema en la herramienta de gestión con el fin de que se le dé seguimiento al evento y se identifique la causa raíz y su solución permanente.
    • Se inicia la contabilización del SLA definido para el proceso de Gestión de Problemas.
    Día 2.
    • Se presenta nuevamente el mismo incidente.
    • Gestión de Incidentes asigna un ticket en la herramienta de Gestión al proveedor de servicios de TI (este segundo ticket se relaciona con el ticket Padre asignado el día 1)
    La pregunta es:
    ¿Cómo deberán ser manejados todos los tickets subsiguientes???, tendrán que ser con la misma prioridad??? Se cierran y se da seguimiento con el ticket padre??? Se dejan abiertos al igual que el caso padre???? ¿El caso padre se cierra y se relacionan los subsiguientes???
    ¿El SLA de Gestión de Problemas es muy independiente del SLA de Gestión de Incidentes o se tienen que relacionar uno con otro????
    Espero me puedas dar tu opinión.
    Gracias.

    • Jose M. Huerta 25 Marzo, 2017 at 13:20 Responder

      Hola Jorge Carlos,

      Te comento mi punto de vista, y perdona por haber tardado tanto en contestar. La prioridad de una incidencia o su medición de cara a un SLA es independiente de que la incidencia esté relacionada con un problema o no. Con esto, las incidencias deberían abrirse y mantenerse abiertas mientras siga la incidencia. Por ejemplo: Imaginemos que no sabemos por qué pero a veces las cuentas de usuario se bloquean solas. Hay que ir a desbloquearlas desde el LDAP de la empresa. Cada bloqueo debe ser tratado de forma diferente, y hasta que no se desbloquee no podemos cerrarlo. Esto es independiente de la investigación del problema cuyo primer objetivo será definir el workaround (precisamente para asegurar el SLA de las incidencias que vayan surgiendo), y segundo será descubrir el por qué, a fin de determinar cual será la solución a aplicar.
      Así respondiendo directamente a las preguntas:
      – ¿Como deberían ser manejados los tikects subsiguientes? Como incidencias. Relacionadas con el problema, pero sólo a título informativo. El resto es independiente. Recomendación 1: Separar la gestión de incidencias de la de problemas.
      – ¿Tienen que tener la misma prioridad? No. La prioridad de una incidencia se determina por el impacto y urgencia de ella misma, sin contar el resto. La del problema tiene que ver con la prioridad de las incidencias y con la probabilidad de recurrencia. Así es posible tener un problema de prioridad alta que genera incidencias de prioridad baja, pero cientos de ellas. Volvemos a la Recomendación 1.
      – ¿Se dejan abiertos igual que el padre? En absoluto. Las incidencias pueden resolverse antes que el problema. Y también puede ser que el problema resuelto no resuelva las incidencias que ya hayan pasado, sino que evite que se produzcan nuevas.
      – ¿El SLA de Gestión de Problemas es muy independiente del SLA de Gestión de Incidentes o se tienen que relacionar uno con otro? Depende de cada caso. Mi recomendación es separarlos. Son dos cosas diferentes. Pero puede haber organizaciones que relacionen el SLA del problema con la suma de tiempos de las incidencias. Eso tiene sentido cuando el coste del equipo resolutor de las incidencias corre a cuenta de la organización. En ese caso, la resolución del problema impacta en coste, por lo que el SLA del problema debería reflejarlo. Pero claro, es que la prioridad del propio problema ya debería reflejar eso. Un problema que genera cientos de incidencias, debería tener una prioridad alta, y esa prioridad es la que determinaría el SLA.

      Por ultimo añadir que tampoco soy muy fan de los SLA de problemas. Una incidencia, aunque única, es más o menos predecible estadísticamente. Sabes que la mayoría se resuelven en 24 horas por ejemplo y que sólo unas pocas tardan más de 2 días, por ejemplo. Pero los problemas son como agujas en pajares. Hay problemas que con un par de horas de investigación están resueltos y otros que necesitan meses. ¿Cómo puedes medir el buen trabajo del equipo en esos casos? Difícil cuestión.

Post a new comment

Te puede interesar...

EdG: ARGO

Esta es la mejor mala idea que tenemos con diferencia