Utilizando casos particulares como ejemplo, en este artículo se propone y explica un método sistemático para realizar mapas de procesos de organizaciones.
El método que vamos a describir es válido para cualquier sistema de gestión.
Paso 1: Identificar a los actores
La organización existe porque tiene clientes que atender, pero también depende de sus proveedores y otras organizaciones de su entorno. Una buena manera de empezar es identificar a los agentes o actores que se relacionan con nuestro sistema de gestión: clientes, proveedores, partners, y otras organizaciones con las cuáles mantenemos una relación que tiene relevancia para nuestro sistema de gestión. Entre los actores también podemos destacar elementos de la infraestructura que puede ser relevante destacar: nuestra página WEB, un almacén, el sistema informático interno, etc.
Si el sistema es de calidad, debemos identificar a los actores que tienen relevancia para la calidad, si es de medio ambiente, a los actores que tienen relevancia en nuestra gestión ambiental, y lo mismo debemos hacer con otros tipos de sistema.
Cojamos un ejemplo real desarrollado en Portalcalidad. Se trata de un sistema de gestión que presta servicios de tecnologías de la información en una universidad. Este tipo de sistemas es lo más complicado que nos podemos encontrar porque sus fronteras son muy difíciles de trazar, se trata de sistemas “engullidos” o “incrustados” en otro sistema mayor (en este caso, el de la Universidad).
¿Cuáles son los actores de estos Servicios Universitarios?. Empecemos por enumerarlos:
Los alumnos: los alumnos reciben servicios de nuestro sistema de gestión. Utilizan la infraestructura de hardware y software mantenida por nuestro sistema. Así que los vamos a seleccionar, y además reflejaremos los alumnos antes y después de haber pasado por sus clases y laboratorios.
Los profesores: los profesores son un colectivo que queremos diferenciar de los alumnos. Utilizan nuestros servicios igual que ellos, y además en sus despachos, pero esta diferencia no es relevante. Lo importante es que los profesores deben especificarnos qué medios necesitan. En nuestro sistema, tal y como nos ha descrito MªCarmen, los profesores son una fuente importante de requisitos que nuestro servicio debe satisfacer. Los alumnos también tienen necesidades, y nos las comunican, esto también lo querremos representar, pero de forma separada, ya que son requisitos de distinta índole.
La Dirección de la Universidad: consideramos que la Dirección de la Universidad es nuestro verdadero cliente, el que marca las condiciones de nuestro servicio. La Dirección de la Universidad es responsable de alumnos y profesores, no nuestro Servicio. Los servicios de una Universidad se deben al rector, aunque los destinatarios de su producto sean otros: alumnos y profesores. Aceptada la Dirección de la Universidad como cliente, ya sabemos que en algún punto de nuestro mapa tendremos que representar la comunicación de requisitos y directrices para el servicio.
Otros servicios y departamentos de la universidad: estas áreas de la universidad también utilizan el producto de nuestro trabajo, utilizan software y hardware que nosotros instalamos, configuramos y mantenemos. Si tuviéramos una relación especial con alguno de estos departamentos, deberíamos separarlo también del resto, y posteriormente reflejar esta relación en el mapa.
El sistema informático: cada vez son menos las organizaciones que no disponen de un sistema que gestione la mayoría de sus procesos de información. Estos sistemas se conocen con el acrónimo ERP (Enterprise Resource Planning) y su importancia es tan vital que es ineludible colocarlo en el centro de nuestro mapa de procesos. Lo más probable es que todos los procesos de nuestro Servicio interaccionen con el Sistema Informático, más adelante deberemos representar las relaciones que sean más importantes.
La Administración Pública: englobamos en este grupo a la administración autonómica y estatal, y los representamos porque nuestro sistema recibe recursos importantes de estos estamentos, en cuya solicitud y trámite tenemos procesos trabajando. Esta relación nos interesará representar en nuestro mapa, aunque no los procesos de solicitud y trámite, a no ser que estos procesos ocupen gran parte de nuestros esfuerzos.
Otros proveedores: de momento haremos un gran grupo para englobar a todos nuestros “otros proveedores”. Es probable que nuestro servicio compre hardware, software, material de papelería, subcontrate servicios, etc. Quizá nuestro sistema no compra directamente las máquinas, ni los programas. A lo mejor no compra directamente nada. En este caso, estos “otros proveedores” deberían substituirse por los procesos de la universidad que han de proporcionar estos productos y servicios.
Ojo!: aunque no compremos nosotros, nuestro sistema tiene la responsabilidad de definir los requisitos del producto y asegurarse de su conformidad.
Podríamos incluir en esta lista al conjunto de la sociedad. Pensamos que la Universidad sí debería hacerlo, pues es uno de sus clientes principales. Los Servicios de la Universidad tienen que contribuir a que ésta pueda hacer correctamente su servicio público, pero sin saltarse a su huésped.
Llegados a este punto, nos podemos aventurar a realizar la primera versión de nuestro mapa de procesos:
Nuestro sistema está ahí para proporcionar la infraestructura de TI que satisfaga las necesidades del proceso de enseñanza. Estamos ahí porque ellos nos necesitan, así que no podemos dejar de representar estos procesos en nuestro mapa, y así lo hemos hecho.
Nuestro mapa ya va tomando forma. Si logramos mantener esta configuración, el resultado final será bastante ordenado. No obstante, lo más probable es que tengamos que mover alguna caja según vayamos añadiendo nuestras cajitas.
Paso 2: Identificar la línea operativa
La línea operativa de nuestra organización está formada por la secuencia encadenada de procesos que llevamos a cabo para realizar nuestro producto. Esta línea viene determinada por la naturaleza de nuestra actividad y por la dosis de innovación que hayamos sabido y podido implementar en nuestro sistema (ingeniería de procesos).
Ejemplos típicos de línea operativa:
Empresa comercial de distribución mayorista:
En este tipo de empresas hay un proceso previo y continuo en la relación con los clientes: la negociación y pacto de las condiciones previas del producto. Este proceso es muy importante en estas empresas, tiene que ver con la estrategia comercial (gestión de tarifas y descuentos, presentación y defensa de ofertas, negociación de subidas de precio, etc.. ), pero no forma parte de la línea operativa. Estos procesos pactan las condiciones del servicio, pero no son los encargados de ejecutarlo. Una de las cosas que deberemos hacer después es establecer la relación entre estos procesos y la línea operativa, relaciones que son clave para la calidad del servicio.
Empresa de servicios a medida
Su línea operativa es bastante más compleja que la anterior. Aquí cada servicio es único, irrepetible.
Cada petición de servicio por parte de un cliente requiere:
- Visitar las instalaciones objeto del servicio y registrar los requisitos del cliente.
- Aportar y definir una solución técnica y legal a las necesidades del cliente.
- Valorar los recursos necesarios para ejecutar el servicio: gasto de material, horas de personal, condiciones de instalación, etc.
- Realizar una oferta de servicio y negociarla con el cliente.
Las especificaciones del servicio están contenidas en la oferta y en otros documentos generados durante la etapa de valoración. Estas especificaciones pasan a un proceso de planificación del servicio, el cual transmite las especificaciones de lo que se ha de hacer a los procesos de instalación, y a los procesos de dirección y control de las instalaciones. Finalmente los procesos de instalación ejecutan la instalación, prestando así el servicio.
Observemos que la complejidad de esta línea operativa es la responsable de que la industria de los servicios de instalación esté tan atomizada, hay muchas pequeñas empresas y, las grandes, no ejecutan el servicio, lo subcontratan a otras empresas, que son pequeñas.
En este tipo de empresas prima la mano de obra frente a la infraestructura, y en general, cuanto más variable y complejo es el servicio a realizar, más pequeña es la empresa que finalmente lo ejecuta. Las empresas grandes tienen posibilidades de competir cuando podemos incrementar substancialmente la productividad mediante la inversión en infraestructura, y siempre que el servicio no sea muy complejo. Más de una gran empresa se ha estrellado intentando meterse en un sector por pensar que había encontrado el Santo Grial.
Un modelo alternativo que sí ha triunfado es el formado por empresas o autónomos que se dedican a vender el servicio al cliente, y que posteriormente transfieren el pedido a la empresa que finalmente lo ejecuta. No descubrimos nada, es la subcontratación pura y dura. La diferencia es que la especificación sobre lo que se ha de hacer ya está hecha, la hace el cliente, aunque la empresa también tiene que determinar sus requisitos propios para cada servicio, hacer ofertas, etc.
Este tipo de relaciones son prósperas y duraderas porque la empresa obtiene trabajo asegurado sin necesidad de invertir recursos en la captación del cliente final. Además, el trabajo de definición/diseño del producto ya está en su gran parte realizado. La empresa “sólo” debe concentrarse en el servicio.
Hay muchas otras líneas operativas típicas que se podrían comentar. Por ejemplo la producción serie, el montaje con instalación, la producción a medida, etc. Pero tenemos esperando a nuestro Servicio de la Universidad, así que vamos con él, y dejamos los otros ejemplos para mejor ocasión.
¿Cuál es la línea operativa de nuestro Servicio?. Empecemos por hacer una propuesta, y después daremos las explicaciones:
Las etapas básicas de nuestra línea operativa las podríamos expresar de la siguiente forma:
- Primero definimos qué servicios vamos a proporcionar (POLÍTICA)
- En segundo lugar planificamos la realización de estos servicios (PLANIFICACIÓN)
- Finalmente ejecutamos el servicio (SERVICIO Y CUENTAS).
CUENTAS es un proceso que tiene por objeto gestionar las cuentas de acceso de todos los usuarios al sistema de la universidad, lo diferenciamos del proceso SERVICIO por su relevancia para la seguridad de los datos en la universidad. Si no fuera por este hecho, hubiéramos metido todos los procesos dentro de uno solo: SERVICIO.
Dentro de SERVICIO tienen lugar numerosos tipos de servicio: instalación de nuevas máquinas y software, configuración de equipos, reparación de equipos, actualización de software, etc. Y actúan en diferentes áreas de la universidad: clases, despachos de profesores, sobre el propio Sistema, ordenadores de los servicios administrativos, etc.
Los procesos de SERVICIO comparten un nexo común, todos reciben instrucciones de un proceso previo, el de PLANIFICACIÓN. El proceso de PLANIFICACIÓN recibe como entrada las necesidades de servicio por un lado, y las directrices a cumplir por otro. Las necesidades provienen de profesores, personal administrativo, y alumnos. Y las directrices provienen de la Dirección de nuestro Sistema. En función de las directrices, las necesidades de servicio, y los recursos disponibles, el proceso de PLANIFICACIÓN debe dirigir y controlar a los procesos de SERVICIO y CUENTAS.
Nos explicaba MªCarmen que a principios de curso se contactaba con los profesores para determinar los recursos informáticos que iban a precisar en el desarrollo de sus clases. Este proceso también lo metemos aquí dentro, y también cualquier proceso que sea asimilable a la misma naturaleza: determinar qué hace falta, pensar cómo hacerlo y planificar su ejecución. En el Manual de Calidad o en el procedimiento que corresponda ya explicaremos cuántos procesos de este tipo tenemos y cómo se ejecuta cada uno de ellos.
EL proceso que denominamos POLÍTICA también lo incluimos en la línea operativa. Le llamamos POLÍTICA como podríamos llamarle “MANOLITO”, podemos bautizar nuestros procesos como queramos, faltaría más.
Consideramos que POLÍTICA forma parte de la línea operativa porque sus directrices y requisitos condicionan fuertemente la actuación de PLANIFICACIÓN. PLANIFICACIÓN presta el servicio que solicitan los alumnos y profesores si antes POLÍTICA le ha dicho que debe hacerlo. Si no, pues no hay servicio. A su vez, POLITICA recibe instrucciones del cliente, la Dirección de la Universidad, expresadas de la mejor forma que sus intelectos permitan.
En POLÍTICA se elaboran las directrices e instrucciones para PLANIFICACIÓN, pero también hacen más cosas. Los procesos de POLÍTICA son ejecutados por la Dirección del Servicio, la Dirección de nuestro Sistema de Calidad. Las directrices e instrucciones deberían emanar de un plan estratégico previo (que no es el plan del Rector). De lo contrario, la Dirección sería un mero vehículo de transmisión de instrucciones, del Rector a PLANIFICACIÓN.
En POLÍTICA debería tener lugar todo el despliegue estratégico propuesto por ISO 9001: revisión de los resultados obtenidos, revisión de la Política de Calidad, y establecimiento de Objetivos.
Paso 3: Añadir los procesos de soporte a la línea operativa y los de Dirección
Empecemos en primer lugar por colocar al capitán del buque. Pongamos en nuestro mapa una cajita llamada DIRECCIÓN, MEJORA CONTINUA, ESTRATEGIA, o lo que queramos. Allí tendrán lugar los procesos que hemos mencionado antes. En nuestro ejemplo ya tenemos esta cajita, la pusimos formando parte de la línea operativa. Los que no la tengan ya, que la pongan, luego ya veremos cómo se relaciona con el resto del sistema
A continuación podemos proceder colocando los procesos de soporte a la línea operativa. Estos procesos son los que proveen de recursos a esta línea.
La línea operativa es la espina dorsal de nuestro sistema de gestión. Cualquier actividad que no forme parte de ella debe adaptarse a ella, incluyendo los procesos de soporte. Este es un problema típico de las administraciones públicas, donde los procesos burocráticos de soporte frenan el servicio al ciudadano, pero también lo encontramos en muchas otras empresas: los clientes esperan mientras la empresa se mira el ombligo.
Coloquemos los procesos de soporte en nuestros ejemplos.
Empresa comercial de distribución mayorista:
Hemos continuado el esquema añadiendo unos cuantos actores más que nos faltaban: los proveedores, un hipotético sistema informático, y el almacén.
En función de los pedidos recibidos, de la disponibilidad de estoc, y de las directrices de la Dirección en cuestiones de aprovisionamiento, se establece contacto con los proveedores para realizar pedidos. A continuación, los productos comprados son inspeccionados a su entrada y colocados en el almacén.
Para preparar los pedidos necesitamos: infraestructura para trabajar, personal formado, pedidos que preparar, productos que recopilar del almacén, y embalajes. Tenemos representado todo esto menos la gestión de los recursos humanos y de infraestructura (ISO 9001 también destaca el ambiente de trabajo como un recurso a gestionar). Estos procesos son de soporte, pero no actúan únicamente sobre la línea operativa, tienen un alcance más global. Lo mismo ocurre con la gestión de incidencias, acciones CC/PP, auditorías internas, etc. Habrá que buscar una forma de expresar esta relación. Lo veremos más adelante.
Empresa de servicios a medida
El soporte principal que necesita este tipo de empresa también está relacionado con la compra de productos a proveedores. Aunque no todos los productos van a parar al almacén porque es frecuente recibir los materiales en obra, por eso hemos tendido el circuito paralelo (siempre con inspección previa, para detectar los errores cuanto antes).
El sistema informático común no lo identificamos en el mapa. No lo hacemos porque no suele tener el papel central que ocupa en las empresas de perfil más comercial. El verdadero plan de ataque no reside en un sistema común, está en los ordenadores y la documentación controlada por PLANIFICACIÓN y por DIRECCIÓN Y CONTROL DEL SERVICIO, y también en las cabezas de sus integrantes.
Vayamos ahora a por los procesos de soporte de nuestro Servicio universitario:
“Tú pide que ya llegará, mientas tanto trabaja con lo que tienes”. Esta es una ley no escrita que predomina en la administración de “lo público”. Los recursos proporcionados a la línea operativa dependen de procesos administrativos ajenos a ella y emanan de presupuestos realizados por agentes externos al sistema (una combinación explosiva). Operativamente, lo ideal sería que el Servicio dispusiera de un presupuesto conocido y mecanismos para surtirlo en función de las necesidades (con mecanismos de control incluidos). Seguramente nuestro caso no es tan grave porque la mayoría de los recursos los proporciona la Universidad (más cercana a nuestro sistema y sensibilizada porque le va su comodidad en ello). Esta relación la representamos con las flechas que vinculan a la DIRECCIÓN con la Dirección de la Universidad. La flecha que va de los procesos de GESTIÓN DE LOS RECURSOS Y COMPRAS a las Administraciones Públicas expresa las “relaciones lejanas”. Ambos agentes, Universidad y Adm. Públicas, compran lo que hemos pedido, o algo que se le parece, y también nosotros compramos algunas cosas (suponiendo que tenemos dinero en la caja o alguna cuenta abierta en los proveedores de la zona).
El esquema representado viene a ser un sistema de aprovisionamiento híbrido entre la compra directa (presupuesto a disposición del Sistema o capacidad de compra por otra vía) y la provisión por solicitud (sin presupuesto disponible, “otros” compran lo que pedimos).
Paso 4: Añadir los procesos que afectan a todo el sistema
Llegados a este punto tenemos el corazón de nuestro negocio representado, pero nos falta el resto de los órganos dan vida al sistema.
Procesos de gestión de incidencias, productos no conformes, etc.
Alguien tiene que apartar las piedras del camino. De forma más o menos organizada, todas las organizaciones se enfrentan a los problemas que genera el trabajo mal hecho. Estos procesos son distintos según la naturaleza del error. No es lo mismo el proceso de tratamiento de productos no conformes de un taller de producción, que la solución de un problema administrativo, o la gestión de un problema de servicio.
En términos generales estos procesos tienen la siguiente configuración:
Transforman problemas en soluciones. En producción, estos procesos detectan productos no conformes y los rechazan (o reoperan, o admiten bajo ciertas condiciones). Si se trata de un error reclamado por un cliente; se atiende, se investiga, y si hemos hecho algo malo, se corrige, y luego se informa al cliente dándole las satisfacciones que convenga. Si es una no conformidad en una auditoría interna; también se debe corregir la situación, y además se deben emprender acciones correctivas (si seguimos ISO 9001).
En potencia estos procesos pueden recibir entradas de cualquier proceso del sistema. Esta variedad de situaciones impide representarlas todas, y por eso hay que encontrar alguna forma de expresar esto.
Una solución es trazar una línea discontinua en nuestro mapa que simbolice el sistema completo:
Aunque otra solución más vistosa es identificar algún proceso de gestión de incidencias que destaque sobre los demás, y cogerlo como bandera. Mostraríamos ese y ningún otro. Los demás procesos podemos presentarlos en el Manual o en algún procedimiento. Allí explicaremos qué, cómo, cuándo y quién.
El mapa de procesos debe dar una visión general de nuestros procesos y sus relaciones. Si lo recargamos en exceso, no lo entenderemos ni nosotros mismos. Hay que sacrificar información, porque si la ponemos toda, no comunicaremos ninguna.
Procesos de gestión de los recursos
Nuestro sistema de gestión necesita infraestructura para trabajar: instalaciones, equipos, herramientas, etc. Y necesita personas para trabajar, profesionales con la competencia necesaria para desarrollar las funciones encomendadas. La gestión de los recursos se ocupa de determinar qué necesita cada proceso y emprender las acciones que sean necesarias para asegurar que cada proceso dispone de los recursos necesarios.
Las necesidades se pueden satisfacer trabajando sobre lo que hay -en los RRHH con actividades de formación al personal, y en INFRAESTRUCTURA con acciones de mantenimiento de la infraestructura-, o bien incorporando nuevas fuerzas al Sistema –contratación de personal cualificado, compra de equipos, etc.-.
Aquí también podemos utilizar el truco de la raya discontinua para representarlos, o destacar alguno que nos interese.
Si algo es importante en nuestro sistema: destaquémoslo!
Acciones correctivas y preventivas
Este tipo de acciones han llegado de la mano de las Normas de gestión para grabarse a fuego en las neuronas de los profesionales que trabajamos con ellas.
Una acción correctiva no es lo mismo que una acción preventiva, sus salidas se parecen, pero sus entradas son bastante diferentes. No obstante, no parece descabellado meterlas juntas en una misma caja.
Aprovechamos, de paso, para establecer su relación con la gestión de productos no conformes. Cuando hay un problema se debe corregir, pero además debemos evaluar la necesidad de emprender acciones para evitar que vuelva a suceder (acciones correctivas).
Recuerde que todo esto es sólo una propuesta de representación, seguro que hay otras formas de expresar lo mismo y, sobre todo, otras formas que son capaces de destacar las singularidades de su sistema.
Satisfacción del cliente, auditorías internas y análisis de datos
Esta es una lista no exhaustiva de otros procesos que tienen un alcance global.
No los vamos a meter todos dentro de una misma caja porque no comparten entradas ni salidas, aunque están relacionados entre sí.
El propósito de representar estos procesos y sus relaciones con un mínimo de exhaustividad nos conduce a un galimatías de cajas y flechas. Si estuvieran ellos solos, nos podríamos aventurar a dejarlo así, pero también tenemos que poner el resto de los procesos. Probablemente tendríamos que alargar mucho algunas flechas, recargando el mapa innecesariamente. Mi consejo es primar la comunicación por encima de la exhaustividad.
ISO 9001:00 requiere que identifiquemos los procesos del sistema de gestión de la calidad y sus relaciones. Pero no pide que tengamos que representar todo esto en una página tamaño DIN A4, y que encima le llamemos mapa de procesos. Así que no hay ningún impedimento formal para que hagamos un mapa de procesos que destaque lo que nos interesa, y obviar las relaciones y los procesos que no queremos destacar.
Dejamos en manos del lector la composición final de los mapas que hemos ido construyendo en este “mini tratado”. Puede encontrar ejemplos acabados en Portalcalidad, o plantear sus dudas en los foros. Deseamos haber contribuido a fijar un marco de trabajo que le permita salir airoso en la construcción de mapas de procesos y, sobre todo, que le ayude a analizar sus operaciones mediante la representación abstracta de lo que se está haciendo.
Ejemplo de mapas de proceso
No hay comentarios:
Publicar un comentario