Uso del Diagrama de Causa Efecto

El diagrama causa-efecto es una herramienta que permite analizar de forma organizada y sistemática los problemas, causas y las causas de estas causas, cuyo resultado en lo que afecta a la calidad se denominará efecto. Permite organizar y representar las diferentes teorías propuestas sobre las causas de un problema. Se conoce también como diagrama de Ishikawa o diagrama de espina de pescado dado que su estructura es similar a la del esqueleto de pescado y se utiliza en las fases de Diagnóstico y Solución de la causa. Otra acepción que recibe este diagrama es el de las 4M o 6M, según sea la cantidad de elementos que puede incluir: Materiales, Mano de obra, Métodos, Máquinas, Medio ambiente y Mantenimiento.

El diagrama causa-efecto es un vehículo para ordenar, de forma muy concentrada, todas las causas que supuestamente pueden contribuir a un determinado efecto. Permite lograr un conocimiento común de un problema complejo, sin ser nunca sustitutivo de los datos. Es importante ser conscientes que los diagramas de causa-efecto presentan y organizan teorías. Sólo cuando estas teorías son contrastadas con datos podemos probar las causas de los fenómenos observables. Errores comunes son construir el diagrama antes de analizar globalmente los síntomas, limitar las teorías propuestas enmascarando involuntariamente la causa raíz, o cometer errores tanto en la relación causal como en el orden de las teorías. Existen dos aspectos básicos que definen está herramienta: (1) ordena y (2) profundiza. Facilita la selección de las causas de mayor influencia y ayuda a adoptar medidas correctivas.

El valor de una característica de calidad depende de una combinación de variables y factores que condicionan el proceso productivo. La variabilidad de las características de calidad es un efecto observado que tiene múltiples causas. Cuando ocurre algún problema con la calidad del producto, debemos investigar para identificar las causas del mismo.

El objetivo que persigue este diagrama es reflejar organizadamente las posibles fuentes de errores o problemas, así como también los buenos efectos.

Las reglas de este diagrama son: 1- Causa probable: se considera todo aquello que genere un determinado efecto 2- Problema: es aquel efecto que se constituye en un elemento mensurable

Los procedimientos para realizar el diagrama son dos: 1- se identifican o sugieren las causas probables mediante la aplicación del Brainstorming o torbellino de ideas, detallando desde las aparentemente principales o más relevantes a las menos principales 2- se registran las causas identificadas ubicándolas sobre el diagrama

Para elaborar un diagrama de causa efecto se debe: 1- trazar una flecha gruesa o destacada de izquierda a derecha 2- indicar al finalizar la flecha, es decir, a su derecha el efecto 3- identificar las causas principales o primarias representando esas causas con sentido oblicuo en ambos lados de la flecha 4- las causas secundarias se representan mediante una flecha paralela al efecto, de izquierda a derecha, hasta tocar la que representa a la causa principal. 5- Se analizan las causas: tomamos cada causa según el orden establecido y se analiza su posible influencia en el problema 6- Se analizan los resultados del análisis: Puede pasar que: • El problema desaparezca • El problema disminuya (en este caso se deben atacar las causas restantes) • El problema siga igual Un diagrama de Causa-Efecto es de por si educativo, sirve para que la gente conozca en profundidad el proceso con que trabaja, visualizando con claridad las relaciones entre los Efectos y sus Causas. Sirve también para guiar las discusiones, al exponer con claridad los orígenes de un problema de calidad. Y permite encontrar más rápidamente las causas asignables cuando el proceso se aparta de su funcionamiento habitual.

Este diagrama se puede aplicar al punto de “Acción Correctiva” (8.5.2) de ISO 9001:2000 y de ISO 90003:2004 (ISO 9001:2000 aplicada al Software), ya que permite evaluar las causas de las no conformidades para así prevenir que ocurran nuevamente.

Respecto de CMMi V1.1 se puede decir que el área de proceso “Causal Analysis and Resolution” (CAR) tiene como finalidad detectar las causas de los defectos y otros problemas para tomar las acciones preventivas correspondientes.

De esta forma, el diagrama de causa efecto puede resultar muy útil no sólo para definir las causas de un problema sino también para evidenciar los factores positivos que pueden aplicarse a las acciones encaminadas a obtener otras mejoras.

Service Oriented Architecture

Service Oriented Architecture (SOA) es un estilo de arquitectura de Tecnología de la Información (TI) que soporta la orientación a servicios. Se basa en la independencia de plataformas de hardware, de sistemas operativos y de lenguajes de programación. Permite fortalecer la reutilización de los sistemas actuales que se construyeron y se utilizaron durante años; y crea un ambiente en el que los negocios y la TI pueden interactuar entre sí.

El Servicio es una tarea repetible que tiene una misma forma y se repite varias veces.

La Orientación a Servicios efectúa una conexión de servicios y resultados asociados. La Arquitectura Orientada a Servicios es un estilo de arquitectura que soporta la integración como servicios vinculados entre sí.

Un verdadero enfoque orientado a servicio se logra cuando las aplicaciones monolíticas son desorganizadas en servicios de negocios auto-contenidos y bien definidos. Toda la funcionalidad de infraestructura es provista mediante servicios. Los procesos de negocio son finalmente replicados como una composición de servicios, coordinada y orquestada por otro servicio.

SOA se fundamenta en: (1) Ejecutar rápido, adaptarse al mercado, ganar ante la competencia, (2) Reutilizar los componentes de los procesos de negocio, (3) Medir los resultados y tomas acciones sobre ellos, (4) Garantizar resultados que sean repetibles y predecibles y (5) Empezar donde sea necesario (área de negocios – área de tecnología).

Es posible tener una percepción distinta del mismo concepto, dependiendo del punto de vista que se emplee. Un “Ejecutivo de negocio” puede ver SOA como un conjunto de servicios de negocio que su organización busca exponer a sus clientes, socios o a otras áreas que la integran. Para un “Arquitecto”, en cambio, SOA será un estilo arquitectónico que va más allá de la implementación, al definir principios de diseño, patrones y criterios que permiten lograr características tales como modularidad, encapsulamiento, bajo acoplamiento, separación de responsabilidades, reutilización, composición, etc. Finalmente, para un “Desarrollador”, SOA es un modelo de programación que provee estándares, herramientas y tecnologías concretas, que le permiten llevar a cabo su tarea diaria.

SOA crea un conjunto de servicios que soportan procesos de negocio. Un negocio flexible permite responder a la velocidad del negocio, a la demanda de los clientes, a las condiciones del mercado y al ambiente competitivo. Un negocio flexible requiere de una infraestructura sensible. SOA brinda flexibilidad sobre sus sistemas actuales.

Las compañías que están comenzando a implementar SOA son aquellas que pueden adaptar sus procesos de negocios a los cambios del mercado, gracias a que su área de tecnología es flexible para aceptar los cambios.

SOA requiere un cambio en la forma de pensar y un cambio de tecnología. Si se analizan las tareas de negocios e identificamos aquellas que se pueden repetir, estas tareas se pueden definir como “Servicios”. Verificar un saldo, abrir una cuenta, comprobar la existencia de stock, son tareas de negocio repetibles que se denominan servicios. Por lo tanto, cualquier negocio, independientemente de su industria, posee servicios.

Existen bloques de construcción que son vistos como servicio y son una tarea de negocio. Se puede tomar cada uno de estos bloques y unirlos de manera flexible. Se puede ensamblarlos varias veces a medida que cambian sus necesidades. Cada bloque equivale a una tarea de negocios dentro de una empresa. Cada persona puede tomar distintos bloques y luego con todos construir algo diferente utilizando los mismos componentes.

Los puntos de entrada a SOA ayudan a las empresas a seguir el camino correcto: aplicando un enfoque basado en proyectos solicitando que cada proyecto entregue el valor empresarial real. Los puntos de entrada de SOA son: (1) Gente, (2) Información, (3) Procesos, (4) Reutilización, y (5) Conectividad. Las personas son la clave para la innovación y la productividad organizacional.

Analistas y Clientes concuerdan en que SOA es crítica para la innovación. La innovación se refiere a la capacidad de realizar cambios de una manera rápida, fácil y económica. La innovación que importa se refiere a todo lo que lo diferencia en su mercado. Reconocer las necesidades del mercado y responder más rápidamente que la competencia, con modelos, productos y servicios empresariales innovadores, es lo que hace que la empresa crezca. SOA ayuda a innovar al asegurar que los sistemas de TI pueden adaptarse veloz, fácil y económicamente para brindar soporte a las necesidades de negocios rápidamente cambiantes.

El ciclo de vida de SOA es: (1) Determinación de los requerimientos, (2) Ensamblado, (3) Integración, (4) Administración y (5) Gobernabilidad.

Las ventajas de SOA son: (1) Reduce el nivel de acoplamiento, (2) Mejora la definición de los roles de desarrollo, (3) Facilita la prueba del software, (4) Mejora la facilidad de mantenimiento, (5) Favorece la reusabilidad y mejora la productividad, (6) Favorece el desarrollo en paralelo, (7) Permite un monitoreo más preciso de los procesos y (8) Permite la interoperabilidad.

Se puede decir que SOA es una arquitectura formada por distintos servicios y que integrados forman un todo unido. Para cada servicio establecido, se puede tener en cuenta la Norma ISO 20000:2005 (Service Management) e ITIL (Information Technology Infrastructure Library), el cual consiste en un conjunto de mejores prácticas que pueden ser consideradas durante la implantación.

Por lo tanto, SOA es un concepto que las empresas están implementando, ya que una de las tendencias de los negocios es la prestación de servicios de TI.

Responsabilidad de la Dirección e ISO 9001:2000 (2)

En todo Sistema de Gestión de la Calidad, la Responsabilidad central pertenece a la Dirección. No es posible encarar ningún Sistema de Gestión sin tener a la Dirección completamente involucrada.

Los aspectos a considerar en “Responsabilidad de la Dirección” son: (1) Compromiso de la Dirección, (2) Enfoque al Cliente, (3) Política de la Calidad, (4) Planificación, (5) Responsabilidad, autoridad y comunicación; y (6) Revisión por la Dirección.

La norma ISO 90003:2004 (ISO 9001:2000 aplicada al Software) considera los mismos ítems que la Norma ISO 9001:2000 para el punto de “Responsabilidad de la Dirección”.

Respecto del punto “Compromiso de la Dirección” (5.1), se puede decir que la Dirección debe conocer y comunicar a la organización, los requisitos que derivan de las necesidades de los clientes como los que se asocian a regulaciones legales. Debe involucrarse en la consecución de tales requisitos, organizarse para gestionar los recursos necesarios para la producción y para revisar periódicamente que dichos requisitos se cumplan y las actividades progresen en el sentido establecido por las políticas y objetivos de calidad declarados.

El punto “Enfoque al cliente” (5.2) ,en términos del cliente o usuario final, hace referencia a la satisfacción de requisitos a través de condiciones de prestación, precios de compra o de mantenimiento, confiabilidad, disponibilidad, servicios posteriores a la venta, etc.

El área de proceso “Requirements Development” (RD) de CMMi V1.1 guarda relación con este punto.

El punto “Política de la calidad” (5.3) debe ser un documento controlado y revisado periódicamente de cara a la consecución de los objetivos de la organización. Asimismo, la política de la calidad debe ser intensivamente difundida para asegurar que todos los miembros de la organización conozcan su participación y su grado de responsabilidad en el cumplimiento de los requisitos de los clientes.

La política de la calidad debería incluir: (1) El nivel esperado de satisfacción del cliente, (2) La expresión de las necesidades de las otras partes interesadas, (3) La mención del concepto de mejora continua como guía de gestión, (4) La expresión de la visión de la Dirección para el futuro de la organización y (5) Una clara demostración del compromiso de la Dirección.

El área de proceso “Organizational Process Focus” (OPF) de CMMi V1.1 guarda relación con este punto.

El punto “Planificación” (5.4) indica que la empresa puede probar que realiza sus planes de calidad, exponiendo un plan de calidad para cada producto. Los procesos de actualización de los planes de calidad deben asegurar que la integridad del Sistema de Gestión de la Calidad no queda afectada. El plan de la calidad es el documento o conjunto de documentos que establecen los objetivos de calidad, la especificación de los procesos operativos necesarios y la disponibilidad de los recursos apropiados para satisfacer tales objetivos, para la elaboración del producto que ocupa a la organización.

La planificación incluye dos aspectos centrales: los objetivos de la calidad y la planificación de la calidad. Los objetivos de la calidad deberán estar expresados en un documento controlado, ser coherentes con la política de la calidad, estar diseñados en función de un espíritu de mejora continua y ser revisados periódicamente a efectos de vigilar su cumplimiento y, eventualmente modificar su expresión para adaptarlos a realidades cambiantes. La Dirección demostrará su accionar en este punto, exponiendo un plan de objetivos de la gestión. Todos los objetivos deben estar expresados en unidades mensurables.

Las áreas de procesos “Organizational Process Focus” (OPF), “Organizational Process Performance” (OPP), “Quantitative Project Management” (QPM) y “Organizational Process Definition” (OPD) de CMMi V1.1 guardan relación con este punto.

El punto “Responsabilidad, autoridad y comunicación” (5.5) hace referencia a que la responsabilidad y autoridad están expresadas en un documento controlado conocido como organigrama. Allí se establecen las relaciones de autoridad dentro de la organización y las interrelaciones entre los miembros del personal. Las responsabilidades de cada funcionario de la organización en lo atinente a la calidad del producto, pueden estar listadas en un documento adjunto al organigrama o en una matriz de competencias, donde en columnas se colocan los sectores de la organización y en filas las actividades de la gestión de la calidad, preferentemente divididas por capítulo. En cada celda de la matriz, habrá de establecerse el grado de responsabilidad esperado para tal sector en la ejecución de tal actividad. En la última columna, se pueden listar los procedimientos, instrucciones o documentos aplicables.

Las responsabilidades de cada funcionario de la organización deben ser claramente conocidas por todos sus miembros, en la medida en que esto sea relevante para sus respectivas actividades.

Las áreas de procesos “Organizational Process Focus” (OPF) y “Organizational Process Definition” (OPD) de CMMi V1.1 guardan relación con este punto.

El punto “Revisión por la Dirección” (5.6) indica que la Dirección debe evaluar periódicamente el avance del Sistema de Gestión de la Calidad, para asegurar su continua consistencia, adecuación y efectividad. La revisión por la Dirección debe hacerse sobre datos concretos de la gestión de la calidad pero, necesariamente, debe estar acompañada del contacto que cada directivo haya podido tener con la realidad del producto, de los clientes y de los procesos. La revisión debe conducirse de modo que se evalúe el grado de satisfacción de los objetivos de calidad y política de la calidad.

El resultado de la revisión por la Dirección, debería dar una gama de decisiones de adecuación de la organización, del sistema de la calidad, de la política o de los objetivos calidad, de los recursos dispuestos para cada proceso, de las tecnologías o del producto en sí, a efectos de corregir las tendencias y conducir la organización hacia la consecución de sus objetivos, lo cual significa llevarla hacia el cumplimiento de los requisitos de los clientes y otras partes interesadas.

Las áreas de procesos “Organizational Process Focus” (OPF) y “Project Monitoring and Control” (PMC) de CMMi V1.1 guardan relación con este punto.

De esta forma, el punto “Responsabilidad de la Dirección” forma parte del modelo de un Sistema de Gestión de la Calidad, el cual está basado en procesos que ilustran los vínculos entre los procesos presentados en los capítulos 4 a 8 de la ISO 9001:2000.