lunes, 11 de mayo de 2009

Formación KMKey Quality

4 comentarios
 
En este punto se supone que se ha explicado la parte común del interface así como los procedimientos de funcionamiento operativo que son transversales a toda la aplicación.

Introducción:
La estructura propia de KMKey lo hace idóneo para su configuración como software para la gestión de sistemas de calidad de cualquier norma ISO y otras.

Conceptos principales:
  • Entorno colaborativo.
  • Los participantes en el SGC (permisos y accesos) pueden estar definidos desde el operario de planta, hasta el gerente, pasando por el propio Dpto. de Calidad y el resto de los mismos.
  • Los flujos de información y sus participantes pueden quedar definidas y automatizadas en el patrón.
  • Notificaciones automáticas (por e-mails e interna) a los participantes de cualquier acción.
  • Interface gráfico para la "visualización" de la evolución de cada expediente.
  • Registro de todas las actividades del sistema, listas para ser explotadas como listados de registros de calidad, listados de documentos, informes, resúmenes de actividad, de acciones abiertas, cerradas, en trámite, etc.
KMKey Quality incorpora un Gestor documental que contempla el Ciclo: Edición, Revisión, Aprobación y un sistema de gestión de versiones (revisiones) que lo hace idóneo para demostrar la trazabilidad, accesibilidad, actualización y validación de todos los documentos propios de la normativa:
tales como:
  • Procedimientos Documentados (Obligatorios o no).
  • Manual y Política de Calidad.
  • Objetivos e indicadores del sistema.
  • Organigramas.
  • Mapas de Procesos.
  • Instrucciones y hojas de trabajo
  • Formatos.
Las acciones propias a todo SGC (obligatorias por la norma o no) se pueden sistematizar y automatizar como distintos patrones de KMKey Quality.
La automatización puede extenderse a la división en distintas tareas de la acción, sus fechas y plazos de desarrollo, sus responsables, los documentos generables de registro asociados, etc.
asi como:
Todo tipo de registros (obligatorios por la norma o no).
  • Gestión completa de No Conformidades.
  • Acciones Correctivas/Preventivas.
  • Revisiones del Sistema.
  • Planes de Auditoría.
  • Planes de Mejora.
  • Planes y registro de Formaciones.
  • Seguimiento y Evaluación de Proveedores.
  • Gestión y Control de Indicadores.
  • y otros
Prácticas de funcionamiento
Conceptos Previos
  • Introducción a la "filosofía" de proyectos/expedientes en 5 pasos, que coinciden con los TABS: DEFINICIÓN, EQUIPO, PLANIFICACIÓN, GESTIÓN Y CONTROL.
  • Explicar (recordar) la vinculación entre patrones a la vista y filtros automáticos.
  • Recordar que no todos los usuarios del sistema tendrán las mismas posibilidades de "iniciar" Nuevos expedientes/acciones, o de intervenir en ellos.
  • Recordar que los campos de cualquier "Nuevo" son definibles según las necesidades del cliente.
  • En función del usuario que estemos utilizando aprovechar para entrar como "manager" y mostrar en el TAB: ADMIN la lista de patrones, su estructura XML y los campos de un patrón en concreto.
  • Recordar que en los patrones de las distintas acciones podemos dejar programado, TAMBIÉN, el flujo de trabajo del mismo:
    - quien lo incia,
    - a quien lo envia,
    - a quién se notifica,
    - que decisiones se toman,
    - como y cuando se supervisan,
    - quiénes son sus responsables,
    - etc.
Práctica 1
Iniciamos (usuario santi) una NC de Proveedor para concentrar las explicaciones de patrón, campos, flujo de trabajo y equipo.

TAB DEFINICIÓN
  • Vemos los datos rellenados.
  • Hacemos observación que NO TODOS los datos de la NC se han rellenado en ese paso, pues puede que el que incia la NC no los conozca o no tenga porqué conocerlos.
  • Avismos que los campos para la captura de los datos que todavía faltan, irán apareciendo en función del usuario y paso en el que se encuentre la acción.
TAB EQUIPO
  • Vemos los participantes incorporados con perfiles de Creador y Receptor
  • Damos a entender que este flujo podría completarse todavía con un aprovador/revisor o enlazarlo con otra acción del sistema como podría ser una AC/AP.
  • Salimos del usuario santi y entramos como Albert, o el que hayamos elegido como receptor.
TAB DEFINICIÓN (2º participante)
  • Selecionamos el objeto en el NAVTREE y el TAB DEFINICIÓN > MODIFICAR.
  • Rellenamos parte de los datos en los nuevos campos que aparecen.
  • Mostramos como podemos iniciar en esa parte del flujo (o en cualquier otra que definiese el cliente) una AC/AP.
  • Realizamos la práctica de vincular una y otra.
  • Mostramos el nuevo expediente de AC/AP incorporado al NAVTREE.
  • Si no se tiene preparado, montar un filtro en el que se muestren la NC (de proveedor) y las AC/AP.
  • Mostrar como podemos pasar de una a la otra NC > AC/AP y de esta a la NC que la originó.
  • Mostrar como el flujo y los responsables/fechas/verificaciones/cierres se pueden adaptar a las necesidades de cada organización.
  • Mostrar como, además, con KMKey Quality tendremos la posibilidad de visualizar en cada momento el estado de cada "acción".
  • Mostrar como podemos dividir tanto la NC, como la AC/AP en tareas que aparecen en el NAVTREE.
En este punto hay que recordar que las explicaciones de Quality no deben hacer "demasiada" insistencia en las partes "fuertes" de KMProject que no se utilizan con el mismo "espiritu" en Quality.
Así, por ejemplo, la división de una acción en distintas tareas, con desarrollo espaciado y secuenciado en el tiempo, con responsables de cada acción queda más evidente si elegimos iniciar una patrón de Auditoría Interna, aunque sólo sea como ejemplo.
Eso es así, debido a que la mayoría de los otros patrones de Quality no dependen tanto de la división en tareas y su desarrollo "al modo" de un proyecto, como de un "flujo de trabajo y orden de intervenciónes" que sumado a unos roles bien definidos configuran toda la acción.

Práctica 2
Por tanto, iniciamos un patrón de Auditoría Interna, más como un ejemplo para LOS TABS EQUIPO y PLANIFICAR, que como otra cosa.
  • Mostramos mediante la apertura del nuevo expediente su división en tareas, con fechas y responsables.

TAB PLANIFICAR

  • Mostramos, mediante la elección de una escala de visualización apropiada, el histograma GANTT del desarrollo de las tareas.
  • Mostramos como mediante "Editar Planificación" o mediante "Modificar" podríamos variar a voluntad las fechas de incio y final de tarea y adaptarlas a nuestras necesidades.
TAB EQUIPO
  • Mostramos como podemos crear un supuesto equipo de Auditores, como Grupo de Recursos/Permisos.
  • Añadimos integrantes a este equipo.
  • Añadimos el equipo creado al expediente nuevo de Auditoria.
  • Volvemos al TAB PLANIFICAR.
  • Mostramos como podemos variar el responsable de las tareas.
  • Mostramos (PLANIFICAR-RECURSOS) y como en un momento dado podríamos llegar a planificar: qué auditor hace qué en una tarea y dia concreto.
Práctica 3
  • Realizamos una asignación y la mostramos en el TAB GESTIÓN > Historia.
  • Advertimos de la posibilidad de que ciertos patrones tengan como opción que las tareas se incien automáticamente con la inclusión de un item de información o que por el contrario se abarn manualmente.
TAB GESTIÓN
Aprovechando la anterior explicación y el expediente de Auditoria recien creado, pasamos al ámbito del TAB GESTIÓN
  • Mostramos los 4 tipos de elementos de información pertenecientes a los 4 ejes de desarrollo de todo proyecto/expediente. (INFORMACIÓN, TIEMPO, ECONOMÍA y ESFUERZO.
  • En este punto hay que advertir que permanecen a la vista los elementos temporales, económicos y de esfuerzo que aunque no sean demasiado "vitales" para los SGC, los mantemos a la vista como posibilidad. (Otros lientes nos los han solicitado)
  • Insistir en los elementos pertenecientes al eje conocimiento/información.
  • Volver a mencionar las prestaciones de KMKey en cuanto al mantenimiento de un sistema de gestión de documental, incorporando un ciclo (Edición, Revisión, Aprobación) totalmente nomativizado.
Práctica 4
Por tanto, iniciamos un ejercicio de "Añadir documento" y advertimos que lo someteremos por completo al ciclo mencionado.
Inciamos la práctica con el usuario santi, como editor.
  • Sube un documento, genera una versión y la envia a revisión.
  • Mostrar los cambios que se producen en la visión de Historia. (Documento -copia- Bloqueada, y copia en "Revisión".
  • Salir de santi y entrar como albert. Mencionar los cambios en la cantidad de patrones que puede o no iniciar y que en ese momento están a la vista.
  • Mostrar el sistema de mensajería y de como queda avisado (notificado) de la necesidad de intervenir en ese expediente con una tarea en concreto: revisar el documento.
  • Acceder al documento desde Mensajes.
  • Visualizar el documento y enviarlo a aprobación.
  • Comentar que el revisor NO DEBE editar el documento por si mismo y que si encuentra algo anormal debe "rechazar" la versión.
  • Explicar que entonces volvería (con notificación incluída al editor.
  • Salir de albert y entrar como joan.
  • Acceso al expediente mediante Mensajes (Notificaiones).
  • Aprobar el documento.
  • Mencionar la "consolidación" en una sóla copia de trabajo.
  • Mostrar (con un usuario con suficientes permisos) todo el login de actividad del documento y el sistema de gestión de versiones.
Práctica 5
Modificar un documento.
Con el fin de que este tipo de acciones que luego se convertirán en actividades frecuentes se repite la práctica anterior, pero ahora simulando que el documento ha sufrido una modificación (puede ser un logo, o un párrafo distinto)
  • Tener preparadas 2 versiones del documento. Mostrar las diferencias entre la que ya está incorporada y la que vamos a "subir".
  • Reemprender la práctica desde el momento en que el editor solicita generar una nueva versión.
  • Modificar ese borrador cargando el documento con el logo o el párrafo cambiado.
  • Enviarlo a Revisión.
  • Entrar como revisor
  • Revisarlo y enviarlo a aprobación.
  • Entrar como aprobador.
  • Aprobarlo y desde un usuario con permisos acceder mostrar el nuevo login de actividad y el cambio en el numeral de la versión/revisión.
  • Acceder a la versión anterior.
Práctica 6
Añadimos una nota.
Cualquier usuario redacta y envia una nota.
  • Mostrar el resultado en Historia.
  • Mostrar el filtro de información propia de la opción.
Práctica 7
Añadimos un e-mail.
Cualquier usuario (santi, albert, joan), aprovechando que ya hay documentos incorporados en el expediente de práctica:
  • Enviar un e-mail a otro participante o a otro contacto.
  • Enviar un e-mail a un expediente o a una tarea KMKey.
Práctica 8
Añadir un documento generado mediante plantilla.
  • Recordamos que ademas de conservar los registros en formato digital, con la información de los mismos podremos generar documentos mediante plantilla y que se pueden incorporar al expediente.
  • Mostrar una NC y generar un Informe/resumen de la misma.
  • Comentar las diferencias entre la información recogida en KMKey y la introducida mediante "Subir Dcocumento".
  • Comentar la posibilidad de generar el informe en distintos formatos.
  • Diferenciar este tipo de documentos de lo que son propiamente los Informes o Listados que obtenemos en el TAB CONTROL
TAB CONTROL
  • Mostrar visualizaciones de Fechas.
  • Informes. Extraer algún ejemplo de informe.

4 Responses so far.

  1. Joan says:

    Manel:
    Me parece correcto pero la primera práctica debería ser un ciclo edición-revisión-aprobación de documentos.
    Será suficiente con cambiar el orden

  2. JuanJe says:

    Existe algun tutorial sobre la gestion de incidentes y reclamos

  3. Hola JuanJe

    En http://www.kmkey.com/ayuda tienes videos demostrativos de casi todo.

    Saludos

  4. Esta disponible para MacOSX?

Leave a Reply