Diseño de un SGC según ISO 9001

Ya he hablado en otras entradas de este blog de los principios y fases de un proceso de implantación de un sistema de gestión de la calidad (SGC) según ISO 9001. También de la primera fase; la planificación. Para continuar con el ciclo, voy a dedicar esta entrada al diseño del sistema. La D del ciclo PDCA.

Una vez realizado el diagnóstico de la situación, después de haber logrado el compromiso efectivo de la dirección y tras haber llevado a cabo una buena planificación debemos pasar a la acción. En mi opinión hay 4 ingredientes imprescindibles es esta segunda fase: información a todo el personal de la organización, formación en gestión de la calidad adaptada a las necesidades de cada grupo de empleados, desarrollo de la documentación del sistema e implantación de los diferentes procesos de la empresa en base a la documentación desarrollada. Vamos a ver cada uno de estos 4 puntos con más detalle.

Información

En cualquier proyecto, un Director de Proyectos pasa la mayor parte de su tiempo gestionando las comunicaciones del proyecto. En un proyecto de implantación de un SGC ésto también es así. En esta fase es fundamental informar a todos los miembros de la organización de:

  • lo que se pretende conseguir,
  • el nivel de implicación que se espera de ellos,
  • cómo les va afectar el proyecto.

La información proporcionada debe ser adaptada al puesto de cada persona en la organización y debe mostrar el compromiso de la organización con el proyecto.

Comunicación con todos los interesados en el proyecto
Comunicación con todos los interesados en el proyecto

Fotografía cortesía de Paul Shanks bajo licencia CC BY-NC 2.0

Formación

La formación debe tener como objeto sensibilizar sobre la calidad en el trabajo y mejorar la comprensión del sistema de gestión, para que todos los afectados puedan comprender los cambios que se van a producir y actuar de forma favorable (o al menos no contraria) a los mismos.

Al igual que la información, la formación deberá adaptarse al puesto y responsabilidades de cada miembro de la organización. Su contenido y duración dependerán del tamaño de la organización pero también de su nivel de madurez en relación a la calidad.

Documentación

Una de las bases de la calidad es la estandarización. Una herramienta fundamental para la estandarización es la documentación, que un vehículo para lograr que las tareas se realicen siempre de la misma forma.

La documentación debe ser redactada en la forma más simple y comprensible, debe describir la forma correcta la forma de realizar las tareas, debe incorporar todo el conocimiento acumulado de la organización, informando de responsabilidades y relacionando unos procesos con otros.

Conforme se vayan redactando procedimientos (que son los documentos que describen los diferentes procesos de la organización) es bueno empezar con su implantación. No obstante, es importante remarcar que lograr la implantación requiere de mucho más tiempo que el de la simple redacción de los procedimientos, especialmente si se parte de un bajo nivel de madurez en relación a la calidad en la organización.

Implantación

Conforme se finaliza la redacción de los documentos y se arranca su puesta en marcha es preciso realizar una serie de actividades con objeto de fijar los nuevos procesos y cambios introducidos:

  • empezar a realizar las tareas cotidianas según se describe en los procedimientos e instrucciones,
  • realizar un seguimiento y verificar de forma distendida el nivel de aplicación,
  • corregir los procedimientos en base al feedback obtenido en el seguimiento.

¿Qué opinas de este modelo de diseño? ¿qué elementos utilizáis en tu organización?¿consideras que hay algún ingrediente importante que falte?

Diseño de un SGC según ISO 9001

Planificación de un proyecto de implantación y certificación de un SGC según ISO 9001

Ya he hablado en este blog sobre la metodología y los principios a seguir en un proceso de implantación de un Sistema de Gestión de la Calidad (SGC) según ISO 9001.

Ahora me gustaría tratar con algo más de detalle las fases a seguir en un proyecto de este tipo. En concreto, me voy a centrar en la fase de Planificación (la P del ciclo PDCA).

Bajo mi punto de vista, los hitos más relevantes son:

1. Diagnóstico de la situación.

2. Obtención del compromiso de la Dirección con la implantación. Definición de la política de la calidad

3. Elaboración de un plan de actuación para la implantación y la certificación.

Vamos a verlos ahora con más detalle.

Diagnóstico

En esta fase es conveniente revisar la forma como se está (o no se está) gestionando actualmente la calidad en la organización.

Cuando actuamos como consultores externos, es importante dedicarle el tiempo necesario a esta fase. Se trata de comprender lo mejor posible la forma como actualmente está trabajando la organización. Hay que preguntar mucho y escuchar de forma activa, hacer participar al máximo de personas que vayan a estar afectadas por el proyecto y ser muy empático.

En esta fase, y de acuerdo con la Dirección, podremos definir el alcance más adecuado para el sistema, el tiempo que se le va a dedicar y los recursos necesarios.

Pero también, mediante el diálogo con todos los implicados, deberemos ser capaces de detectar posibles elementos de resistencia al cambio y también  posibles riesgos que puedan dificultar la consecución de los objetivos del proyecto. Como consecuencia, uno de los resultados de esta fase será un listado de alto nivel de los riesgos del proyecto junto con posibles acciones a realizar en relación a ellos.

Compromiso de la Dirección

Para empezar, se debe obtener un compromiso formal de la Dirección en relación a la implantación. Ésto es básico y si no se logra es razón suficiente para no continuar con el proyecto. Uno de los primeros entregables debe ser la definición junto a la Dirección de una Política de Calidad.

También es necesario hacer un análisis de las necesidades de los clientes, establecer métodos para medir su nivel de satisfacción y planear cómo se va evaluar a proveedores (si no se estaba haciendo ya) y analizar cómo se tratan las incidencias y/o reclamaciones de los clientes.

Acabaremos esta fase fijando los objetivos de la calidad, de acuerdo con la Dirección y con los implicados en conseguirlos.

5222966685_92f9cdc084_o

Strategic Plan – cortesía de Alper Çuğun mediante licencia CC by 2.0

Elaboración de un plan de actuación

La implantación de un sistema de gestión de la calidad debe enfocarse como un proyecto. Debe tener un alcance definido, un presupuesto y un calendario.

Al igual que es fundamental obtener el compromiso de la Dirección, también es básico designar un responsable de dirigir este proyecto. Es conveniente que sea una persona de dentro de la organización, que sea buen conocedor de su cultura y de su estructura.

También es importante que este persona tenga un perfil que le permita liderar el proyecto y ser capaz de comunicarlo adecuadamente dentro de la organización. De hecho, probablemente la actividad a la que tenga que dedicar más tiempo dentro del proyecto sea la comunicación.

Es posible que internamente dispongamos de personas con este perfil pero que no tengan conocimientos sobre gestión de la calidad. Eso no es invalidante, bajo mi punto de vista. En caso de encontrarnos en esta situación será conveniente formar adecuadamente a la persona escogida y ayudarla con un consultor externo que aporte el conocimiento sobre la gestión de la calidad y la experiencia en su aplicación en otras organizaciones.

Doy por supuesto que la persona escogida está completamente comprometida con el proyecto y dispuesta a asumir el rol de agente de cambio en la organización, en complicidad con el consultor externo. Bajo mi punto de vista, tan importante es la aptitud como la actitud.

¿Qué opináis sobre la fase de planificación? ¿Cuál es vuestra experiencia al abordar este tipo de proyectos en vuestras organizaciones?

Planificación de un proyecto de implantación y certificación de un SGC según ISO 9001

Implementación útil de un sistema de gestión de la calidad ISO 9001

Voy a dedicar algunas entradas en el blog a describir el proceso de implantación de un sistema de gestión de la calidad, según ISO 9001, en una organización.

Principios básicos

Tanto cuando he trabajado dentro de una organización con la ayuda de consultores externos como ahora que me dedico a la consultoría externa, he procurado seguir una serie de principios que me han dado buenos resultados:

  • Implantación y liderazgo internos. El equipo de la empresa debe ser el artífice de la implantación y debe haber una persona dentro de la organización que lidere todo el proceso. En función del tamaño de la organización será preciso que se dedique en exclusiva o no a este proyecto.
  • Metodología didáctica y de mejora continua:
    • dedicación continua pero no excesivamente invasiva.
    • demostrar y convencer es mejor que imponer.
    • explicación clara y concisa de los motivos de los cambios que se deban realizar en la organización.
  • Lograr un sistema de gestión útil y lo más simple posible.

Fases de un proceso de implantación

Un sistema que me ha dado siempre buenos resultados consiste en utilizar el conocido proceso PDCA (Plan-Do-Check-Act). Se trata de seguir las siguientes fases:

ciclo PDCA y la mejora continua
ciclo PDCA y la mejora continua

Mejora continua y PDCA – cortesía de Wikipedia (lic CC)

1. Plan

Diagnóstico de la situación.

Obtención del compromiso de la Dirección con la implantación. Definición de la política de la calidad

Elaboración de un plan de actuación para la implantación y la certificación.

2. Do

Información al personal para lograr su participación y colaboración.

Formación para una mejor comprensión del sistema y de los cambios organizativos que comporta.

Documentación del sistema: manual de calidad, procedimientos e instrucciones.

Implantación: puesta en marcha de procedimientos e instrucciones. Seguimiento inicial (informal) y adaptaciones.

3. Check

Auditorías internas.

Revisión del sistema.

Certificación del sistema por una Entidad de Certificación.

Resolución de No Conformidades.

4. Act

Revisión por la Dirección. Establecimiento de nuevos objetivos estratégicos.

Optimización y mejora continua.

Y así volveríamos a entrar en un nuevo ciclo PDCA.

Como decía al principio, en próximas entradas describiré con más detalle cada una de estas fases.

¿Habéis participado en procesos de implantación de sistemas de gestión de la calidad? ¿Qué método seguisteis en vuestra organización? ¿Qué salió bien y qué no repetiríais?

Puedes añadir un comentario en la entrada o contactar conmigo por correo electrónico rellenando el formulario y explicarme tus impresiones.

 

Implementación útil de un sistema de gestión de la calidad ISO 9001

Criterios para gestionar No Conformidades

El punto 8.3 de la norma ISO 9001 nos obliga a asegurar que el producto no conforme es identificado y controlado adecuadamente para prevenir su uso no intencionado.

El tratamiento a realizar puede ser diverso, desde tomar acciones para eliminar la no conformidad hasta autorizar su utilización bajo ciertas condiciones. No voy a entrar en ello en este artículo.

Here I M by Scott Shephard by scottshephard (CC BY-NC-ND 2.0)

Lo que me interesa tratar hoy es: ¿cómo gestionar formalmente estas No Conformidades para cumplir con la norma de la forma más eficiente posible?

Una posibilidad es abrir una No Conformidad cada vez que se produce una incidencia. Eso obliga a realizar Acciones Correctivas por cada incidencia detectada.

Una segunda opción consiste en gestionar y registrar incidencias (y no necesariamente tomar acciones) por departamentos o por procesos. Más tarde, de forma periódica, se pueden revisar todas estas incidencias, analizarlas y plantear Acciones Correctivas en bloque.

No creo que ninguna de las dos opciones sea mejor que la otra sin más. Como en muchas otras cosas depende, por ejemplo, del volumen de No Conformidades a gestionar.

Hay sectores como el farmacéutico en los que cada incidencia suele representar una No Conformidad que debe ser abierta y tratada, generalmente de forma independiente. Al tratarse de sectores altamente regulados, hay mucha conciencia de esta necesidad y se destinan recursos a la formación para que los empleados informen de manera sistemática de cada incidencia por pequeña o repetitiva que ésta sea.

En otras áreas de actividad económica, la cultura corporativa puede ser muy diferente y sólo se abren No Conformidades cuando las incidencias detectadas son de cierta entidad o si siendo poco importantes se repiten con frecuencia.

Mi criterio es que si la cantidad de No Conformidades a tratar es pequeña, en relación a los recursos disponibles para ello, es mejor abrir una No Conformidad para cada incidencia y gestionarla de forma independiente. Eso le da mayor entidad y asegura que le vamos a dedicar mayor atención.

Por el contrario si, en nuestra actividad, se genera un gran número de incidencias diario (me refiero a decenas o centenares) y muchas de ellas son repetitivas creo que es mejor hacer una revisión periódica (diaria o semanal) y plantear No Conformidades que agrupen un gran volumen de incidencias del mismo tipo. Ésto asegura igualmente el tratamiento pero mejora la eficiencia y evita perder el tiempo en tareas repetitivas que no aportan valor.

¿Qué opinas? ¿Qué criterio seguís en tu organización?

Criterios para gestionar No Conformidades

Problem solving process

Many times we must deal with problems in our management activity that it is necessary to face in a systematic way, without improvisations, in order to be able to solve them effectively.

3D Problem Solving
3D Problem Solving

3D Problem Solving by StockMonkeys (under CC by 2.0)

During my professional activity I have successfully used many times the following process of 7 steps:

1. Symptom detection.

2. Problem definition

3. Root cause analysis

4. Research of various alternatives of solution

5. Analysis of alternatives

6. Decission taking

7. Action plan.

Now I am going to explain each phase a little bit:

Symptom detection.

Frequently, it is not the root cause of a problem what we notice but some of its consequences, its symptoms. It is important not to take a symptom as the cause of a problem.

Problem definition

Once we have analyzed the symptoms it is important to focus in the real problem. For instance, maybe you have found that you cannot access the intranet of your company but the real problem is that your LDAP services has failed and you cannot also start a session in your file server or navigate using the corporative proxy server. In this phase it is very important to collect as much data as possible about the problem.

Root cause analysis

What is the real reason of the problem? This is probably the most important point. If you fail to identify the root cause of the problem any solution that you may implement will not solve the problem.

There are many methodologies to help you find the root cause of a problem: 5 whys method, fishbone diagrams, pareto charts, brainstorming, …

Research of various alternatives of solution

Once we have identified the root cause of the problem we can start looking for apropriate solutions. it is important not to stop once we have found a feasible solution. That is laziness of thinking. It is necessary to struggle a little bit more and look for some more alternative solutions.

Analysis of alternatives

When we have a group of solutions, it is necessary to study each one. We must look for pros and cons of each solution and decide which one is the best one.

Decission taking

Once we have the best possible solution it is important to review it again from another point of view. We must look for all the possible inconveniences of the solution. One way to do so is to put yourself in the place of your boss or somebody who will have to aprove the final action plan and try to find all the possible weak points in our argumentation.

Action plan

After one of the alternative solutions has been approved it is necessary to implement an action plan to take it into practice. The action plan must have a set of ordered actions with people responsible to carry them on and the final dates to have each one implemented.

Of course, the plan must be communicated apropriately and have the approval and support of at least a member of the organization with enough authority and executive power to ensure it will be implemented as planned.

A final step.

And a final point. It is a must to verify the results of the action plan and review if the problem has been solved. If it has not yet been solved it will be necessary to analyze if the failure has happened because of a bad implementation or because of a bad root cause analysis, and act in consequence going back to point 7 or to point 3 of the method.

What about you? Do you use this methodology to solve problems? What could be improved? Please, share with us any alternative methodologies that you know or use.

Problem solving process

Using a Blog to support your Project Management Information System

Last summer I started reading “Social Media for Project Managers”, from Elizabeth Harrin. There were many concepts I already knew and some tools I was already using but the book gave me some ideas to use those tools for new purposes. One of them was using a Blog as a part of the PMIS (Project Management Information System) as a project log.

Blog image from http://www.sxc.hu/profile/svilen001
Blog image from http://www.sxc.hu/profile/svilen001

How we use a blog in our project

We started using a blog in a software development project I am managing. The team is young and they are used to these kind of tools so it was not difficult to convince them to start blogging everyday their project activities.

As we all are not working at the same office and also some team members have different working hours, we thought that this tool would help us with its universal accessibility (well, in fact we have limited the access to the blog to the project stakeholders).

These have been the results

After some months of work we have:

  • A project log, explaining what we have done and why we have done it that way. A knowledge repository.
  • A tool useful to train new team members is they are needed in the future.
  • A tool to collaborate. We can receive feedback from the community of project stakeholders through their comments at the blog posts.
  • A tool to build relationships between the team members, as not all of them are collocated.

Some difficulties and risks

But not everything has been easy. We have had establish some ground rules about what to post and how. As every stakeholder may read a post it is not easy to decide the kind of information to include as not all of them have the same needs.

There are some posts that are for internal use (just for the team members), some others are for everybody involved in the project and we are working now in the weekly project status reports, for the project sponsor and the final product users.

As everybody can read every post, the tool we use to filter are tags. If you want to read a project status report you must look for “status” tags in the blog. When a team member looks for some information about the data base he must use some of the tags we have previously agreed to use for these issues, and so on.

What’s your opinion?

What about you, are you using any social media tool to support your projects? What has been the most difficult challenge you have faced to deploy it? What have been the benefits for the project? Any negative result?

Using a Blog to support your Project Management Information System

Validación y pruebas de servicio. Tests unitarios.

Nuestro equipo de desarrollo de aplicaciones es joven, con ganas de probar y aprender pero también con limitada experiencia en algunos temas. Uno de los que me preocupa últimamente es el control de los cambios de las aplicaciones que tenemos en producción pero que seguimos desarrollando y evolucionando.

No es lo mismo ir cambiando versiones de una aplicación mientras está en desarrollo que hacerlo una vez ha pasado a producción, con las repercusiones que puede tener un corte de servicio o un fallo en una funcionalidad.

Una de las aplicaciones que hemos desarrollado controla una línea de producción de equipos en nuestra planta. Desde que la pusimos en marcha el departamento de Producción ha podido ir incrementando considerablemente su ritmo de fabricación semanal, de forma que cualquier corte en el servicio, por pequeño que sea, ahora tiene gran repercusión.

En otra entrada ya explicaré cómo tenemos implementada la gestión de cambios en la aplicación pero ahora lo que me interesa es lo que en ITIL se denomina Validación y Pruebas del Servicio, dentro del proceso de Transición del Servicio.

Tras haber aprobado un cambio es preciso, por este orden y a grandes trazos, definir los requisitos que debe cumplir la solución, diseñar la solución y las pruebas que deberá pasar antes de entrar en producción y, lógicamente, desarrollarla.

Modelo de desarrollo y test "en V"
Modelo de desarrollo y test “en V”

Siguiendo el Modelo V, empezaríamos las validaciones con pruebas unitarias, seguidas de pruebas de sistema y acabando por las pruebas de integración.  También será preciso hacer tests de regresión, para verificar no sólo que la entrega cubre los objetivos del cambio planificado sino que todo lo que nuestra aplicación hacía bien antes de la entrega lo siga haciendo después.

Cuando las aplicaciones se hacen grandes verificar la cobertura de las pruebas respecto a los requerimientos y/o las líneas de código no es trivial.

Según se desprende del modelo en V, una buena base desde la que construir la aplicación deben ser los test unitarios. En el BCNDevCon12 tuve oportunidad de asistir a un par de master sessions en las que se explicaba de forma práctica la metodología TDD (Test Design Driven). Este método de desarrollo nos asegura que nuestro código va a cumplir con los requerimientos.

En pocas palabras se trata de diseñar los tests que deberá pasar nuestro código antes incluso de desarrollarlo, en base a cada uno de los requerimientos que nuestro cliente nos haya planteado. Una vez diseñado el test hacemos el mínimo código para cumplir con el requerimiento y lo probamos contra nuestro test.

Si el resultado es positivo pasamos al siguiente requerimiento y su test asociado. Si es negativo rehacemos el código y volvemos a testear hasta que lo pase.

Según vamos incorporando requerimientos deberemos ir refactorizando nuestro código y volviéndolo a probar contra la batería de tests. Todo el proceso está muy bien explicado aquí.

En otro post hablaremos de los tests de sistema y los de integración. Me interesa mucho encontrar herramientas para automatizarlos en el marco de desarrollo de aplicaciones web. Pero, como decía,  eso será en otra entrada. ¿Qué métodos y/o herramientas utilizáis en vuestras pruebas unitarias? ¿usáis TDD? ¿con qué resultados?

Validación y pruebas de servicio. Tests unitarios.