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 Problemas’

15 Jun

Los riesgos son errores conocidos…

riesgos

… o al menos muchos de ellos lo son, sobre todo los más ligados a la tecnología y la infraestructura que subyace bajo los servicios. Así que mira que bien, tenemos un dos por uno, gestión de riesgos y gestión de problemas (más o menos) por el mismo precio.

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
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
24 Abr

Encuestas, correlación y acciones de mejora (3 de 3)

chart2Para prestar servicios de TI de manera competitiva es necesario comprender el punto de vista de nuestros usuarios y clientes, especialmente en algo tan relevante como su grado de satisfacción. En este artículo explicaremos cómo enfocar esto apoyándonos de sencillas herramientas estadísticas.

Continuamos lo indicado en el artículo anterior intentando mejorar la propuesta de análisis de la satisfacción según distintas preguntas de una encuesta usando una encuesta que ofrece respuestas a cuatro preguntas.

En la siguiente tabla vemos los resultados de las preguntas por las dimensiones (P1, P2 y P3), la pregunta por el constructo (P4) y el coeficiente de correlación de Pearson entre las preguntas P1, P2 y P3 y la pregunta P4. 

P1

P2

P3

P4

4

3

4

4

3

2

4

3

4

0

4

4

1

5

4

2

4

2

3

4

4

2

4

4

1

1

3

1

2

4

5

3

M

2,88

2,38

3,88

Cor

94,72%

-18,86%

22,27%

Como dijimos en el artículo anterior, el valor más alto del coeficiente de correlación nos permite saber la pregunta (dimensión) que más correlaciona con la satisfacción. En nuestro caso, la dimensión que analice la pregunta P1 es la que más aproxima el resultado de la satisfacción en general (que aparece en la pregunta P4). 

Si el lector tiene conocimientos de estadística, por favor, lea la nota 1 al final del artículo.

Conocido esto, la pregunta es: ¿qué podemos hacer para aprovechar este hecho y mejorar la satisfacción de los usuarios y clientes?

En mi opinión, intentaría dos cosas:

  • Lo primero sería mantener lo que se proponía en la primera parte del artículo: calcular la pregunta que peor promedia (dato M) y emprender acciones de mejora en ella. Sin duda los clientes están muy poco satisfechos en ese aspecto y merecen que pongamos el foco para mejorar ahí.

  • Lo segundo sería identificar la pregunta con mayor correlación e intentar acciones de mejora en ella. No podemos estar seguros de que obtengamos un aumento de la satisfacción (lea la nota 2 al final del artículo) pero a priori parece un posible quick win para conseguir una mejora rápida.

Terminamos el artículo recordando que el autor es ingeniero, no matemático, y por tanto utiliza la estadística como una herramienta para buscar soluciones razonables, no verdades absolutas ni teorías científicas que requieran una dedicación de tiempo y recursos inasumibles por un departamento de TI al uso.

NOTA 1

Correlación no implica causalidad (que donde haya un atasco sea un probable ver un policía de tráfico no nos permite asegurar que la presencia de un policía de tráfico provoca un atasco). Este artículo lo explica muy bien.

Sin embargo, en nuestro caso, al calcular la correlación entre un constructo y sus dimensiones parece menos temerario afirmar que exista una relación de causalidad.

NOTA 2

No podemos garantizar que una dimensión tenga una oportunidad de mejora infinita, por eso no podemos garantizar que insistir en la dimensión con mayor correlación provoque una mayor satisfacción.

Para entender esto suponga que usted tienen un negocio de alquiler de coches y que el aspecto que más correlaciona con la satisfacción es la potencia de los coches. Si usted alquila coches de 100 CV y pasa a alquilar coches de 150 CV quizás la satisfacción mejore, pero si alquila coches de 200 CV y pasa a alquilar coches de 400 CV quizás no note mejoría alguna en la satisfacción porque sus clientes no aumentan su valoración a partir de cierto límite.

Sin embargo, es cierto que sin más datos tampoco podemos afirmar lo contrario, por lo que no debemos dejar pasar la oportunidad de intentarlo (aunque sea pilotanto una acción de mejora en un subconjunto de los usuarios y clientes) para ver si se confirma y, en caso afirmativo, generalizar la mejoría al resto.

 José Luis Fernández

Leer más
22 Abr

Encuestas, correlación y acciones de mejora (2 de 3)

chart3Para prestar servicios de TI de manera competitiva es necesario comprender el punto de vista de nuestros usuarios y clientes, especialmente en algo tan relevante como su grado de satisfacción. En este artículo explicaremos cómo enfocar esto apoyándonos de sencillas herramientas estadísticas.

Continuamos lo indicado en el artículo anterior intentando mejorar la propuesta de análisis de la satisfacción según distintas preguntas de una encuesta.

Vamos a modificar ahora el enfoque haciendo un cambio muy sencillo: además de hacer P1, P2 y P3 preguntas para valorar el constructo C, vamos a preguntar directamente por el constructo C. 

Es decir, si en el ejemplo del artículo anterior P1 era “valore entre 0 (nada satisfecho) y 5 (muy satisfecho) el plazo de resolución de sus incidencias y peticiones”, ahora añadiremos P4 que será “valore entre 0 (nada satisfecho) y 5 (muy satisfecho) su satisfacción en la gestión de incidencias y peticiones que brinda el helpdesk”.

El resultado es que preguntamos tanto por las dimensiones en que hemos descompuesto el constructo como por el propio constructo.

En la siguiente tabla vemos los resultados de las preguntas por las dimensiones (P1, P2 y P3), la pregunta por el constructo (P4) y el coeficiente de correlación de Pearson entre las preguntas P1, P2 y P3 y la pregunta P4.

P1

P2

P3

P4

4

3

4

4

3

2

4

3

4

0

4

4

1

5

4

2

4

2

3

4

4

2

4

4

1

1

3

1

2

4

5

3

Cor

94,72%

-18,86%

22,27%

La diferencia de este método con el utilizado en la primera parte del artículo es que el constructo no lo calculamos nosotros promediando P1, P2 y P3, sino que tenemos un resultado directo dado por los encuestados que es P4.

Puede parecer un poco absurdo preguntar por las dimensiones si directamente preguntas por el constructo, pero la ventaja que tenemos ahora es que podemos ver qué dimensión correlaciona más con el constructo.

Esto nos permite saber qué pregunta aproxima mejor la satisfacción (aquella pregunta con un coeficiente de correlación más cercano al 100%). En este caso vemos que la pregunta P1 aproxima mejor la satisfacción y, por lo tanto, podemos suponer que lo que más valoran nuestros usuarios y clientes como satisfacción es la dimensión de la pregunta P1 (en nuestro ejemplo serían los plazos de resolución).

En la continuación de este artículo explicaremos cómo se puede explotar los datos de esta tabla para identificar oportunidades de mejora.

 José Luis Fernández

Leer más
10 Abr

Encuestas, correlación y acciones de mejora (1 de 3)

Chart1Para prestar servicios de TI de manera competitiva es necesario comprender el punto de vista de nuestros usuarios y clientes, especialmente en algo tan relevante como su grado de satisfacción. En este artículo explicaremos cómo enfocar esto apoyándonos de sencillas herramientas estadísticas.

Suponga que quiere conocer la satisfacción de sus usuarios y clientes. Medir la satisfacción, a diferencia de otro tipo de mediciones (por ejemplo el cumplimiento de los SLA), es más complejo porque no existe una definición universal de satisfacción y, ni siquiera, es un concepto fácilmente medible (no existe un voltímetro de la “satisfacción”).

El enfoque habitual es “descomponer” el concepto de satisfacción (formalmente denominado “constructo”) en varios aspectos (denominados “dimensiones”) como por ejemplo: cumplimiento de plazos, efectividad en la resolución de incidencias, etc.

Esto significa que para conocer la valoración de la satisfacción de nuestros usuarios y clientes les haremos preguntas para conocer su opinión sobre las distintas dimensiones y luego agruparemos estos resultados para conocer su opinión sobre el constructo original.

En la tabla siguiente hemos supuesto que P1, P2 y P3 son las preguntas que hemos hecho sobre tres dimensiones distintas para valorar el constructo C. Las respuestas a estas preguntas son números entre 0 y 5. El valor del constructo C no es más que la media de las respuestas.

Por ejemplo, C podría ser “satisfacción en la gestión de incidencias y peticiones que brinda el helpdesk” y P1 podría ser “valore entre 0 (nada satisfecho) y 5 (muy satisfecho) el plazo de resolución de sus incidencias y peticiones”.

P1

P2

P3

C

4

3

4

3,67

3

2

4

3,00

4

0

4

2,67

1

5

4

3,33

4

2

3

3,00

4

2

4

3,33

1

1

3

1,67

2

4

5

3,67

M

2,88

2,38

3,88

El método anterior tiene varias ventajas:

  • Es muy sencillo de aplicar.

  • La satisfacción se puede analizar en base a varias preguntas que se podrían plantear en una encuesta.

  • Podemos analizar cada dimensión (pregunta) por separado y encontrar puntos de mejora en aquellas preguntas (columnas) cuya media (valor M) sea menor. En nuestro ejemplo, claramente los aspectos relacionados con la pregunta P2 serían una gran oportunidad de mejora.

Por cierto, analizar los resultados de las encuestas podría ser un buen input para el proceso de Gestión de Problemas, que podría proponer los cambios necesarios para intentar mejorar la valoración en las preguntas peor puntuadas y que se refleje la mejora en futuras encuestas.

En la continuación de este artículo explicaremos cómo se puede mejorar el análisis anterior.

José 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
23 Ene

TPS y 5-whys

Uploaded to www.sxc.hu for free use.

Toyota no sólo es uno de los mayores fabricantes mundiales del sector de la automoción, también es uno de los líderes en optimización de procesos y mejora continua. ¿Cómo utiliza Toyota el método de los 5-whys?

Como empleado de Espiral Microsistemas, fabricante de ProactivaNET, figuro en el organigrama como Director de Ingeniería de Procesos.

Mi trabajo consiste en analizar los procesos de nuestra empresa y trabajar para mejorarlos en busca de la mejora continua. Fundamentalmente me dedico a la reingeniería de procesos identificando oportunidades de mejora y promoviendo las acciones necesarias para explotar esas oportunidades.

Además, completo mi tiempo como consultor ITSM de ProactivaNET, lo que no es más que el mismo tipo de trabajo pero con un ámbito más concreto, ya que ayudo a nuestros clientes a implantar procesos ITIL que mejoren su organización.

Debido a esto me encuentro permanentemente buscando fuentes de inspiración que me sugieran nuevos métodos o técnicas. El pasado sábado hice un descubrimiento que ha absorbido mi tiempo desde entonces: un libro que explica el TPS (Toyota Production System) llamado “Las claves del éxito de Toyota: 14 principios de gestión del fabricante más grande del mundo”.

Toyota no es sólo uno de los mayores fabricantes del sector de la automoción, también es un líder mundial en optimización de procesos y su método es aplicable a cualquier ámbito.

Todavía no he terminado el libro, pero he encontrado un ejemplo que me ha llamado tanto la atención que quise escribir este artículo. En el ejemplo se explicaba cómo los “5-whys” son un método para encontrar soluciones que combinan requisitos que parecen contrapuestos y que, a priori, se cree que no se puedan satisfacer a la vez.

En los años 90 Toyota era un fabricante de automóviles con un buen número de ventas en el mercado USA pero sin acceso al sector de los vehículos de lujo (Mercedes Benz, BMW, Jaguar, etc.). Entonces se propuso construir un vehículo de lujo que superase a los competidores y este fue el origen de la marca Lexus.

Entre otros requisitos, el primer Lexus debía tener un peso reducido (para ahorrar combustible) y una baja sonoridad dentro del habitáculo. Estos dos requisitos son, a priori, incompatibles porque la reducción de ruido suele conseguirse con material insonorizante que añade peso.

Entonces los ingenieros de Toyota empezaron a cuestionarse la causa raíz siguiendo el método de los 5-whys al que tanto hace referencia el TPS. Esto les permitió cambiar el enfoque pasando de tratar el síntoma (el ruido que requiere pesado material insonorizante) a la auténtica causa raíz (el motor, que es quien genera el ruido). La solución pasó entonces por rediseñar los motores para que generasen menos ruido en lugar de añadir pesado material aislante. Este ejemplo evidencia cómo identificar claramente la causa raíz permite aplicar soluciones eficaces, lo que es el núcleo de la Gestión de Problemas.

Seguro que en otros artículos del blog seguiré comentando aspectos interesantes extraídos de este libro, pero mientras tanto, si alguien tiene curiosidad sobre el resultado de ese “primer Lexus” puedo adelantaros que en pocos meses superó en ventas a sus competidores.

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
8 Jul

Problemas y no conformidades

Problemas y no conformidades

Si ha implantado un Sistema de Gestión de Servicios de TI según la norma ISO 20000-1 se habrá encontrado con la necesidad de gestionar problemas y no conformidades. ¿Qué relación hay entre estos conceptos? ¿Existen sinergias entre ambos?

La norma ISO 20000-1 utiliza la definición de no conformidad de la norma ISO 9000 (que no es la misma que la ISO 9001).

Según la norma ISO 9000 una No Conformidad es un incumplimiento de un requisito del sistema, sea este especificado o no. Se conoce como requisito una necesidad o expectativa establecida, generalmente explícita u obligatoria.

Es decir, una no conformidad es un incumplimiento de lo que la norma (la ISO 20000-1 en este caso) nos exige como requisito o bien lo que nos hayamos autoimpuesto como consecuencia de un requisito.

Por ejemplo, la norma ISO 20000-1 exige la existencia de un procedimiento documentado para registrar, clasificar, evaluar y aprobar las solicitudes de cambio (epígrafe 9.2). Si no hemos definido este procedimiento tendremos una no conformidad, pero si lo hemos definido y no lo aplicamos, también tendremos una no conformidad.

Las no conformidades pueden detectarse de manera espontánea o porque hayamos dedicado recursos a identificarlas. Una auditoría no es más que una búsqueda sistemática de no conformidades. No obstante, que detectemos no conformidades no es algo malo en sí mismo, ya que las no conformidades son realmente oportunidades de mejora. Lo preocupante sería ignorarlas porque entonces no haríamos nada por mejorar y viviríamos felices en la mediocridad.

Por otra parte, la norma ISO 20000-1 define un problema como la causa raíz de una o más incidencias. En otros artículos como los que señalo a continuación:

he propuesto el uso de la Gestión de Problemas como mecanismo genérico para la mejora continua más allá de la lucha por evitar incidencias repetitivas.

De hecho, mi propuesta es considerar un problema como cualquier tipo de oportunidad de mejora y, entonces, utilizar las no conformidades detectadas como otro input para la Gestión de Problemas. De esta manera, podremos satisfacer los requisitos de la norma ISO 20000-1 respecto a la gestión de no conformidades según una sistemática ya conocida en la organización y tratar la mejora continua de manera homogénea.

Por último, si recurrimos a la norma ISO 9001 (epígrafe 8.5.2) veremos cómo la gestión de no conformidades es idéntica a la Gestión de Problemas.

“Debe establecerse un procedimiento documentado para:

a) revisar las no conformidades

b) determinar las causas de la no conformidades

c) evaluar la necesidad de adoptar acciones para asegurarse de que las no conformidades no vuelvan a ocurrir

d) determinar e implementar las acciones necesarias

e) registrar los resultados de las acciones tomadas

f) revisar la eficacia de las acciones correctivas tomadas”.

José Luis Fernández Piñero

Leer más
4 Jul

#ITILGlossary – Problema

ITIL Glossary-Problema.

ITIL Glossary-Problema.

Éste es uno de los conceptos en los que muchas veces se comenten más errores, al pensar que un problema es una “incidencia grande”, cuando realmente no tiene por qué ser así. Los problemas surgen de incidencias reiteradas, que se repiten en el tiempo, y para las que nos interesa analizar la causa raíz y darles solución definitiva. ¿Qué es mejor, estar constantemente resolviendo la misma incidencia, o analizar el por qué de ese tipo de incidencias, y atajarlas desde su causa raíz para que desaparezcan? Claramente lo segundo… Si realmente implantamos una buena gestión de problemas, estaremos dando un paso fundamental en la reducción delas incidencias, lo cual tendrá un impacto directo en la calidad del servicio que prestamos a nuestra organización. Con este planteamiento de que un problema surge ante la repetición de incidencias, hay que tener en cuenta que: (a) una incidencia nace y muere incidencia, y nunca se convierte en problema, aunque puede ser el origen de los mismos; (b) un problema no es una incidencia de tipo problema, son cosas distintas, y como tal, requieren flujos y ritmos específicos para cada uno de ellos.

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=