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

16 Sep

Gestión de tareas

Gestión de tareas

Cualquier equipo de trabajo requiere una gestión de tareas para repartir la actividad a realizar entre los miembros. ProactivaNET ofrece herramientas de gestión -por ejemplo el módulo de Gestión de Incidencias y Peticiones- pero a veces es necesario gestionar cuestiones ajenas a procesos ITSM. ¿Cómo hacerlo?

Seguro que en su organización tiene que coordinar la realización de tareas dentro de equipos de trabajo.

Leer más
6 May

Empresas de servicios que no comprenden el concepto de servicio

Empresas de servicios que no comprenden el concepto de servicio

Muchas empresas son proveedores de servicios y siguen funcionando sin marcos de referencia adecuados, lo que provoca ineficiencias y faltas de calidad. Aunque una empresa opere en un negocio ajeno a las TI, pueda apoyarse en los marcos de referencia existente para mejorar.

La norma ISO 20000-1 (2011) se denomina “Requisitos del Sistema de Gestión del Servicio (SGS)” y, aunque está dentro de un apartado llamado “Tecnología de la información”, puede leerse obviando la relación con TI y pensando en proveedores de servicio en general.

Leer más
18 Feb

Queda mucho camino por recorrer

Queda mucho camino por recorrer

Aunque la Gestión de Servicios de TI, amparadas por ITIL o ISO 20000, son prácticas conocidas y reconocidas en el sector existen muchas organizaciones que se resisten a implantarlas. Sin duda hay mucho camino por recorrer y muchas oportunidades para mejorar la calidad de los servicios y la productividad de las organizaciones.

España es un país de PyME (en general más P que M), donde el 99,3% tiene menos de 50 empleados. Si nos centramos en el sector relacionado con TI, ver capítulo 10 del informe sobre implantación de las TIC en las PyME, podemos observar que hablamos de un número importante de empresas (unas 26.000 dedicadas a la programación, consultoría y otras actividades relacionadas).

Leer más
10 Dic

Incidencias y problemas, mejor juntos

Incidencias y problemas, mejor juntos

Estamos muy acostumbrados a realizar una gestión “conjunta” de incidencias y peticiones, cuando realmente son procesos que atienden “casos” totalmente distintos. Y mientras estos dos procesos suelen acercarse mucho entre ellos, un tercero, el de problemas, queda algo separado, o al menos en segunda fila. CMMI-SVC ofrece un acercamiento totalmente distinto a este enfoque, juntando las incidencias y los problemas, lo cual puede que sea un enfoque muy acertado.

Quizá sea herencia de versiones anteriores de los marcos de mejores prácticas, pero lo cierto es que son muchas las organizaciones que “juntan” los procesos de gestión de incidencias y peticiones.

Leer más
28 Ago

Dimensionando la primera línea de soporte (5 de 5)

Dimensionando la primera línea de soporte (5 de 5)

En esta serie de artículos estudiaremos cómo dimensionar correctamente la primera línea de soporte que atiende incidencias y peticiones. De esta manera, los costes de personal para la provisión del servicio se mantendrán ajustados a la par que garantizamos el cumplimiento de los niveles de servicio pactados.

En este último artículo de la serie completaremos la explicación directamente con un ejemplo. Le sugiero que tenga a mano las definiciones del artículo anterior.

Leer más
21 Ago

Dimensionando la primera línea de soporte (4 de 5)

Dimensionando la primera línea de soporte (4 de 5) 2

En esta serie de artículos estudiaremos cómo dimensionar correctamente la primera línea de soporte que atiende incidencias y peticiones. De esta manera, los costes de personal para la provisión del servicio se mantendrán ajustados a la par que garantizamos el cumplimiento de los niveles de servicio pactados.

En el artículo anterior de esta serie terminamos indicando los parámetros que participan en el cálculo:

  1. El tiempo medio que transcurre entre dos incidencias/peticiones recepcionadas por la primera línea en la franja horaria que estamos considerando.
  2. El tiempo medio requerido en la atención a una incidencia/petición de la clasificación que estamos considerando.
  3. El tiempo máximo de espera aceptable para que una incidencia/petición sea atendida por un técnico del pool correspondiente a dicha clasificación.
  4. El número de técnicos disponibles en el pool que atiende las incidencias/peticiones de esta clasificación en esta franja horaria.

Leer más
27 May

Solicitud de cambio y RFCs no son lo mismo

chang-future-case-goldfish

Muchas veces se confunden y se consideran iguales,  pero lejos de ser lo mismo, los cambios (RFCs) y las solicitudes de cambio no son lo mismo. Sin entrar en grandes tratados ni estudios “ITILicos” detallados, a continuación trataremos de aportar un poco de luz al respecto…

Aunque no me considero ni ejerzo de consultor de procesos ITIL, sí es verdad que mi vida profesional gira en torno al ese marco de gestión de servicios TI, y de la mano de ProactivaNET me toca orientar y asesorar a clientes y potenciales sobre cómo enfocar la implantación de algunos procesos utilizando nuestra herramienta. Uno de los procesos sobre el que más dudas surgen y sobre el que más preguntas recibo es sobre la gestión de cambios,  y al profundizar en el tema,  en muchas ocasiones descubro que realmente estamos hablando de peticiones,  no de cambios.

El proceso de gestión de peticiones es un proceso ejecutado la mayoría de las ocasiones por el Centro de Servicios, típicamente de manera muy cercana al de gestión de incidencias (aunque son cosas totalmente distintas), que recepciona las nuevas solicitudes realizadas por parte de los usuarios finales,  conforme al un catálogo de servicios que deberíamos tener definido y publicado. Las peticiones pueden ser de muchos tipos: peticiones de compra, solicitudes de nuevos servicios, peticiones para adaptar informes, consultas técnicas, resolución de dudas, asesoramiento,… En ningún caso el servicio se ve comprometido (todo debería estar funcionando bien).

Uno de esos tipos de peticiones puede ser precisamente una petición expresa de cambio (por ejemplo en un informe), pero en otras ocasiones una petición podría derivar en un cambio sin que el usuario realmente sea consciente de ello. La solicitud del usuario es el mecanismo por el cual nos piden las cosas, de manera pública, y que puede desencadenar (o no) una RFC en la gestión de cambios, que quizá ya no sea visible para el usuario final,  al ser un proceso interno de las TI.  Es más, en muchas organizaciones las peticiones que derivan un cambio incluso salen del ámbito del Service Desk, pasando a equipos de gestión de proyectos externos gestionados por PMOs (no digo que sea lo más recomendable ni mucho menos, pero la realidad es esa en muchos casos…)

Una regla que ayudará a determinar de qué estamos hablando, podría ser la siguiente:

  • Si lo que necesitas es gestionar el flujo de peticiones de cambio por parte de tus usuarios (establecer un mecanismo para que te pidan cosas) , estamos hablando de gestión de peticiones,  no de gestión de cambios (aunque derivado del primero quizá necesites al segundo); muchas peticiones se resolverán sin necesidad de realizar ningún cambio.
  • Sí lo que necesitas es gestionar el propio cambio en sí (no tanto la propia solicitud y comunicación con el usuario, si no más bien el “proyecto”) , haya llegado a partir de una petición de usuario o de cualquier otro origen, estamos hablando de gestión de cambios; un volumen importante de cambios vendrán derivados de orígenes muy diversos,  no de ninguna petición del usuario.

Como casi siempre en ITIL, todo es cuestionable y “depende” de cada caso, pero espero que esta sencilla reflexión sirva para sacar de la duda a algún que otro despistado 😉

Jandro Castro.

Leer más
29 Ago

#ITILGlossary-Prioridad

ITIL Glossary-Prioridad

ITIL Glossary-Prioridad

Prioridad=Impacto * Urgencia. Lo complicado de la fórmula anterior no resulta tanto realizar el cálculo, si no establecer y dejar perfectamente claro cuáles son los niveles de impacto que vamos a utilizar, y cuándo vamos a utilizarlos, y de igual manera para las urgencia. Debido a esa dificultad, muchas organizaciones simplifican el proceso de priorización de incidencias, peticiones, problemas, cambios,… indicando directamente la prioridad, y prescindiendo de los otros conceptos. Esta simplificación podría ser correcta siempre y cuando: (a) siempre se realice de la misma manera, (b) sea lo más objetiva posible, disminuyendo su componente subjetiva. Si finalmente se opta con realizar una priorización basada en impacto y urgencia, resultará cómodo que el número de niveles de impacto sea el mismo que el número de niveles de urgencia y prioridades, de tal manera que la “matriz de priorización” sea cuadrada (más fácil de rellenar que si no tiene el mismo número de elementos en cambas dimensiones). A continuación, un ejemplo típico de matriz de priorización.

Ejemplo de matriz de priorización

Ejemplo de matriz de priorización

Jandro Castro

Leer más
27 Jun

#ITILGlossary – Petición de servicio

ITIL Glossary-Petición de Servicio

ITIL Glossary-Petición de servicio.

No confundir con las incidencias, en las que hay algo que “va mal”. En el caso de las peticiones de servicio no hay nada que esté fallando, simplemente necesitamos “algo más”. El origen de la confusión viene muchas veces derivado del uso de la misma herramienta para la gestión de incidencias y para la gestión de peticiones de servicio, pero es importante saber diferenciarlas. Esa diferenciación muchas veces derivará en acuerdos de niveles de servicio distintos para incidencias y peticiones: si la incidencia es algo que va mal, y la petición es algo más que necesito pero toda va bien; ¿no es lógico pensar que muchas veces el SLA vinculado a las incidencias debería ofrecer tiempos de resolución más ágiles que para las peticiones? (no debe generalizarse, no siempre será así, pero muchas veces sí…). Otro aspecto importante en la gestión de peticiones es que muchas veces requerirán de procesos de autorización o aprobación antes de poder resolverlas (por ejemplo, una petición para la compra de un nuevo equipo requerirá una autorización previa). Por último, merece la pena reflexionar sobre dónde acaba una petición de servicio y dónde comienza un cambio estándar, ya que muchas veces la barrera que los separa no está del todo clara… Para aquellos que tienen dudas sobre dónde poner la barrera, simplemente transmitir tranquilidad, ya que realmente no es muy relevante dónde termina una petición y dónde empieza un cambio estándar, siempre y cuando esté claro cómo se gestionan, y todas ellas se gestionen por igual (recordar que esto no es un examen de ITIL, aquí lo importante es gestionar bien todas las peticiones, de manera homogénea, y garantizando que ofrecemos a nuestro negocio el máximo valor posible).

Jandro Castro

Leer más
26 Mar

Para poner orden: primero mide

mideMuchas organizaciones implantan herramientas de ITSM Software para poner orden en sus procesos. Si te encuentras en este caso, te interesa usar métricas para valorar la situación actual de tu empresa. Siguiendo la máxima que dice que no se puede mejorar lo que no se conoce, el primer paso es emplear métricas para conocer la situación real de una manera objetiva. En general se pueden seguir tres recomendaciones básicas:

1. Conocer la carga de trabajo desde el punto de vista de los clientes. Deberíamos establecer una serie de métricas que nos permitan conocer la demanda:

  • ¿Cuántas incidencias se generan para cada servicio ofrecido en un periodo de tiempo?
  • ¿Cuántas incidencias genera cada cliente?

Podríamos establecer métricas sobre otros procesos que no sean la Gestión de Incidencias, pero desde el punto de vista del usuario final seguramente sean los registros más relevantes. Al fin y al cabo, cada incidencia es un fallo que le ha impedido realizar su trabajo.

Así podríamos identificar qué servicios fallan más y qué cliente se ve más afectado por los fallos para identificar fácilmente dónde actuar (Gestión de Problemas y Gestión de Cambios), reducir el número de incidencias y mejorar la percepción de los clientes.

2.- Conocer el coste de la prestación de los servicios. El departamento de TI debe operar como cualquier negocio, contrastando unos ingresos (presupuesto asignado) contra unos gastos. La prestación de servicios provocará unos costes que, en muchos casos, podremos reducir.

  • ¿Cuánto cuesta la resolución de las incidencias y peticiones de cada servicio en un periodo de tiempo?
  • ¿Cuánto cuesta la resolución de las incidencias y peticiones de cada cliente en un periodo de tiempo?

El coste normalmente es más fácil calcularlo en horas y luego definir un coste por hora para obtener un importe económico. Es necesario que los técnicos registren cada acción realizada y el tiempo empleado. Con estas métricas podríamos identificar qué servicios son más costosos de proveer y podríamos identificar dónde actuar (Gestión de Cambios) para tratar de optimizar costes. Por ejemplo identificando necesidades de formación, rediseñando servicios, implementando nuevas soluciones tecnológicas, etc.

3.- Conocer la madurez de los procesos.

Es imprescindible conocer si los procesos ITSM implantados están operando como se espera. Preguntémonos, por ejemplo:

  • ¿Los técnicos que gestionan incidencias y peticiones las registran todas?
  • ¿Los usuarios finales utilizan los canales de contacto definidos o se utilizan canales no oficiales?
  • ¿Para cada RFC se realiza la correspondiente PIR?
  • ¿Las PIR se utilizan para emprender acciones de mejora?
  • ¿Se mide el impacto de los problemas resueltos sobre la calidad del servicio?
José Luis Fernández Piñero
Leer más
22 Mar

Gestión del Conocimiento y mejora continua 3/3

Tecnico_de_vacacionesEn muchas organizaciones llegan a presentarse situaciones como las que comentaremos en este artículo. En el caso de que lleguemos a identificarnos con alguna de ellas es posible que podamos aplicar alguna de las soluciones sugeridas.

¿Los técnicos se encuentran con incidencias o peticiones que no saben cómo resolver? Si se encuentra en esta situación hay tres posibilidades: que los criterios de escalado a los grupos de soporte no sean adecuados, que el grupo asignado sea el correcto pero no disponga de la formación adecuada o que sólo algunos técnicos posean un conocimiento no disponible para el resto.

Si las incidencias y peticiones se escalan a grupos que no tienen el conocimiento para resolverlas pero otros grupos si tienen este conocimiento, entonces los criterios de escalado no son adecuados y deberán revisarse para evitar que las incidencias y peticiones requieran de varios reescalados antes de alcanzar el grupo adecuado. No obstante, debemos revisar que no nos encontremos realmente en la situación descrita en el primer artículo (1/3) de esta serie.

Si el grupo al que se asigna la incidencia y petición es el adecuado pero no dispone del conocimiento necesario, entonces debemos asegurarnos de que se preparen los recursos formativos oportunos y que los técnicos sigan el plan de formación adecuado. Recomendamos revisar la situación descrita en el segundo artículo (2/3) de la serie, donde se hacen sugerencias al respecto.

Si sólo algunos técnicos disponen del conocimiento, entonces debemos encargarles a ellos que preparen los recursos de ayuda y formación oportunos para que se pongan a disposición de los demás técnicos. El objetivo es que el conocimiento esté disponible para toda la organización y no sólo para algunos técnicos.

En esta última situación, tal vez nos encontremos con técnicos reticentes a compartir este conocimiento para preservar cierta situación de privilegio. Si nos sucede esto, debemos explicarle al técnico las ventajas que tendría para la organización compartir su conocimiento y a su vez las ventajas que tendría para él mismo.

Podría ser ventajoso para el técnico porque siempre tendría mayor flexibilidad a la hora de tomarse unas vacaciones, al no ser tan crítica su presencia en la empresa y no resultar necesario llamarle para que resuelva “crisis” que sólo él sabe cómo resolver en ese caso. También incluso, se le podría premiar de alguna forma (por ejemplo una bonificación en la nómina) por aportar y compartir su conocimiento con la organización, convirtiéndose en un técnico de referencia.

Si el técnico sigue siendo reacio a colaborar, entonces posiblemente debamos plantearnos reemplazarlo o bien tengamos que asumir esta situación considerándola un riesgo más para la operativa del departamento. ¿Qué sucedería si se pone enfermo o se va a trabajar a otra empresa?

Sin duda hay más situaciones que se pueden encontrar en las organizaciones, pero esperamos que esta serie de tres artículos recorra la casuística más común y ofrezca algunas sugerencias sobre cómo abordarlas.

Leer anterior post sobre Gestión del Conocimiento y mejora continua 2/3.

José Luis Fernández Piñero
Leer más
19 Mar

La Gestión de Niveles de Servicio de ProactivaNET se certifica en PinkVERIFY 2011

Certificaciones10_800x600

ProactivaNET 8 acaba de certificar otro proceso más en PinkVERIFY 2011. En este caso ha sido la Gestión de Niveles de Servicio y con éste ya son 10 los procesos de ProactivaNET certificados por el programa de verificación de herramientas ITSM Software más riguroso del mundo.

Esta certificación demuestra el alineamiento de la herramienta con las mejores prácticas ITIL® y su garantía de usabilidad por los consumidores finales.

La solución ProactivaNET está certificada en 10 procesos de ITIL 2011, que, de acuerdo a PinkVERIFY, se consideran óptimos para alcanzar calidad y eficiencia en las operaciones de TI:

  • Gestión de Incidencias
  • Gestión de Peticiones
  • Gestión de Cambios
  • Gestión de Problemas
  • Gestión de Entregas y Despliegues
  • Gestión de la Configuración y Activos del Servicio (CMDB)
  • Gestión del Conocimiento
  • Cartera de Servicios
  • Catálogo de Servicios
  • Gestión de Niveles de Servicio
Si quieres conocer más sobre nuestro módulo de Gestión de Niveles de Servicio no dudes en contactar con nosotros. Lea aquí más información sobre las certificaciones de ProactivaNET.
Leer más
11 Mar

Gestión del Conocimiento y mejora continua 1/3

ideas1El personal de una organización es un activo clave para obtener la máxima productividad. Sin embargo, para que esto sea cierto el equipo, humano debe aportar y explotar aquello que no puede aportar la tecnología por sí sóla: el conocimiento.

En muchas organizaciones se nos presentan situaciones como las que comentaremos en este artículo. Si te identificas con alguna de ellas posiblemente puedas aplicar las sugerencias que te vamos proponer. ¿Se requieren escalados a grupos de soporte de mayor nivel del que debieran para poder ofrecer soluciones en la Gestión de Incidencias o la Gestión de Peticiones?

No obstante el primer punto a tratar es si eres capaz de detectar que esta situación esté sucediendo en tu organización. Si te ocurre que técnicos del nivel de soporte N no disponen del conocimiento necesario y tienen que recurrir en exceso a los grupos de soporte de nivel N+1. Para poder detectar esta situación deberemos definir claramente qué tipo de incidencias y peticiones debe ser capaz de resolver cada nivel de soporte. Para ello, es conveniente que, en el proceso de Gestión de Problemas, se revisen los históricos de incidencias y peticiones, pero no sólo patrones de repetición en cuanto a los fallos o las solicitudes de los usuarios, sino también patrones de repetición respecto a escalados a un nivel no adecuado.

Si asignas esta tarea a la Gestión de Problemas podrás tratar estas situaciones con el flujo normal de detección, análisis de la causa raíz, proposición de solución y ejecución de la solución que sugiere ITIL y que combina Gestión de Problemas y Gestión de Cambios.

Si la Gestión de Problemas detecta esta situación podremos identificar qué grupos de soporte no tienen el conocimiento necesario para atender las incidencias y las peticiones que deberían ser capaces de resolver según lo definido inicialmente.

Con esta información deberemos preparar los recursos de conocimiento necesarios: artículos de la KB, procedimientos de trabajo, listas de comprobación, etc. Debemos ponerlos a disposición de los técnicos, por ejemplo, incluyéndolos en la aplicación que soporte la Gestión de Incidencias y la Gestión de Peticiones o bien publicándolos en la intranet del departamento de TI. A su vez, hay que comunicar a los técnicos su existencia, para que sepan que los tienen a su disposición y los pueden y deben utilizar. En el próximo artículo continuaremos comentando más situaciones típicas.

Leer siguiente post sobre Gestión del Conocimiento y mejora continua 2/3.

José Luis Fernández Piñero
Leer más
9 Ene

Motivos para tener una CMBD

tenerunacmbd¿Pretendes implantar procesos ITIL y te estás preguntando para qué sirve una CMDB? Antes de plantearnos implantar una CMDB deberíamos reflexionar sobre sus ventajas y el valor que realmente nos aporta. En este artículo te explicamos cuál es su verdadera transcendencia.

ITIL propone un buen número de procesos para estructurar las distintas actividades que sustentan la prestación y gestión de servicios de TI de calidad. Uno de los procesos, Gestión de la Configuración y Activos del Servicio (SACM), incluye explícitamente el concepto de CMDB, tan de moda hoy en día.

Pero, antes de entrar en materia, debemos definir qué es una CMDB, algo que va más alla de un simple inventario de tecnología. Se trata de un repositorio de información a partir del cual se modela toda la prestación y gestión de servicios de TI, en el que se guarda tanto información tecnológica como de negocio. Por ejemplo incorpora cuáles son los servidores que utilizamos, qué servicios sustentan dichos servidores y cuáles son las relaciones con otros elementos clave, como los procedimientos de trabajo o acuerdos de nivel de servicio.

Una CMDB, como cualquier otro repositorio de información, sólo aporta valor cuando se consulta, en cambio, el coste de tener y mantener nuestra CMDB estará presente desde el primer momento. Por lo tanto, el primer consejo que podemos dar es que la CMDB y el proceso de Gestión de la Configuración y Activos del Servicio no deben ser el primer proceso a implantar, precisamente porque la CMDB aporta valor cuando se consulta desde las actividades propias de otros procesos:

  • Desde Gestión de Incidencias, para trazar los elementos relacionados con los que muestra el síntoma de un fallo, pudiendo averiguar dónde se encuentra para proponer una solución alternativa.
  • Desde Gestión de Problemas, para analizar con detalle los elementos relacionados con los activos que muestran fallos recurrentes e identificar aquellos activos que verdaderamente son la causa raíz.
  • Desde Gestión de Cambios, para analizar el impacto de las modificaciones en la infraestructura utilizada para prestar servicios.

Sin embargo, si implanto los procesos de manera progresiva y el primero es Gestión de la Configuración y Activos del Servicio, no obtendré ningún beneficio porque no tendré ningún proceso desde el que se consuma la información, pero ya estaré soportando el coste de implantación y mantenimiento de la CMDB desde el primer momento. Por este motivo, es mejor empezar por otro proceso y dejar la CMDB para más adelante.

Casi da igual qué proceso implantemos antes que Gestión de la Configuración y Activos del Servicio, porque todos los procesos se aprovechan de la CMDB. Así que implantemos primero uno o dos procesos (por ejemplo Gestión de Incidencias y Gestión de Peticiones) y después Gestión de la Configuración y Activos del Servicio con su CMDB.

Eso sí, cuando implantemos nuestra CMDB debemos estar listos para implantar a la par Gestión de Cambios, pero eso lo trataremos en otro artículo.

José Luis Fernández Piñero

Leer más
14 Dic

Estrategias para identificar problemas II

estrategiasparaidentificarprobleamasDentro del marco ITSM Software la Gestión de Problemas es un aspecto fundamental. Identificar correctamente los problemas que se van a gestionar en busca de mejoras perceptibles en la calidad de la prestación de servicios es crítico.

En un artículo anterior explicamos cómo identificar los problemas cuya solución sería más eficaz para mejorar la Gestión de Incidencias. Otro proceso susceptible de mejora es la gestión de cambios ¿Cómo podemos priorizar los problemas para gestionar antes aquellos cuya solución tiene un mayor ROI?

Para mejorar la Gestión de Cambios.

a) Definir una lista de comprobación (checklist) que se aplicará de manera sistemática en todos los cambios cuando se cierren. Lo ideal es que tenga la forma de preguntas con respuesta sí/no (tal vez debamos tener distintas checklist en función del tipo de cambio). b) Revisar periódicamente los cambios agrupándolos por las respuestas a cada pregunta de la checklist para poder identificar aquellos que sugieren una oportunidad de mejora. Por ejemplo, el porcentaje de cambios tiene respuesta “sí” a las preguntas ¿la planificación fue adecuada? o ¿las pruebas fueron suficientes? c) Aplicar el principio de Pareto sobre los datos de b) para identificar las áreas de mejora (por ejemplo la planificación de las actividades o los recursos dedicados a pruebas)

La lista c) nos dará una idea de qué debemos cambiar a la hora de la gestión de cambios para que estos sean más efectivos. Este es, por tanto, el “input” para generar registros de problemas cuya resolución mejore la realización de cambios de manera efectiva. Como se puede apreciar, que la checklist sea adecuada es la clave del éxito de este método.

¿Cómo podemos elaborar la checklist para que sea efectiva? La respuesta es sencilla: busquemos los cambios cuya realización ha provocado incidencias. Veamos un ejemplo:

Supongamos que tenemos un cambio en el que había que migrar una aplicación de un servidor a otro. Se realiza la migración y la aplicación ya está funcionando en el nuevo servidor. Sin embargo, una semana después de realizar el cambio se empiezan a generar incidencias donde hay usuarios que reportan que una aplicación que leía información de la que fue migrada, ahora muestra un mensaje de error. Las incidencias están provocadas por una dependencia entre las dos aplicaciones que no se conocía o no se tuvo en cuenta.

Si trazamos el cambio con las incidencia que provocó y hacemos lo mismo con cada cambio que provoque incidencias, tendremos un buen punto de partida para identificar las preguntas y saber lo que debe contener la checklist. En este caso podrían ser:

  • ¿El análisis del impacto fue efectivo?
  • ¿Si el análisis del impacto no fue efectivo, se debe a que la CMDB no representaba todas las relaciones entre los activos?

De esta manera hemos visto cómo definir una checklist que utilizaremos para identificar las oportunidades de mejora en los cambios que podremos abordar mediante la Gestión de Problemas.

José Luis Fernández Piñero

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=