Recientemente me he devorado el libro escrito por Womack, Soluciones Lean. Por qué gestionar incidencias?

En el ámbito de las TI (Tecnologías de la Información) como en muchos otros ámbitos, hemos llegado a dar por sentado que el servicio/producto tendrá fallos y deberemos tener un servicio que nos responda y nos los resuelva. En las organizaciones, gran parte del presupuesto lo dedicamos a resolver gestionar incidencias. Primera referencia necesaria es la de basarnos en las ideas recogidas en ITIL.

Planteamiento generalizado sobre Gestionar Incidencias

Generalmente, existe un proceso de gestión de incidencias en las organizaciones por el que se tramitan todos esos desajustes y errores de usuario. Se tratan de corregir. El objetivo principal es hacerlo en el menor tiempo posible. Correcto.

Suele existir una distribución por niveles, en la que el primer nivel, con un conocimiento limitado de los sistemas y con capacidades limitadas de actuación, dejan a los expertos las actuaciones más complejas. Esto desde que me leí el libro, ya no lo tengo tan claro.

Muchas veces, esta parte de la organización se suele subcontratar. Concretamente la parte del primer nivel (el técnico que nos atiende las llamadas). En estas contrataciones se establecen una serie de SLAs muy orientados al servicio que se subcontrata. Y la empresa proveedora identifica Acuerdos de Nivel de Servicio relacionados con el tiempo de respuesta, llamadas perdidas, horarios… La empresa proveedora trata de dar el mejor servicio que el cliente (en este caso nuestra organización) está solicitando. Pero es este el servicio que realmente necesitamos?

A veces, de cara a ofrecer a nuestros clientes (los usuarios del negocio) el valor del servicio que les damos, solemos trasladar parte de estos Acuerdos, directamente a ellos. Hablándoles sobre tiempos de respuesta ante incidencias, llamadas perdidas…  Esto les aporta algo?

Cuando existen varios proveedores en mantener los sistemas de información, es cuando se complica un poco más el asunto. Cada proveedor dispone de unos SLAs que responden al objetivo de cada necesidad. El servicio de Atención a Usuarios trata de cerrar las incidencias en el menor tiempo posible, el desarrollador no da a basto con las incidencias, y es cuando cada servicio empieza culpar al otro del mal funcionamiento de algo. Cómo hemos llegado a este punto? No habéis vivido algo parecido?

Resumiendo muy mucho los pasos, os podría asegurar que no son pocas las organizaciones públicas y privadas que se encuentran en este punto o puntos parecidos.

Qué ha pasado? Dónde está el fallo de gestionar incidencias?

Creo que el fallo, y en esto coincido con el libro de Womack, está en que nos preocupamos de segmentar el servicio por tratar de ser eficientes y lo que no vemos es el conjunto real de lo que se está pidiendo. Me explico. Dar por sentando que vamos a tener incidencias es el error. Nuestro objetivo debería de ser reducir el número de incidencias.

Es una práctica habitual dividir la gestión de las TI en procesos. De alguna forma tenemos que empezar a organizar el caos, pero lo que hay que tener claro es el objetivo. No aporta valor el resolver incidencias. Lo que realmente aporta es el no tener interrupciones del servicio. Se puede conseguir cero incidencias? Posiblemente no, porque en las organizaciones trabajan personas. Con una capacidad creativa que supera cualquier limite, pero siempre, nuestro objetivo debería de ser tratar de reducir el número.

Cómo reduzco el número de incidencias?

Categorizando las incidencias

No hay que hacer un árbol muy concreto, no hay que acertar a la primera. Tiene que ser una estructura que nos sirva para localizar pautas. Una distribución podría ser:

  • Cuentas de usuario
  • Seguridad
  • Hardware
  • Software
  • Bases de datos

Es esta la mejor categorización? Posiblemente para empezar lo es. Lo que interesa es identificar pautas. Recomiendo un número menor que 6, ya que a los técnicos les va a resultar más fácil empezar a categorizar así.

Identificar pautas y tomar acciones

Está muy bien categorizar, pero lo importante es identificar pautas. Categorizar nos debería permitir ver que ocurre y así poder tomar decisiones al respecto. Que tengo muchos usuarios a los que se les olvida la contraseña en septiembre. Algo deberíamos de hacer.

 Tomar acción: se trata de ser valiente y enfrentarse a la realidad del dato.

Frases como…

  • Eso aquí no lo podemos hacer
  • Cómo vamos a plantear eso?
  • Es que no nos van a hacer caso
  • Si total les dá igual
  • Me estas echando la culpa a mí? (esta es una de las que más se repite y que más odio)

No es cuestión de culpas, generalmente no son errores premeditados, son situaciones en las que hay que tomar acciones. Eso es hacer Lean. Hacer mejoras en base a la experiencia.

 

Podría seguir con pautas hasta escribir un libro… igual me lo planteo 🙂