Otra forma de medir, los percentiles

Los que somos padres alguna vez nos hemos preocupado por los famosos percentiles en los que habitualmente  los pediatras "enmarcan" a nuestros hijos. Imaginemos la siguiente conversación:

- Pediatra: Su hijo está en el percentil 42 de talla". 
- Padres: ¿Y eso que quiere decir? ¿Nuestro hijo va a ser bajito? 
- Pediatra: No, lo que significa es que 42 de cada 100 niños son más bajitos que el suyo.
- Padres: Buff, que susto!


El pediatra tranquiliza a los padres comentando que cualquier percentil ya sea alto o bajo no es preocupante a menos que este por debajo o por encima de unos criterios establecidos.

No, no voy a cambiar el contenido de Traicionando ITIL, pero la introducción me parece adecuada para hablar de otra forma de medir los resultados del trabajo realizado, los percentiles. Estos se consideran como una medida de posición no central, es decir permiten conocer puntos característicos de una distribución que no son los valores centrales. Los percentiles ponen a nuestra disposición unos resultados distintos a las tan frecuentemente utilizadas "medias".

¿Por qué utilizar los percentiles? En diversos proyectos en los que he participado existían una cantidad ingente de mediciones y muchas de ellas basadas en medias, especialmente aquellas relativas a tiempos. Tiempo medio de solución, tiempo medio de respuesta, tiempo medio de llamada,etc... Por ejemplo: el tiempo medio de solución de las incidencias del mes es de 6 horas. Dependiendo de los objetivos establecidos este tiempo puede ser alto, bajo o todo lo contrario. Sin embargo alguna vez ocurre que los datos no coinciden con la percepción que tiene el usuario, es en ese momento en el que hay que desconfiar de la media.

Como siempre voy a intentar explicar el objetivo a través de un ejemplo práctico. Dada la siguiente tabla en la que se muestran una relación de incidencias con su tiempo de solución, el valor del tiempo medio resultante es 1,76.

Supongamos que el tiempo medio establecido como indicador contractual es 2, a pesar de que el resultado esta en "verde", una serie de usuarios consideran que los tiempos de solución son demasiado elevados. Si calculamos cuál es el percentil que supone el valor 2 para esta serie de datos obtendremos un 73,60%, lo que quiere decir que mas de un 25% de las incidencias relacionadas han superado el umbral establecido como tiempo de solución.

¿A pesar del cumplimiento del indicador, se está dando un buen servicio? ¿Que opináis?

Alberto Álvarez Álvarez


PD. En el apartado "Enlaces de interés" hemos añadido el blog de Oscar Corbelli, sencillamente, un maestro!!!

Congreso anual itSMF

El pasado lunes y martes tuvo lugar el congreso anual del itSMF España, itgsmVision11. Este año ha sido celebrado junto con ISACA. En el día de hoy dejo un lado los post sobre ITIL para transmitir mi mas sincera enhorabuena a toda la organización del evento. Las diversas ponencias a las que he podido asistir han resultado muy enriquecedoras y conferencias de este tipo resultan un oasis en medio de la vorágine del día a día. Seguir así.

Os animo a que dejéis vuestra opinión sobre el congreso.

Alberto Álvarez Álvarez

Arboles de decisión, que solución adoptar. (y II)

En el post anterior se iniciaba el desarrollo de un modelo de predicción para encontrar cual es la solución más viable en la situación expuesta, un árbol de decisión. Debido a problemas presupuestarios una organización tiene que enfrentarse un año más a la imposibilidad de llevar a cabo un "plan renove" en su parque de pc's. Con estas premisas se barajan tres posibles soluciones para intentar mitigar el crecimiento de incidencias de lentitud en los puestos de trabajo del usuario final.

Una vez se ha elaborado la matriz el siguiente paso es dibujar el árbol de decisión. Según los datos previos el resultado obtenido es el siguiente:

Paso a paso:

• Dibujamos un árbol con tres ramas principales: Reinstalación, + Memoria y + Disco Duro.
• De cada una de ellas salen otras 3. Cada una de ellas representa la probabilidad y el impacto económico reflejado en la matriz.
• Por último hay que calcular el valor para cada rama principal, el número destacado en rojo. La fórmula es bien sencilla. Reinstalación = (0.4*120) + (0.5*90) + (0.1*3) = 96.

Una vez obtenidos los valores para las tres ramas principales la decisión adecuada es la de mayor peso, para el ejemplo que hemos seguido la Ampliación de memoria parece ser la solución a adoptar. De todas formas hay que dejar bien claro que cualquier método que se utilice para la ayuda a la toma de decisiones no es más que eso, una ayuda. El conocimiento del entorno y las posibilidades y el sentido común, pueden hacer variar el resultado obtenido.

¿En algún examen ITIL os habéis encontrado con algún supuesto en el que se pudiera aplicar este método?

¿ Creéis que en los cursos de preparación para obtener la certificación ITIL, deberían aparecer más ejemplos de este tipo?

Alberto Álvarez Álvarez

Arboles de decisión, que solución adoptar. (I)

Continuamente estamos hablando sobre como el departamento TI puede aportar valor al negocio. Sin ir más lejos el congreso anual del itSMF España este año tiene como título "Integrándonos con el negocio", definitivamente estoy convencido que desde TI si se puede aportar valor al negocio. El post de hoy es el primero de una miniserie sobre como tomar decisiones basadas en un modelo de predicción, los árboles de decisión. Enmarcados en las matemáticas discretas sus aplicaciones abarcan ámbitos tan variopintos como puede ser el de la inteligencia artificial o la economía, y por qué no también el de la gestión de servicios TI. Traicionando ITIL, nace con una vocación eminentemente práctica a si que me voy a saltar la parte teórica y entraré directamente a compartir un posible uso como herramienta de ayuda en la toma de decisiones.

Antes de dibujar un árbol y evaluar su resultado lo primero de todo es describir cuál es el problema e identificar detalladamente todas las alternativas. Os propongo tomar como base el siguiente supuesto (o quizás no es tan supuesto):

Tras un largo período en el que debido a un recorte de presupuesto (seguro que os suena ¿verdad?) no se han podido renovar los pc's, desde Gestión de Problemas y a través de un Informe de Tendencias se ha detectado que existe un incremento en el número de incidencias en los puestos de los usuarios, "mi pc es muy lento". Como sigue habiendo problemas económicos se sabe que la alternativa de un "plan-renove" es inviable. Antes de emitir un informe definitivo sobre la situación hay que evaluar que decisión tomar dentro de las posibilidades existentes, siempre intentando incurrir en el menor coste posible.

Con un presupuesto tan limitado solo se han podido identificar tres posibles soluciones:

• Formateo y re-instalación de los pc's afectados.
• Ampliación de memoria.
• Cambio de disco duro.

La elección correcta depende de la probabilidad de éxito en la mitigación del tipo de incidencia comentado y se ha decidido asignar un porcentaje como el siguiente:

• Probabilidad alta de éxito 40%.
• Probabilidad media de éxito 50%.
• Probabilidad baja de éxito 10%.

Con la ayuda de la Gestión Financiera se ha evaluado una matriz de beneficios que detalla el análisis de costes para las acciones mencionadas. El resultado obtenido es el siguiente:

En el próximo post se verá como aplicar la información disponible a un árbol de decisión para su posterior evaluación.

Incidencias vs Peticiones. ¿Qué tiene mayor prioridad?

Que yo sepa ITIL no aclara esta cuestión y antes o después suele surgir en el trabajo diario de las organizaciones de soporte. La teoría dice que una incidencia siempre es mucho más urgente que una petición de servicio debido a que estas últimas se suelen relacionar con acciones panificables. Como siempre digo la teoría lo soporta todo, pero en ocasiones la cruda realidad nos dice lo contrario.

Ante una incidencia de máxima prioridad y una petición de servicio también de máxima prioridad, ¿que hay que atender primero? Hace unos días abrí un debate en Linkedin sobre si una solicitud de reseteo de password debería registrarse como una incidencia o como una petición, la respuesta fue unánime: petición. Ahora bien si un usuario necesita que su password sea reseteada, ¿puede esperar a la "cola" de la planificación?

Cierto es que en este caso lo importante no es el concepto sino darle una solución rápida al usuario. Por lo general el flujo de trabajo de las incidencias es el más "ágil" de todos los procesos y esto puede llevar a pensar que en un ejemplo como el anterior lo más aconsejable es saltarse la teoría. Cada organización debe tomar su propia decisión al respecto (adopt & adapt) pero... ¿hay alguna forma de seguir la teoría al pie de la letra sin perjudicar al usuario?

Lo habitual es que los técnicos que se encargan de tratar las incidencias sean los mismos que los que se dedican a las peticiones de servicio. Si el dimensionamiento lo permite, lo ideal sería tener a un recurso dedicado a realizar labores de "dispatcher". Esta persona debe tener unas directrices claras para poder tomar una decisión y repartir la carga de trabajo al equipo de técnicos correspondiente. Si no es posible disponer del "dispatcher" y la organización no es lo suficientemente madura existe el riesgo de que peticiones que no pueden esperar sean encoladas y retrasadas en el tiempo.

Self Service Desk Service

Sírvase usted mismo. Está es la filosofía de cualquier cualquier Self-Service y creo que a día de hoy este concepto no ha evolucionado lo suficiente como para decir que los usuarios disponen de autoservicios de calidad. En la mayoría de ocasiones su implementación es debida a una necesidad de descargar de trabajo al Service Desk y al resto de grupos operativos. Si este es el motivo que origina la puesta en marcha de un autoservicio el fracaso estará casi asegurado. Las organizaciones TI están obligadas a aportar valor y para eso deben tener más empatía con el usuario final. ITIL promueve el uso de buenas prácticas como por ejemplo la implementación de FAQ's pero, ¿es esto suficiente?, ¿el concepto de "autoservicio" es idéntico al de "hágalo usted mismo"?

Cuando pienso como actúan los usuarios finales (cada día que pasa me cuesta menos, ¿será por qué ya soy uno más?), siempre recuerdo una frase que escuche hace un tiempo a una persona con una dilatada experiencia en las relaciones entre TI y el negocio, "cada negocio con su negociado", es decir un usuario final vive en mundo distinto al de TI. Por supuesto que hay un nexo común, el uso de las TI, como manejar esta intersección es el centro del nudo gordiano que toca "desatar" desde la gestión de servicios. Implementar un self-service es  una tarea que hay que mimar si se quiere tener una herramienta que beneficie tanto al negocio como a TI.

Para mi, los factores críticos de éxito son los siguientes:

• Tener claro que incidencias/peticiones son mas frecuentes en la organización. En un post anterior ya se habló de este tema.
• Por muy recurrente que sea una incidencia/petición, no quiere decir que se pueda incluir en un self-service. Según lo complejo de la solución se debe incluir o no en el servicio.
• Disponer de herramientas "transparentes" para el usuario final que realicen las tareas necesarias para dar solución. Si no se dispone de presupuesto para contar con aplicativos software, hay que utilizar procedimientos de solución claros y concisos.
• Diseñar con sumo cuidado el argumentario al que se van a tener que enfrentar el usuario final para dar con la solución a su incidencia/petición.

Nunca hay que perder de vista que el lenguaje utilizado por el negocio suele ser distinto al que se emplea desde TI. Es necesario realizar un esfuerzo en encontrar un punto intermedio en el que ambas partes se encuentren confortables. Como en todos los servicios, la fase de Mejora Continua, formará parte activa de la evolución del self-service y puesto que es una herramienta orientada al usuario contar con su opinión es fundamental para adaptarlo a sus necesidades.

Pensar como un usuario es el quid de la cuestión: "no soy un experto en TI", "busco una solución rápida a mis problemas", "si el self-service es un servicio de calidad continuaré utilizándolo". El objetivo es facilitar el trabajo, no convertir al usuario en un técnico.

Alberto Álvarez Álvarez

Gestión de peticiones, un proceso a industrializar.

Cada vez que llevo el coche a la revisión en el taller oficial, se produce la misma situación (además de pagar una cuantiosa factura). Consultan el historial, le echan un rápido vistazo y me dicen al detalle que es lo que voy a tener que pagar y cuando voy a poder pasar a recogerlo. Si en el transcurso de la revisión detectan algo anómalo (no planificado) enseguida me llaman para notificarme las "buenas noticias". Para mi esto es un buen servicio.

Hasta dónde yo se no hay truco, lo que hay es una muy buena planificación, cada tarea que se lleva a cabo en el taller esta descrita y me atrevo a decir que hasta procedimentada, además tiene asociada un tiempo que es el que posteriormente viene reflejado en la factura (si no hay imprevistos). Tiempo, parámetro fundamental para cualquier proceso de planificación.

¿Cómo aplicar el funcionamiento de un taller a la Gestión de Peticiones?

En mi opinión simplemente hay que hacer una extrapolación a lo que he comentado anteriormente.Cualquier usuario final, incluso el más exigente, se encontrará satisfecho si a la hora de realizar una petición al Service Desk tuviera una respuesta inmediata del tiempo en el que va a ser solucionada la misma. Esto pasa por aplicar la industrialización al proceso de Gestión de Peticiones.

Lo primero es conseguir una relación de las distintas tareas que se pueden llevar a cabo dentro de cada petición que el usuario pueda hacer a través del catálogo. A cada una de ellas hay que asociarle un tiempo de ejecución. Ya estoy escuchando alguna voz que dice que esto es imposible: "esto de la informática no es igual que la mecánica de coches", "la misma tarea unas veces te llevará una hora y otras veces lo hará tres", ... hay que hacer un esfuerzo se puede conseguir. 

El resto es lo más sencillo, para saber la carga de trabajo actual en horas lo único que hay que hacer es multiplicar el número de tareas sin resolver en el momento actual, por el tiempo estimado. Si además somos capaces de saber las horas que el equipo de trabajo va a dedicar a realizar dichas peticiones, la planificación será coser y cantar.

Quizás los resultados obtenidos al principio no sean del todo exactos pero tampoco llevará mucho más esfuerzo acercarse a la realidad. Si no existe experiencia previa el estimar un tiempo para cada tarea será una cuestión de prueba y error o mejor dicho de aproximación, pero es posible conseguirlo.

Detalles a tener en cuenta:

• Las tareas no siempre son unitarias, es decir una petición puede conllevar más de una repetición. No es lo mismo que se pida instalar un procesador de textos en un pc que en cien. Con lo cual otro factor a tener en cuenta es el número de repeticiones.

• Antes de dar el paso de comunicar un tiempo estimado al usuario hay que estar seguro de que se va a poder cumplir. En mi opinión es peor dar un tiempo y no cumplir que no dar ningún tiempo.

• El obtener la carga de trabajo en horas además de ayudar a obtener una mejor planificación también permitirá tener un dimensionamiento más adecuado del número de recursos necesario.

Sigo empeñado en haceros parte activa del blog, con lo cual hoy dejo algunas preguntas abiertas esperando vuestras opiniones:

¿Que proceso debe ser el encargado de realizar está "buena práctica"? ¿Gestión de Peticiones? ¿Gestión de la Capacidad? ¿Los dos? ¿Otro distinto?...

Alberto Álvarez Álvarez

Incidencias nuevas vs recurrentes. Ley de Pareto

Peter Drucker considerado por muchos como el padre del Management dijo en una ocasión:

"Innovar es encontrar nuevos o mejorados usos a los recursos de que ya disponemos"

Los buenos propósitos que se suelen tener al inicio de un proyecto, en cuanto a la revisión de incidencias, suelen diluirse como un azucarillo en el café a medida que pasa el tiempo. Al principio se invierten muchos esfuerzos en documentar la aparición de "nuevas incidencias" pero habitualmente esta buena practica se va perdiendo con el paso del tiempo. Siguiendo el consejo de Drucker es de obligado cumplimiento innovar en un aspecto tan importante como es la repetición de las incidencias. Parece lógico pensar que no es posible que todos los días aparezca una incidencia totalmente distinta a las anteriores, aceptando que esto es así no queda otro camino que aceptar que la mayor parte de las incidencias se repiten de forma recurrente.

¿Cómo identificar que tipo de incidencias surgen con mayor frecuencia? Según mi experiencia un método tan sencillo como eficaz es el de aplicar la Ley de Pareto. Aunque su creador aplicó este principio a temas para nada relacionadas con la Gestión de Servicios TI, en la actualidad se aplica en distintos ámbitos entre ellos el control de calidad. También conocida como la ley del "80-20", su filosofía es la de "pocos problemas son vitales y muchos triviales". La primera vez que utilicé esta norma me parecía casi imposible que se cumpliese, los resultados obtenidos me hicieron cambiar de opinión radicalmente. Antes de exponer un ejemplo práctico es importante que quede bien claro un concepto, de nada sirve utilizar este o cualquier otro principio si los datos de origen no son fiables.

¿Cómo llevar a la práctica la Ley de Pareto en la Gestión de Incidencias? Lo primero que hay que hacer es obtener por ejemplo una relación de los distintos tipos de incidencias junto con sus volúmenes. Una tabla tan sencilla como la siguiente es mas que suficiente:

Simplemente hay que hacer hincapié en dos pequeños detalles, la lista esta ordenada de mayor a menor por el volumen de incidencias para cada tipo de incidencia. Por otra parte cualquier tipo o agrupación que se signifique por la categoría "Otros", debe ir siempre al final de la lista independientemente del volumen o cantidad a la que haga referencia. Una vez hecho esto el siguiente paso es calcular los porcentajes que representa cada tipo de incidencia respecto al total. Una vez hecho esto lo único que queda es representar los datos obtenidos en un gráfico como el siguiente:

La conclusión a la que se puede llegar observando el gráfico es: los 4 primeros tipos de incidencias representan casi un 80% del total de incidencias, lo cual quiere decir que el resto de incidencias supondrán el 20% restante. En este ejercicio (realizado con datos reales) se puede ver que la Ley de Pareto se cumple casi con total exactitud. Si los esfuerzos se centran en mejorar la solución sobre 4 tipos de incidencias se estará trabajando en mejorar un 80% del volumen total de incidencias.

Puede que en alguna ocasión el ejercicio no sea tan fiel a Pareto como el ejemplo que he reflejado, pero lo que si es cierto que siempre se puede encontrar una relación aproximada, si no es el famoso 80-20 será un 70-30 o incluso un 60-40, pero todo aquello que sea simplificar la búsqueda del conjunto de incidencias sobre el que hay que trabajar redundará en el beneficio del proceso.

En el siguiente post, ahondaremos un poco más sobre este tema que me parece muy interesante, incidencias nuevas vs recurrentes.

Una última cosa os animo a que dejéis vuestros comentarios en el blog, cualquier opinión siempre es enriquecedora y a todos nos ayudará a mejorar en este complicado mundo de la Gestión de Servicios.

Alberto Álvarez

Hablan nuestros clientes

Hoy aparcamos nuestras experiencias en el mundo de la Gestión de Servicios TI y del conjunto de mejores prácticas ITIL, para compartir con todos vosotros un caso de éxito en uno de nuestros clientes. Corporación Alimentaría Peñasanta (muchos de vosotros lo identificareis por Central Lechera Asturiana). Os dejamos la entrevista que Socinfo llevo a cabo al Director de TI. Solo tenéis que hacer clic en el play para escuchar la entrevista.

Gestión de Incidencias. Mapa de escalados.

La Gestión de Incidencias siempre tiene una espada de Damocles encima de la cabeza, el tiempo de solución. Siempre y cuando los tiempos sean acordes a los indicadores establecidos en el ANS no habrá ningún problema, la necesidad de mejora llega en el momento en el que este tiempo se demora en exceso. Los retrasos a la hora de solucionar una incidencia suelen motivarse por diferentes razones: dimensionamiento inadecuado, conocimiento insuficiente del entorno,..., y por último mi "favorito" el escalado infinito. Suele ser bastante frecuente encontrarse con incidencias que han pasado de forma reiterada por distintos grupos de soporte, los cuales siempre encuentran una justificación para escalar la incidencia: "he revisado mi parte y está todo bien", "la configuración es la adecuada", "seguro que es un problema del servidor",...

Para evitar este traspaso incontrolado de incidencias de un grupo a otro hay dos factores que se me antojan más que necesarios:

• Realizar un diagnóstico inicial lo más certero posible.
• Disponer de un mapa de escalados.

Ya comenté en su momento la conveniencia de trabajar sobre procedimientos diagnósticos que faciliten al Service Desk la tarea de identificar de forma inequívoca cual es el(los) elemento(s) afectado(s) por una incidencia. Aunque esto solo no será suficiente para encaminar las incidencias al grupo de soporte adecuado, hay que diseñar un Mapa de escalados. Este será la herramienta que se pondrá a disposición del Service Desk para que puedan distribuir de forma correcta las incidencias.

¿Qué hay que tener en cuenta a la hora de crear un mapa de escalados? Tal y como he comentado en otros post todo depende del nivel de madurez con el que cuente la organización. Lo ideal es que el mapa de escalados este embebido en la herramienta de gestión del servicio aunque quizás en la etapa de implantación y durante un corto período de tiempo se puede utilizar una simple hoja de Excel (cuantas menos hojas de Excel se utilicen mucho mejor). Pero en mi opinión hay algo todavía mucho más importante a tener en cuenta y son los criterios a seguir para asignar las incidencias a uno u otro grupo.

¿Cuales son estos criterios? En primer lugar hay que identificar de forma detallada que alcance tiene cada equipo de trabajo dentro de la gestión de incidencias. Este detalle tiene aún más relevancia si tenemos grupos de trabajo con un ámbito común pero con distinto alcance, por ejemplo un grupo N2 Unix y otro N3 Unix. Hay que tener muy claro que tipo de incidencias debe resolver cada grupo.

El otro criterio a tener en cuenta es la categorización o clasificación de las incidencias. En un post previo hablaba sobre la idoneidad de asociar el activo afectado y las preguntas a las que dar respuesta a la hora de clasificar una incidencia: ¿dónde reside el fallo? y ¿que ha provocado el fallo?.

Una vez establecidos los criterios anteriores, la creación del Mapa de escalados será una cuestión de mapeo entre estos y los equipos o grupos de trabajo que tenga la organización. Es importante que esta herramienta de escalados sea puesta en conocimiento de todos los integrantes de la organización. Por último y como todo en este mundo de la gestión de servicios, el Mapa de escalados debe ser una herramienta dinámica, a medida que la organización vaya madurando (sobre todo en lo que a documentación de soluciones tipo se refiere), es muy aconsejable que el alcance en cuanto a la solución de incidencias vaya adecuándose a los niveles menos especializados.

Alberto Álvarez

Gestión de incidencias. Reutilizar información.

Hace ya unos años que el hombre que más dinero ha ganado en este mundo de IT dijo: "El poder está en la información". Estoy seguro de que ni mucho menos se refería a nada que tenga que ver con ITIL, pero creo que la famosa frase viene como anillo al dedo a la hora de hablar de la información de que dispone cualquier organización dentro del proceso de Gestión de Incidencias. Generalmente este proceso es el que más cantidad de registros ocupará dentro de la aplicación de Service Management.

El valor de reutilizar dicha información no es lo suficientemente valorado por las organizaciones y precisamente es una fuente de conocimiento al alcance de todos. El problema reside básicamente en como se organizan los datos relativos a las incidencias. En un post anterior, ya hice referencia a una forma de clasificar o categorizar las incidencias. Esta agrupación es muy interesante a la hora de saber que tipo de incidencias son más recurrentes, pero hay otra parte de una incidencia que también hay que tener muy en cuenta, la solución.

Ser capaz de reutilizar la información disponible en la solución de una incidencia arroja al menos dos beneficios importantes:

• Medir la homogeneidad en la forma de solucionar las incidencias.
• Poner a disposición de los técnicos con menos experiencia una base de conocimiento bien organizada.

Cómo todo en este mundo de la gestión de servicios TI, enfrentarse a este reto no supone una tarea fácil. La  documentación ocupa un lugar privilegiado en el "top ten" de los trabajos más odiados por parte de los técnicos dedicados al mundo del soporte. Es necesario dar unas instrucciones muy claras de como se debe llevar a cabo si queremos disponer de información reutilizable y además hay que ser muy constante a la hora de "perseguir" la correcta aplicación de las directrices establecidas.

En la mayoría de las herramientas con las que he tenido contacto a lo largo de mi experiencia en la gestión de servicios IT, la información relativa a la solución suele estar vinculada a un extenso campo de texto en el que el técnico que soluciona una incidencia, describe de su "puño y letra" que es lo que ha hecho para resolverla. Uno de los contenidos más repetidos es el famoso "Incidencia solucionada" que como podréis imaginar no aporta nada a la hora de reaprovechar la información. 

Como ya es habitual os doy mi opinión de como llevar a cabo esta tarea. Desde mi punto de vista una buena práctica es la de "divide y vencerás". Extraer información útil de un campo de texto libre, es una tarea que no se la deseo ni al peor de mis enemigos. La solución pasa por intentar acotar la información que debe introducir un técnico a la hora de documentar una solución. Por ejemplo se puede dividir el campo solución en base a los resultados que queramos obtener:

• Es muy útil poder asociar el código del "Procedimiento de solución" utilizado, en el caso de que se haya utilizado un procedimiento estandard. 
• También es importante saber si se ha utilizado alguna herramienta (homologada o no) para dar solución a la incidencia.
• Si la solución de la incidencia ha sido a través de la ejecución de un cambio, es de obligado cumplimiento asociarlo con la incidencia antes de ser solucionada.

En resumen hay que pensar como deseamos reutilizar la información y adaptar el método a tal objetivo. Disponer de información estructurada siempre es más útil que utilizar campos de libre contenido.

¿Cuál es tu opinión?

Alberto Álvarez