INDICE

SOLUCION DE PROBLEMAS

A. METODOLOGIA PARA LA SOLUCION DE PROBLEMAS (IT)
3
i. Fase 1: Defining (Definicin) 4
ii. Fase 2: Gathering (Recoleccin) 4
iii. Fase 3: Analyzing (Analisis) 5
iv. Fase 4: Fixing (Solucin) 6

B. PROCESO CONTROL DE PROBLEMAS 7
i. Identificacin y Registro 7
ii. Clasificacin y Asignacin de Recursos 8
iii. Anlisis y Diagnstico: Error conocido 8

C. PROCESO DE CONTROL DE ERRORES 9
a) Identificacin y Registro de errores 9
b) Anlisis y Solucin 9
c) Revisin Post Implementacin y Cierre 10

D. CASO PRCTICO DE CONTROL DE PROBLEMAS 11
E. LINKOGRAFIA




f
a
c
f
y
m
2





SOLUCION DE PROBLEMAS
Diariamente es necesario enfrentar problemas y conflictos a los cuales se les deben encontrar
soluciones aceptables de acuerdo al contexto.El proceso de solucionar problemas implica una
serie de capacidades y habilidades del pensamiento que es importante desarrollar y evaluar.
A. METODOLOGIA PARA LA SOLUCION DE PROBLEMAS (IT)
Muchas veces necesitamos una metodologa para solucionar los problemas de nuestros
clientes. Hace algunos aos atrs, miembros del grupo de soporte de escalacin para
Latinoamrica se reunieron y crearon una metodologa que usa las mejores prcticas basadas
en la experiencia del grupo y en el mtodo cientfico para la solucin de problemas.
Son varios los beneficios que se obtienen al utilizar una metodologa para solucionar los
problemas, entre ellos llegar a una solucin lo ms rpido posible. Hemos querido compartir
con todos nuestros clientes estas mejores prcticas para que sean aplicadas no solamente en
los casos de soporte de Microsoft, sino en general en cualquier escenario de solucin de
problemas tcnicos.
El mtodo cientfico parte de la definicin de un problema, crea una hiptesis, recolecta los
datos necesarios, analiza estos datos, entrega un reporte de lo que en los datos se encontr y
valida o rechaza la hiptesis.
Estos mismos conceptos los podemos aplicar como metodologa para la solucin de los
problemas de soporte tcnico. De esta manera surgieron las cuatro etapas utilizadas por los
ingenieros del grupo de soporte de Microsoft de Latinoamrica.
Estas cuatro etapas son:
Defining.
Gathering.
Analyzing.
Fixing.
Fig. 1. Metodologa de resolucin de problemas
Estas estn representadas en la figura 1. Su representacin es cclica porque el proceso de
resolucin se mueve a travs de las cuatro fases en secuencia con el objetivo de que en cada
interaccin el problema sea acotado ms y ms hasta llegar a la solucin. La recomendacin es
seguir las fases en secuencia y no omitir ninguna.

Es muy difcil llegar al lugar a donde queremos ir si no definimos cual es dicho lugar. El proceso
3

de resolucin de problemas debe siempre comenzar con la definicin del problema. A
continuacin vamos a hablar de cada una de las etapas en detalle.



i. Fase 1: Defining (Definicin)
El primer paso es elaborar una buena definicin del problema. Depende de cmo definamos el
problema, va a ser ms fcil o ms difcil solucionarlo exitosamente. La definicin del problema
nos ayuda a definir tambin el criterio de solucin del mismo. Esto es lo que llamamos scope
del problema.
A menos que el problema este correctamente definido, es poco probable que sea encontrada
una solucin satisfactoria.
Existen varias tcnicas que pueden ser utilizadas durante esta etapa y que ayudan a nuestros
ingenieros a definir un problema, entre ellas tenemos:
Escuchar activamente.
Realizar preguntas precisas.
Parafrasear.

El objetivo es capturar la mayor cantidad de detalles e informacin que nos ayude a definir el
problema de una manera precisa.

Con base en la definicin del problema y el conocimiento de cmo el producto debera
funcionar, el siguiente paso es crear una hiptesis acerca de que podra ser la causa del
problema.

Recordemos que una hiptesis es una declaracin que an no se ha establecido como cierta.
En el caso de los ingenieros de soporte, diramos que es una aproximacin educada basada en
experiencia, conocimiento, habilidades e intuicin.

El crear una hiptesis nos ayuda a darle un enfoque a nuestro pensamiento y continuar con las
siguientes fases.

La fase de defining o definicin, nos debe dar como resultados:
Una definicin clara del problema.
El criterio bajo el cual se define la solucin del problema.
Una o ms hiptesis.


ii. Fase 2: Gathering (Recoleccin)
Con base en la hiptesis creada, ahora s podemos comenzar a recolectar los datos que son
necesarios para comprobar o refutar la hiptesis. Muchas veces tendemos a capturar
4

informacin sin antes haber definido el problema y puede ser frustrante invertir tiempo en
recolectar informacin que no ser usada. El primer objetivo de esta fase es definir un plan de
accin efectivo para la recoleccin de los datos de tal manera que todos los datos necesarios
sean recolectados en la primera vez. El segundo objetivo de esta fase es garantizar que la
calidad de los datos es ptima antes de pasar al anlisis.

Un buen plan de accin debe ser detallado, incluir informacin especfica de lo que se necesita
y si es el caso, incluir explicaciones detalladas de como recolectar la informacin. Actualmente
existen herramientas de soporte remoto que facilitan esta labor, caso que se necesite de
ayuda para recolectar los datos.
Despus de definir el plan de accin de cuales datos se necesitan y cmo van a ser
recolectados, el siguiente paso es recolectar dicha informacin siguiendo el plan creado. Una
buena prctica es tomar una pequea muestra de los datos para estar seguros que se est
recolectando correctamente. Un ejemplo de este escenario son los logs del performance
monitor. Se puede tomar una muestra por un periodo corto de tiempo para garantizar que los
contadores estn trabajando como se espera.
Antes que los datos sean analizados deben ser validados. La validacin consiste en responder
las siguientes preguntas:
Es leble la informacin? Por ejemplo un dump de memoria. El cliente puede revisar
que es vlido antes de enviarlo al ingeniero usando herramientas como el
dumpchk.exe.

Los datos contienen informacin relevante? Por ejemplo en una captura de red. El
cliente puede revisar con en Network Monitor que la captura incluye trfico entre las
maquinas relevantes al problema.

Estas pequeas acciones evitan invertir tiempo innecesario tanto del cliente como del
ingeniero.
La fase de gathering o recoleccin, nos debe dar como resultados:
Un plan de accin detallado para recolectar los datos necesarios.
Validacin de los datos recolectados.

iii. Fase 3: Analyzing (Analisis)
El objetivo de esta fase es analizar la informacin recolectada en la fase anterior. Esta
informacin es estudiada para confirmar o rechazar la hiptesis o hiptesis generadas en la
primera fase.
Analizar el problema implica aprender sobre el mismo lo ms que se pueda. En esta fase la
experiencia en el tema es crtica as como tambin las herramientas usadas para el anlisis.
Dentro de las acciones que un ingeniero de soporte realiza durante esta fase de anlisis estn:
Separar los datos que son relevantes para el anlisis basado en la definicin del
problema y en el conocimiento y experiencia sobre el tema.

5

Buscar por evidencia obvia primero antes de invertir tiempo en un anlisis ms
profundo. Para clarificar este punto, un ejemplo es revisar los logs de EventViewer
antes de tomar un dump completo de la mquina.

Buscar por contenido ya existente en las bases de datos de conocimiento. Nuestros
clientes podran realizar este paso buscando en el sitio de soporte de Microsoft y
tambin revisando sus bases de datos de problemas internos.
Realizar un anlisis ms profundo. Esto es, investigar los datos recolectados en detalle,
intentar reproducir el problema, comparar los datos recolectados con relacin a un
ambiente que est trabajando normalmente.

Como resultado de este anlisis, debemos ser capaces de confirmar la hiptesis, hay suficiente
evidencia que confirme la hiptesis y soporte un diagnostico; o por el contrario tenemos que
rechazar la hiptesis.
En caso que la hiptesis sea rechazada, tendremos que comenzar un ciclo, esto es, ir a la fase
de definicin nuevamente. En este punto se debe considerar colaboracin o escalacin del
problema al siguiente nivel.
La fase de analyzing o anlisis, nos debe dar como resultados:
Hiptesis confirmada por el anlisis de los datos.
Resultado del anlisis de los datos.
Posible causa raz identificada.
Comunicacin a nivel de las personas involucradas informando el progreso.

iv. Fase 4: Fixing(Solucin)
En esta fase con base al anlisis realizado previamente, necesitamos elaborar un plan de
accin para solucionar el problema. Este plan de accin de solucin debe considerar el impacto
y los riesgos de las acciones sugeridas. De ser necesario se recomienda probar el plan de
accin en un ambiente de pruebas y de no ser posible, incluir las medidas necesarias tales
como tener un respaldo (backup), planes de contingencia, en caso que el plan de accin deba
ser aplicado directamente a produccin.
Como mejores prcticas para la solucin de problemas tcnicos, la experiencia nos ensea a:
Si hay varias maneras de solucionar el problema o una solucin involucra varios pasos,
aplicar un cambio cada vez y observar los resultados.
Seguir los pasos de acuerdo a las instrucciones dadas y al orden recomendado.
En caso de dudas sobre el plan de accin, preguntar antes de ejecutar.

Aqu podemos tener varias situaciones, que veremos a continuacin.
Si despus de aplicar el plan de accin, los sntomas desaparecen, podemos considerar
el problema como resuelto.
Si el problema original est resuelto pero aparece un problema diferente, esto se debe
manejar como un nuevo incidente de soporte e iniciar nuevamente con el ciclo de
solucin.
6

Si el problema contina, no hay cambio en los sntomas, debemos retornar a la fase de
definicin y comenzar nuevamente. Escalacin al siguiente nivel debe ser considerara
en esta situacin.
Si el problema empeora (esta condicin es la menos deseada por supuesto!),
escalacin al siguiente nivel debe ser considerada a este punto.




La fase de solucin, nos debe dar como resultados la solucin al problema originalmente
definido o la decisin de volver a la fase de defining o definicin nuevamente; obviamente
considerando la posibilidad de involucrar recursos adicionales que nos ayuden a llegar a una
solucin.

B) PROCESO CONTROL DE PROBLEMAS

El principal objetivo del Control de Problemas es conseguir que estos se conviertan enErrores
Conocidos para que el Control de Errores pueda proponer las soluciones correspondientes.


El Control de Problemas se compone en esencia de tres fases:
1. Identificacin y Registro
Una de las tareas principales de la Gestin de Problemas es identificar los mismos. Las
principales fuentes de informacin utilizadas son:
La base de datos de Incidentes: en principio cualquier incidente del que no se conocen
sus causas y que se ha cerrado mediante algn tipo de solucin temporal es
potencialmente un problema. Sin embargo, se habr de analizar si este incidente es
aislado o su impacto en la estructura TI antes de elevarlo a la categora de problema.
Anlisis de la infraestructura TI: en colaboracin con la Gestin de Disponibilidad y de
Capacidad, la Gestin de Problemas debe analizar los diferentes procesos y determinar
7

en qu aspectos se debe reforzar los sistemas y estructuras TI para evitar futuros
problemas.
Deterioro de los Niveles de Servicio: el descenso del rendimiento puede ser una
indicacin de la existencia de problemas subyacentes que no se hayan manifestado de
forma explcita como incidentes.

Todas las reas de la infraestructura TI deben colaborar con la Gestin de Problemas para
identificar problemas reales y potenciales informando a sta de cualquier sntoma que pueda
ser seal de un deterioro en el servicio TI.
El registro de problemas es, en principio, similar al de los incidentes aunque el nfasis debe
hacerse no en los detalles especficos de los incidentes asociados sino ms bien en su
naturaleza y posible impacto.
El registro debe incorporar, entre otra, informacin sobre:
Los CIs implicados.
Causas del problema.
Sntomas asociados.
Soluciones temporales.
Servicios involucrados.
Niveles de prioridad, urgencia e impacto.
Estado: activo, error conocido, cerrado.

2. Clasificacin y Asignacin de Recursos
La clasificacin del problema engloba desde las caractersticas generales de ste, tales como si
es un problema de hardware o software, que reas funcionales se ven afectadas y detalles
sobre los diferentes elementos de configuracin (CIs) involucrados en el mismo.
Un factor esencial es la determinacin de la prioridad del problema, que al igual que en el caso
de los incidentes, se determina tanto a partir de la urgencia (demora aceptable para la
solucin del problema) como de su impacto (grado de deterioro de la calidad del servicio).
Al igual que en la Gestin de Incidentes la prioridad puede cambiar en el curso del ciclo de vida
del problema, por ejemplo, si se encuentra una solucin temporal al mismo que reduce
considerablemente su impacto.
Una vez clasificado y determinada su prioridad se deben de asignar los recursos necesarios
para su solucin. Estos recursos deben ser suficientes para asegurar que los problemas
asociados son tratados eficazmente y as minimizar su impacto en la infraestructura TI.

3. Anlisis y Diagnstico: Error conocido
Los objetivos principales del proceso de anlisis son:
a. Determinar las causas del problema.
b. Proporcionar soluciones temporales a la Gestin de Incidentes para minimizar
el impacto del problema hasta que se implemente los cambios necesarios que
lo resuelvan definitivamente.
8



Es esencial tener en cuenta que no siempre el origen del problema es un error de hardware o
software. Es moneda frecuente que el problema este causado por:
Errores de procedimiento.
Documentacin incorrecta.
Falta de coordinacin entre diferentes reas.
...


Es tambin posible que la causa del problema sea un "bug" bien conocido de alguno de las
aplicaciones utilizadas. Por lo tanto es conveniente establecer contacto directo con el entorno
de desarrollo, en caso de aplicaciones desarrolladas "en la casa", o investigar en Internet
informacin sobre errores conocidos aplicables al problema en cuestin.
Una vez determinadas las causas del problema ste se convierte en un Error Conocido y se
remite al Control de Errores para su posterior procesamiento.
Una vez que el Control de Problemas ha determinado las causas de un problema es
responsabilidad del Control de Errores el registro del mismo como error conocido.

C) PROCESO DE CONTROL DE ERRORES
a) Identificacin y Registro de errores
El registro de los errores conocidos es de vital importancia para la Gestin de Incidentes pues
debe llevar asociado, siempre que esto sea posible, algn tipo de solucin temporal que
permita minimizar el impacto de los incidentes asociados.
b) Anlisis y Solucin
9

Se deben investigar diferentes soluciones para el error evaluando en cada momento:
El posible impacto de las mismas en la infraestructura TI.
Los costes asociados.
Sus consecuencias sobre los SLAs.

En algunos casos, en los que el impacto del problema puede tener consecuencias graves en la
calidad del servicio, pueden emitirse una RFC de emergencia para su procesamiento urgente
por la Gestin de Cambios.
Una vez determinada la solucin ptima al problema y antes de elevar una RFC a la Gestin de
Cambios han de tenerse en cuenta las siguientes consideraciones:
Es conveniente demorar la solucin? Ya sea porque se prevn cambios
significativos en la infr
aestructura TI a corto plazo o por el escaso impacto del problema en cuestin.
Es la solucin temporal aportada suficiente para mantener unos niveles de
calidad de servicios aceptable?
Los beneficios justifican los costes asociados?

Sea cual sea la respuesta, todo la informacin sobre el error y su solucin se registrar en las
bases de datos asociadas. En el caso en el que se considere que el problema necesita ser
solucionado se emitir una RFC. Ser responsabilidad de la Gestin de Cambios la
implementacin de los cambios de infraestructura propuestos.

c) Revisin Post Implementacin y Cierre
Antes de dar el problema por resuelto y cambiar su estado a cerrado se debe analizar el
resultado de la implementacin de la RFC elevado a la Gestin de Cambios (PIR).
Si los resultados de esta PIR son los deseados y se pueden cerrar todos los incidentes
relacionados con este problema se considera concluido el proceso y se emiten los informes
correspondientes.
El objetivo de la Gestin de Problemas no es otro que el de mejorar el funcionamiento de la
infraestructura TI y para evaluar su eficacia es imprescindible realizar un continuo seguimiento
de los procesos relacionados y evaluar su rendimiento.
En particular una buena gestin de problemas debe traducirse en una:
Disminucin del nmero de incidentes y una ms rpida resolucin de los
mismos.
Mayor eficacia en la resolucin de problemas.
Gestin proactiva que permita identificar problemas potenciales antes de que
estos se manifiesten o provoquen una seria degradacin de la calidad del
servicio.

La correcta elaboracin de informes permite evaluar el rendimiento de la Gestin de
Problemas y aporta informacin de vital importancia a otras reas de la infraestructura TI.
Entre la documentacin generada cabra destacar:
10

Informes de Rendimiento de la Gestin de Problemas: donde se detalle el
nmero de errores resueltos, la eficacia de las soluciones propuestas, los
tiempos de respuesta y el impacto en la Gestin de Incidentes.
Informes de Gestin Proactiva: donde se especifiquen las acciones ejercidas
para la prevencin de nuevos problemas y los resultados de los anlisis
realizados sobre la adecuacin de las estructuras TI a las necesidades de la
empresa.
Informes de Calidad de Productos y Servicios: donde se evale el impacto en la
calidad del servicio de los productos y servicios contratados y que
eventualmente puedan permitir adoptar decisiones informadas sobre cambios
de proveedores, etc.



Una eficaz Gestin de Problemas tambin requiere determinar claramente quienes son los
responsables de cada proceso. Sin embargo, en pequeas organizaciones es recomendable no
segmentar en exceso las responsabilidades para evitar los costes asociados: sera poco eficaz y
contraproducente asignar unos recursos humanos desproporcionados al proceso de
identificacin y solucin de problemas.

D) CASO PRCTICO DE CONTROL DE PROBLEMAS
El ServiceDesk de "CaterMatters" ha informado a la Gestin de Problemas sobre unaincidencia
a la que no se le pudo asociar un error conocido y que causo una interrupcin de bajo impacto
en el servicio.
La Gestin de Problemas decide analizar el problema utilizando el protocolo establecido, que
en este caso sigue el modelo de Kepner y Tregoe:
Identificacin del problema.
Clasificacin del problema.
Establecimiento de las posibles causas.
Comprobacin de la causa ms probable.
Verificacin de la causa verdadera.

Identificacin: En nuestro caso el problema es sencillo de definir:
La aplicacin de pedidos online muestra, de forma no previsible, errores en el
registro de ciertos pedidos, sin que este error parezca tener correlacin con
otros componentes de hardware / software.

Clasificacin: La clasificacin se adaptara a los siguientes parmetros:
Identificacin: Problemas en el registro de pedidos.
Origen: Mdulo de pedidos online.
Frecuencia: el problema no es recurrente, es la primera vez que se detecta.
Impacto: leve. El incidente ha sido resuelto sin una interrupcin grave del
servicio.

Posibles causas: Entre las causas ms probables figuran:
11

Errores en la programacin del lado cliente de la aplicacin.
Errores en los mdulos de registro del servidor web.
Errores de configuracin de la base de datos.

Los analistas deciden que el origen ms probable del problema est en los mdulos de registro
de la aplicacin.
Comprobacin de la causa ms probable: con la ayuda de la informacin registrada por la
Gestin de Incidentes:
Se intenta reproducir el problema.
Se comprueba que el error slo se reproduce con una determinada marca de
helados.
Se comprueba que dicha marca de helados tiene un apstrofe en el nombre y
que eliminado ste se registra el pedido sin problemas.

Verificacin:
Se crea un entorno de pruebas que reproduce el mdulo de inters en el
entorno de produccin.
Se introducen las modificaciones necesarias en la programacin.
Se comprueba el correcto registro del pedido.

El problema se ha convertido en un error conocido, es ahora tarea del Control de Errores:
Elevar una RFC con la solucin propuesta.
Llevar a cabo la revisin post-implementacin en el caso de que la Gestin de
Cambios considere oportuno implementar la RFC.


E) LINKOGRAFIA
http://www.taringa.net/posts/info/10973778/Metodologia-para-la-solucion-de-problemas-
IT.html
http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/gestion_de_problemas/proceso_gestion_
de_problemas/control_de_problemas.php