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

Publicaciones etiquetadas ‘Gestión de Incidencias’

28 Jun

Super Equipo ELS

hands-1939895_1280

ELS, o lo que es lo mismo, Early Life Support, es un equipo que podrá librarnos de muchos rompederos de cabeza, y mejorar enormemente nuestra capacidad de soporte en los primeros momentos después de la puesta en producción de un nuevo servicio, o tras una importante modificación de alguno de ellos.

Leer más
25 May

Concepto de problema

concepto de problema

Impartiendo formación sobre ITSM encuentro de manera recurrente alumnos que no interpretan correctamente el concepto de problema y que lo mezclan con el concepto de incidencia. Intentaremos aclarar las dudas más habituales para luchas contra este error de concepto.

Leer más
4 May

Concepto de servicio

Concepto de servicio

Impartiendo formación sobre ITSM encuentro de manera recurrente alumnos que no interpretan correctamente el concepto de servicio y que lo confunden con algunos procesos o funciones típicas en la Gestión de Servicios de TI. Intentaremos aclarar las dudas más habituales para luchas contra este error de concepto.

Leer más
24 Jun

LEAN, TPS y mejora continua en ITSM (2 de 2)

Striped_8_ball

Este artículo enumera los tipos de desperdicio que las técnica de Lean Management pretenden eliminar. Quizás vea reflejada aquí alguna actividad de su organización sobre la que pueda aplicar una acción de mejora. ¿Se reconoce en los ejemplos? Si es así felicidades. Acaba de dar el primer paso para mejorar.

Leer más
17 Jun

LEAN, TPS y mejora continua en ITSM (1 de 2)

sapling-154734_640  

Este artículo enumera los tipos de desperdicio que las técnica de Lean Management pretenden eliminar. Quizás vea reflejada aquí alguna actividad de su organización sobre la que pueda aplicar una acción de mejora. ¿Se reconoce en los ejemplos? Si es así felicidades. Acaba de dar el primer paso para mejorar.

La aplicación del Lean Management a la Gestión de Servicios de TI es un tema muy de moda y sobre el que hay extensa literatura en internet al respecto (por ejemplo aquí y aquí).

 Sin embargo, aunque todo esto suene a algo muy nuevo es bastante más viejo. La búsqueda de la eliminación del desperdicio, el núcleo de los enfoques LEAN, está en el centro de la filosofía y la metodología de trabajo de Toyota.

El TPS  incluye como actividad fundamental para la mejora la continua eliminación del muda, es decir, la eliminación de todo aquello que es desperdicio y, por tanto, no aporta valor añadido.

 Jeffrey K. Liker enuncia en su libro sobre el TPS las ocho categorías del muda, es decir, los ocho tipos de actividades que no aportan valor y que deberíamos esforzarnos en eliminar de nuestros procesos, que son:

  1. Sobreproducción.
  2. Esperas evitables.
  3. Movimientos innecesarios de los productos.
  4. Sobreprecesado.
  5. Exceso de inventario.
  6. Movimientos innecesarios de los empleados.
  7. Defectos de calidad.
  8. Creatividad desaprovechada.

El mero hecho de repasar estos ocho tipos de actividades a evitar seguro que le permite identificar alguna que está sucediendo en su organización y sobre la que podría poner el foco para la mejora continua. Sin embargo, se me acaba el espacio en este artículo, así que tras esta introducción que espero haya despertado su interés, dejaremos para una segunda parte repasar estas ocho categorías con detalle.

Jose Luis Fernández

Leer más
25 Mar

JIT, inventario de seguridad e ITIL (2 de 2)

diana_blog_ProactivaNET2En una serie de dos artículos presentaremos primeramente el concepto de producción JIT frente al uso más tradicional de un inventario de insumos a modo de margen de seguridad para la producción para, a continuación, explicar un ejemplo de cómo trasladar el concepto JIT y sus ventajas a una actividad propia de la Gestión de Incidencias como es el escalado a tercera línea de incidencias.

En la primera parte de este artículo explicamos que la producción JIT permitía, entre otras cosas, evidenciar los fallos tan pronto ocurren y obligaba, por tanto, a resolverlos de manera rápida ya que en caso contrario se para la producción.

Una ventaja del JIT es, por tanto, que obliga a la mejora continua previniendo fallos y evitando, en caso de que sucedan, su repetición. Esta es, sin duda, la esencia de la mejora continua (“kaizen”, en la terminología Toyota) y, en el mundo ITIL, el proceso de Gestión de Problemas.

Después de una primera parte del artículo alejado de ITIL y otros marcos para la Gestión de Servicios de TI, pasaremos a explicar como el concepto JIT puede extrapolarse a otros ámbitos. Vamos a poner un ejemplo muy concreto en el concepto de escalado de incidencias.

Suponga que usted tiene un grupo de soporte que realiza escalados jerárquicos y funcionales a grupos de un nivel superior cuando es incapaz de resolver la incidencia por falta de tiempo o de conocimiento.

Esta idea, sumamente habitual y recomendada, puede provocar al igual que el almacenamiento de insumos como medida preventiva que se escondan fallos y situaciones que deberíamos corregir pero que incluso nos cuesta detectar.

Pensemos por un momento que el grupo de soporte al que hacíamos mención tiene un nivel de conocimiento insuficiente sobre cierta materia y que, por tanto, permanentemente está haciendo escalados funcionales a otro grupo cuando se encuentre una incidencia relacionada. Pensemos también que podría suceder que ese mismo grupo de soporte esté sobrecargado y que, constantemente, deban realizar escalados jerárquicos para evitar que las incidencias incumplan los SLA.

Fíjese que en ambos casos, la existencia de los grupos a los que realizar los escalados jerárquicos o funcionales está ocultando un problema que es la sobrecarga de trabajo o la falta de capacitación del grupo que siempre debe recurrir a los escalados y, mientras no actuemos para corregirlo, estaremos asumiendo el sobrecoste de utilizar más grupos y más personal para resolver incidencias del que tendría que ser necesario.

Una interpretación estricta del método JIT nos sugiere que no deberían existir grupos a los que realizar escalados jerárquicos o funcionales para que, en caso de existir falta de capacidad en el grupo de soporte que atiende las incidencias, esta se haga evidente y así podamos ser conscientes del problema y actuar para resolverlo.

No le negaré que por mucho que me guste el concepto JIT y el TPS esta opción me parece inasumible porque en este caso, lo mejor puede ser enemigo de lo bueno. Es decir, hacer que sean evidentes las incapacidades de ese grupo de soporte puede provocar incumplimientos graves de los SLA que tengan consecuencias serias en forma de penalización económica o mala imagen frente al cliente.

Sin embargo, no tenemos por qué resignarnos a no aplicar el TPS ya que este también acepta la flexibilidad en su interpretación, llegando incluso a admitir que la existencia de cierto inventario de seguridad puede mejorar la calidad entregada al cliente, como sucede en nuestro ejemplo de los escalados al tener como “inventario de seguridad” los grupos a los que realizar el escalado jerárquico o funcional.

Eso sí, no debemos permitir que los fallos permanezcan ocultos o en ese caso nos será imposible la mejora continua (“kaizen” en terminología Toyota) y tendremos que asumir como inevitable el sobrecoste de utilizar personal en exceso para resolver las incidencias.

Por eso aquí recomendaría una combinación de dos principios: no se conoce lo que no se mide y utiliza el control visual siempre que sea  posible, este último también un principio del TPS que no es más que la plasmación de que una imagen vale más que mil palabras.

Por lo tanto, lo que recomendaría es tener siempre sobre observación los escalados de incidencias entre grupos para detectar situaciones inadecuadas como sobrecarga de un grupo que provoca muchos escalados jerárquicos o falta de conocimiento de un grupo que provoca muchos escalados funcionales.

Pero esta observación debe ser ágil y sencilla, por lo que nada mejor que algo que permita supervisión visual, como por ejemplo unas métricas del dashboard de ProactivaNET

Por último comentar que esta situación la hemos vivido en el soporte de ProactivaNET y que, para poder identificar fácilmente los grupos de soporte que estaban sobrecargados o que requerían formación no quedó más remedio que quitar esa “red de protección” a modo de “almacén de seguridad” que era el ámbito de responsabilidad compartido sobre las incidencias entre todas las oficinas.

En el momento en el que las distintas oficinas con personal de soporte se responsabilizaron de su ámbito geográfico en exclusiva, cuando una oficina era incapaz de resolver su trabajo podía realizar un escalado jerárquico o funcional (así garantizábamos la atención a nuestros clientes). Pero bastó con hacer esta situación explícita para que se pudiese identificar con facilidad los cuellos de botella sobre los que aplicar las acciones de mejora y, por tanto, avanzar hacia una mejor calidad en la atención a nuestros clientes aplicando la mejora continua.

 José Luis Fernández

Leer más
20 Mar

JIT, inventario de seguridad e ITIL (1 de 2)

diana_blog_ProactivaNET

En una serie de dos artículos presentaremos primeramente el concepto de producción JIT frente al uso más tradicional de un inventario de insumos a modo de margen de seguridad para la producción para, a continuación, explicar un ejemplo de cómo trasladar el concepto JIT y sus ventajas a una actividad propia de la Gestión de Incidencias como es el escalado a tercera línea de incidencias.

El concepto de producción JIT (“just in time”) hace referencia a un paradigma de producción industrial donde en una secuencia de pasos el paso N sólo genera material que sirve de insumo al paso N+1 cuando este lo requiere.

Este enfoque se caracteriza por la producción bajo demanda y la no existencia de material almacenado a modo de inventario de seguridad. La clave aquí es que el paso N no produce si el paso N+1 no lo requiere para trabajar.

El método JIT ofrece dos ventajas que me interesa resaltar:

  • al no existir producción sin consumo ni productos almacenados en espera de que sean usados se reducen los costes de operación

  • en caso de existir algún fallo este se vuelve visible de inmediato por lo que su corrección se vuelve prioritaria

Pongamos un ejemplo para explicar la primer ventaja: Supongamos que su familia viaja en automóvil y que, en lugar de comprar gasolina cada vez que hay que llenar el depósito, todos los años comprase el 1 de enero la gasolina que estima que utilizará ese año.

La existencia de ese almacén de producto tiene varios inconvenientes. No obstante, resaltaremos uno menos obvio: ¿qué coste tiene para usted almacenar toda esa gasolina?

Un automóvil estándar tiene un consumo medio de unos 7 litros cada 100 km. Suponga que hace 21.000 km al año y descubrirá que necesita 1.470 litros. Para almacenar ese volumen y suponiendo que tiene un depósito en su propia casa de un metro de altura este deberá tener aproximadamente 1,5 m2 de superficie.

Si vive en España, donde el m2 de una vivienda nueva está sobre unos 2.000€, descubrirá que ha pagado 3.000€ para comprar el sitio suficiente donde guardar la gasolina. Quizás quiera argumentar que por comprar tanta gasolina a la vez consigue un precio mejor, pero eso se puede calcular. Un litro de gasolina cuesta aproximadamente 1,50 €, por lo que si compra 1.470 litros a ese precio pagaría unos 2.200€. Suponga que consigue una rebaja del 20% del precio (cosa que dudo mucho) y se habrá ahorrado 440€. Necesitará repetir esto cinco años antes de conseguir compensar los costes.

No obstante, piense que durante ese tiempo usted incurre en el riesgo de tener almacenado en su casa un material inflamable y, por otra, parte que si cambia su vehículo por otro con motor diesel deberá buscar qué hacer con la gasolina sobrante.

El ejemplo anterior puede extrapolarlo al almacenamiento de insumos en cualquier fábrica, la complejidad inherente a la logística necesaria para preservar y gestionar el stock (carretillas elevadoras, salas con temperatura especial, seguridad contra robo, etc.) y la falta de flexibilidad en la producción al tener un material almacenado que, si no es utilizado, deberá ser destruido o, en el mejor de los casos, reprocesado o incluso malvendido.

Pongamos un ejemplo para explicar la segunda ventaja: Supongamos que usted fabrica sillas tapizadas y dispone de un almacén con tapizados que utilizan los obreros que realizan el montaje de la silla. Si la fabricación de los tapizados falla usted vive tranquilo porque los obreros que montan las sillas utilizan los tapizados almacenados para seguir fabricando sillas sin verse afectados por el fallo previo.

Podemos decir que el material almacenado como un inventario de seguridad actúa como cortafuegos de manera que aísla a una unidad de producción de los fallos de las anteriores.

Sin embargo, esta característica a priori tan beneficiosa se vuelve en su contra en varios casos de los cuales me interesa resaltar uno: ¿qué sucede si el operario que fabrica los tapizados no hace más que tener fallos? Como usted dispone de stock suficiente de tapizados en ese inventario de seguridad para fabricar las sillas seguramente este problema recurrente no llamará la atención y difícilmente se verá motivado a averiguar la causa raíz y solventarlo.

Esto significa que ese cortafuegos que es el inventario de seguridad se convierte también en un paraguas bajo el que esconder los fallos.

Por lo tanto, el método JIT ofrece reducción de costes pero, lo que más me interesa resaltar, fuerza a que las dificultades y los fallos salgan a la luz y nos obliga a solucionarlos, ya que en caso contrario la producción se para. Si necesitaba motivación para la mejora continua no creo que encuentre uno mejor que evitar que se pare la producción y no se puedan satisfacer los pedidos.

Quizás pueda parecer muy drástico, pero el método JIT es una de las herramientas de producción “lean” que tan buen éxito le dan a Toyota dentro de su TPS (Toyota Production System).

En la segunda parte de este artículo explicaremos qué tiene que ver el método JIT y la ausencia de inventario de seguridad con el escalado de incidencias.

José Luis Fernández
Leer más
16 Ene

Prioridad, impacto y urgencia (2 de 2)

urgent ITIL explica qué se entiende por prioridad, impacto y urgencia. En este artículo intentaremos poner ejemplos de cómo utilizar estos conceptos en la práctica.

En un artículo anterior explicamos cómo llevar a la práctica la priorización utilizando directamente el concepto prioridad. Ahora vamos a ver cómo realizar una priorización más compleja en base a dos dimensiones: impacto y urgencia.

Si queremos ayudar a que nuestros técnicos de primera línea rellenen la prioridad con criterios objetivos podemos dar un paso más sobre lo propuesto en la primera parte de este artículo y, en lugar de confiar en una descripción para cada valor de prioridad, exigir que cada prioridad se describa como una combinación de impacto y urgencia.

Esto significa que lo primero que hay que hacer es definir los impactos que nos interesa utilizar. Nuevamente, olvídese de nombrar los impactos y esfuércese en definirlos. Por ejemplo, si establecemos un impacto ALTO, asegúrese de concretar cuándo debe elegirse ese impacto y en qué se diferencia de un posible impacto BAJO. Del mismo modo, deberemos definir las urgencias.

La pregunta ahora es ¿qué consideraremos un impacto y qué consideraremos una urgencia? Mi consejo es que consideremos como valores de impacto cómo se ven afectados los usuarios o la organización por el error reportado en la incidencia. Por otra parte, consideremos como valores de urgencia los plazos límite que puedan existir para la resolución de la incidencia.

Es interesante resaltar que en muchas organizaciones simplifican excesivamente el concepto de prioridad igualando este concepto a lo que realmente sería la urgencia.

A continuación ponemos unos ejemplos de valores de impacto centrados en el número e importancia de los usuarios afectados así como los servicios. Es necesario que tengamos bien definidos cuáles son los usuarios VIP y los servicios críticos.

  • Afecta a un usuario VIP o un servicio crítico.
  • Afecta a muchos usuarios.
  • Afecta a un único usuario.

Estos son unos ejemplos de valores de urgencia en función de los plazos disponibles:

  • Impide la realización de un trabajo urgente.
  • Existe una fecha límite.
  • No es urgente.

Es interesante resaltar que el hecho de impedir la realización de un trabajo urgente puede pensar que está asociado a un servicio crítico pero no tiene por qué ser así. Por ejemplo, el sistema de nóminas que utiliza RRHH quizás no sea un servicio crítico, pero si el día que hay que emitir las nóminas no tenemos acceso entonces es algo que afecta a un usuario (la persona que emite las nóminas) pero que impide la realización de un trabajo urgente (pagar a los empleados).

Si queremos, podemos dar nombre a los impactos y las urgencias. Por ejemplo, los tres impactos y urgencias anteriores podrían ser respectivamente ALTO, MEDIO y BAJO. Pero aunque les demos un nombre, lo importante es asociarles una descripción que nos aclare cuándo hay que elegirlos.

Con este enfoque la prioridad si que puede ser una palabra sin necesitar una descripción, ya que la prioridad se calcula en función del impacto y la urgencia que se combinan en una matriz de priorización similar a la siguiente, por lo que los técnicos de primera línea no tienen por qué saber cómo se escoge la prioridad, sólo tienen que saber escoger correctamente el impacto y la urgencia.

 matriz-priorizacic3b3n

Espero que estos dos artículos hayan servido para sugerir posibles enfoques para priorizar incidencias, ya sea mediante el uso directo del concepto prioridad o mediante la combinación de impacto y urgencia para calcularla.

José Luis Fernández
Leer más
14 Ene

Prioridad, impacto y urgencia (1 de 2)

urgent2

ITIL explica qué se entiende por prioridad, impacto y urgencia. En este artículo intentaremos poner ejemplos de cómo utilizar estos conceptos en la práctica.

En artículos anteriores se explicó el concepto teórico de prioridad, impacto y urgencia. Vamos a ver ahora cómo llevar esto a la práctica.

Para que la explicación resulte más útil y concreta, vamos a suponer que queremos formalizar la priorización de las incidencias.

Priorizar una incidencia es algo que, típicamente, realizarán los técnicos de primera línea cuando la crean (por ejemplo si el usuario reporta la incidencia por teléfono) o cuando la recepcionan en un buzón (por ejemplo si el usuario reporta la incidencia directamente en el portal de usuarios).

Sin embargo, para que los técnicos de primera línea asignen la prioridad correctamente debemos definir unos criterios claros y sin ambigüedad.

Para definir estos criterios tenemos dos opciones: trabajar directamente con el concepto prioridad o dividir la prioridad en dos conceptos que son el impacto y la urgencia.

La teoría recomienda siempre la segunda opción, pero ProactivaNET Service Desk permite los dos enfoques según la madurez y la necesidad concreta de su departamento de TI.

Si hasta ahora no priorizaba las incidencias quizás le interese empezar utilizando sólo el concepto prioridad para no complicarlo en exceso. Eso sí, definir prioridades no es poner solo nombres, sino asociar situaciones a esos nombres.

Es decir, no se limite a “nombrar” tres prioridades (por ejemplo ALTA, MEDIA y BAJA) y esfuércese en “definirlas”. ¿Qué significa en su organización prioridad ALTA? ¿Qué debe pasar en una incidencia para ser considerado de prioridad ALTA? ¿En qué se diferencia de la prioridad MEDIA?

A continuación ponemos un ejemplo donde para cada prioridad damos una descripción concreta:

  • ALTA: Un servicio se ve afectado de manera severa impidiendo su uso y afectando a actividades críticas de negocio.

  • MEDIA: Un servicio se ve afectado impidiendo su uso pero no afectando a actividades críticas de negocio.

  • BAJA: Un servicio se ve afectado pero no impide su uso.

Lo anterior no es más que un ejemplo, pero podrá ver que en la descripción de cada prioridad se detalla claramente qué tiene que pasar para elegir esa prioridad y en qué se diferencian unas de otras. En el caso anterior lo único que quedaría por definir es cuáles son las actividades críticas de negocio.

Si queremos formalizar más el cálculo de la prioridad podemos, entonces, establecer una construcción de la prioridad en base a dos dimensiones (impacto y urgencia) tal y como veremos en la segunda parte de este artículo.

  José Luis Fernández

Leer más
29 Jul

Un cambio de tendencia (2/2)

Un cambio de tendencia 2

Un estudio de Deloitte afirma que en 2012, tras varios años de reducción de presupuesto que obligaban a TI a centrarse en reducir costes, por fin aparecen objetivos habilitadores: poder realizar cambios ágiles que posibiliten oportunidades de negocio y el crecimiento de las empresas.

En el artículo anterior mencionamos opciones para reducir costes minimizando el impacto en los servicios prestados y su calidad. Si su organización ya ha alcanzado el punto de inflexión de la crisis quizás el departamento de TI tenga como objetivo apoyar al máximo al negocio habilitando nuevas opotunidades.

El Catálogo de Servicios y los Acuerdos de Nivel de Servicio deben adecuarse a las necesidades reales de la organización. Dedique un tiempo a reflexionar para trazar los servicios de TI con los procesos de negocio y así evidenciar la componente aportada por los servicios respecto a la cadena de valor de su empresa.

Con estos datos en su mano podrá evidenciar la importancia de TI y, si durante la contracción hizo sus deberes, quizás haya llegado el momento de exigir más presupuesto o, al menos, que se reduzca la presión por la contención de costes.

Mejore la comunicación entre el departamento de TI y el resto de la organización. Las TI tienen una componente de innovación muy importante. No se limite a atender las peticiones de servicios de los demás departamentos, escuche sus necesidades del día a día e intente ofrecerles nuevas soluciones: gestione su Cartera de Servicios de manera proactiva.

Por último, no olvidemos que al departamento de TI se le exige agilidad para adaptarse: el “tempo” lo marca el “time to market” de negocio. Pero agilidad no debe significar caos ni, mucho menos, provocar una reducción de la calidad.

La Gestión de Cambios balancea estos criterios: permita y anime a la realización de cambios que apoyen al negocio, no los realice de cualquier manera pero tampoco imponga burocracia absura.

Clasifique los cambios y defina procedimientos distintos para la realización de cada cambio que dimensionen, de manera realista, las necesidades y características de las tareas previas (análisis de impacto, planes de contingencia, formación y comunicación, etc.), la ejecución (proceso de autorización, hitos de control, trámites burocráticos, etc.) y, finalmente, las actividades finales ajustando la PIR para  que aporte valor sin malgastar recursos.

Cualquier año es un buen año para lanzar proyectos de mejora como los que hemos sugerido anteriormente, sin embargo, intentar hacerlo todo a la vez es temerario y conduce al fracaso y la frustración. Elija, de lo dicho anteriormente, aquello que cree que aporta en su organización y, para cada mejora que quiera incorporar, priorícela para abordarlas de una en una.

 José Luis Fernández Piñero

Leer más
11 Jul

#ITILGlossary – OLA

ITIL Glossary-OLA.

ITIL Glossary-OLA.

El propio glosario incluye como traducción al castellano tanto “Acuerdo de Nivel Operativo” como “Acuerdo de Nivel Operacional”. Estos acuerdos internos con otros departamentos de nuestra organización que nos apoyarán en la prestación del servicio deberían gestionarse antes, o al menos al mismo tiempo, que los SLAs con los que los clientes y usuarios finales, de tal manera que garanticemos que vamos a poder cumplir el SLA final (obviamente, los OLAs deberán garantizar que podemos llegar a cumplir el SLA, ya que por ejemplo no tendría sentido acordar un SLA con un tiempo de resolución de incidencias de 4 horas, si por ejemplo el OLA que necesitamos tiene un tiempo mayor a esas 4 horas…) Aunque muchas veces no se les de un elevado grado de formalismo en departamentos que proveen servicios internos, resultan de gran ayuda para medir “dónde se nos va el tiempo” en procesos como la resolución de incidencias (asignar un OLA a cada grupo de soporte interno puede ser un buen método para conocer y medir mejor cómo resolvemos las incidencias, y por lo tanto, un punto de partida estupendo para detectar oportunidades de mejora).

Jandro Castro

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=