Blog

Modelos de referencia de procesos (I). El Process Classification Framework (PCF)

Process Classification Framework

Un elemento fundamental de la arquitectura empresarial, y una herramienta imprescindible de una reingeniería es el mapa de procesos: esa identificación estructurada de los procesos de negocio que aplican a una empresa u organización.

 

Ese mapa de procesos puede ser el primer entregable de la fase (AS-IS) de una reingeniería y resulta fundamental porque nos da el marco sobre el que apoyar todo lo demás. Sin embargo, hacer un mapa de procesos partiendo de una hoja en blanco es más difícil de lo que puede parecer. Y hacerlo claro y completo, más todavía.

 

Para ayudar en esa labor, y para proporcionar cierta homogeneidad y algo parecido a una estandarización, surgen los modelos de referencia de procesos o frameworks. Los modelos de referencia sin como una especie de estantería que ordenan el conocimiento estableciendo espacios y secciones donde colocar nuestros libros, que, en este caso, serían los procesos de negocio  nuestra compañía. Nos proporcionan un marco general, particularizable para cualquier empresa, de los procesos de negocio de una compañía. En algunos casos son sectoriales o de aplicación particular (como puede ser el caso de eTOM para el sector de las Telecomunicaciones, ITIL para la prestación de servicios TI o SCOR para el caso de la cadena de suministro) y en otros, ser de propósito general como el caso que nos ocupa en este post: PCF.

 

PCF significa Process Classification Framework y está desarrollado por la APQC (American Productiviy & Quality Center), una organización sin ánimo de lucro que integra a más de 500 empresas y que aspira a ser la máxima autoridad en materia de mejora de procesos y rendimiento, mejores prácticas y gestión del conocimiento.

 

PCF es una clasificación estructurada y jerárquica de procesos, El primer nivel, categoría, se ordena de una forma que recuerda a la Cadena de Valor de Michael Porter, distinguiendo entre los procesos operativos (que se corresponderían con los procesos primarios) y los de gestión y soporte (que se corresponderían con los estratégicos y de soporte). Según eso, el mapa de procesos de PCF, en su primer nivel queda como se muestra en la figura;

 

PCF - Process Management Framework categories

 

Se observa que en PCF existen 13 categorías de procesos, a saber:

 

  1. Develop visión and strategy
  2. Develop and manage products and services
  3. Market and sell productos and services
  4. Deliver physical products
  5. Deliver services
  6. Manage customer service
  7. Develop and manage human capital
  8. Manage information technology (IT)
  9. Manage Financial Resources
  10. Acquire, construct and manage assets
  11. Manage enterprise risk, compliance, remediation and resiliency
  12. Manage external relationships
  13. Develop and mange business capabilities

 

Esta es la visión en un primer nivel, el que se denomina categoría. Pero PCF es jerárquico y cada nivel se descompone en otros de mayor nivel de detalle, así hasta un quinto nivel. En concreto, el concepto que corresponde a cada nivel es:

 

  • Categoría
  • Grupo de procesos
  • Proceso
  • Actividad
  • Tarea

 

Veamos un ejemplo en descomposición. Nos vamos a centrar en la parte de venta de productos y servicios. Vamos a ir descomponiendo y seleccionando un elemento en cada nivel que, para mayor claridad, marcamos en negrita. En este ejemplo, intentamos llegar hasta el nivel en que registramos los datos de contacto de un cliente al que hemos vendido un producto o servicio. Descomponiendo sobre PCF al final tendríamos lo siguiente:

 

  • Categoría: 3.0 Market and Sell Products and Services
    • Grupo: 3.1 Understand markets, customers, and capabilities
    • Grupo: 3.2 Develop marketing strategy
    • Grupo: 3. 3 Develop and manage marketing plans
    • Grupo: 3.4 Develop sales strategy
    • Grupo: 3.5 Develop and manage sales plans
      • Proceso: 3.5.1 Manage leads/opportunities
      • Proceso: 3.5.2 Manage customers and accounts
      • Proceso: 3.5.3 Develop and manage sales proposals, bids, and quotes
      • Proceso: 3.5.4 Manage sales orders
        • Actividad: 3.5.4.1 Accept and validate sales orders
        • Actividad: 3.5.4.2 Collect and maintain account information
          • Tarea: 3.5.4.2.1 Administer key account details
          • Tarea: 3.5.4.2.2 Retrieve full customer details
          • Tarea: 3.5.4.2.3 Modify involved party details
          • Tarea: 3.5.4.2.4 Record address details
          • Tarea: 3.5.4.2.5 Record contact details
          • Tarea: 3.5.4.2.6 Record key customer communication profile details
          • Tarea: 3.5.4.2.7 Review involved party information
          • Tareas: 3.5.3.2.8 Terminate involved party information
        • Actividad: 3.5.4.3 Determine availability
        • Actividad: 3.5.4.4 Determine fulfillment process
        • Actividad: 3.5.4.5 Enter orders into system
        • Actividad: 3.5.4.6 Identify/perform cross-sell/up-sell activity
        • Actividad: 3.5.4.7 Process back orders and updates
        • Actividad: 3.5.4.8 Handle sales order inquiries including post-order fulfillment transactions
      • Proceso: 3.5.5 Manage sales partners and alliances

 

Y así hasta llegar a varios cientos (en realidad algunos pocos miles) de elementos entre categorías, grupos de proceso, procesos, actividades y tareas.

 

Este framework PCF es accesible  de forma gratuita tanto en formato PDF como en excel y, actualmente se encuentra en su versión 7.2.1. Además, y aunque PCF es esencialmente transversal a cualquier sector, existen particularizaciones sectoriales disponibles en la misma web de APQC. Es por tanto, probablemente, el mejor punto de partida si no disponemos de un framework más específico para nuestro caso de estudio y reingeniería.

 

En próximos posts veremos algún otro modelo de referencia pero éste es, probablemente, el más transversal que podemos encontrar.

 

¿Para qué una arquitectura empresarial en una reingeniería de procesos?

arquitectura empresarial

En el artículo anterior de este blog intentamos explicar lo que es una arquitectura empresarial. Ahora nos centramos en su utilidad: ¿Para qué una arquitectura empresarial?

 

Recordamos que hablábamos de que una arquitectura empresarial era un marco conceptual que explicaba la estructura y funcionamiento de una empresa. Y que, en nuestra visión, siete eran los elementos que conformaban esa arquitectura empresarial, siendo nucleares, casi obligatorios, los cuatro primeros y convenientes o complementarios los tres últimos:

 

  • Mapa de organización (nuclear)
  • Mapa de procesos de negocio (nuclear)
  • Mapa de sistemas (nuclear)
  • Mapa de información (nuclear)
  • Modelo de negocio (complementario)
  • Porfolio de productos y servicios (complementario)
  • Mapa de tecnologías (complementario)

 

Los cuatro elementos nucleares, a saber, mapa de organización, mapa de procesos, mapa de sistemas y mapa de información tienen una clara relación con la reingeniería de procesos.

 

Hablemos ahora de su utilidad en el ámbito de una reaingeniería.

 

La utilidad de los modelos nucleares

 

Mapa de procesos

 

En primer lugar, y el más fácil de entender, el mapa de procesos. Una reingeniería de procesos se centra, precisamente, en esos procesos de negocio. El mapa de procesos actúa como la descripción en un primer nivel de detalle de los procesos de una compañía y sus relaciones.

 

Si ya existe previamente a la reingeniería, será un ‘input‘ evidente en el levantamiento (identificación, modelado y análisis) de los procesos actuales (AS-IS). Y si no existe, será, precisamente, uno de los primeros pasos en la labor de reingeniería.

 

Cuando definamos los procesos del futuro (TO-BE) ese mapa puede verse o no afectado dependiendo de en qué nivel de detalle se produzcan los cambios de procesos. En cualquier caso, finalizada la reingeniería, el mapa de procesos final será un entregable evidente de esa reingeniería. El mapa de procesos es un elemento intrínseco a una reingeniería así que lo necesitaríamos, incluso aunque no nos planteásemos definir una arquitectura empresarial.

 

Mapa de organización

 

No resulta tampoco difícil entender el papel del mapa de organización. Las tareas y actividades de un proceso son realizadas con frecuencia por personas, que ejercen unos roles y pertenecen a unas unidades organizativas, jerárquicas o funcionales. Incluso las tareas que son automáticas, deben realizarse ‘en nombre de‘ o ‘bajo la responsabilidad de‘ un rol o unidad organizativa.  El mapa de organización, pues, identifica las unidades y ubica los roles, que participan en los procesos.

 

Y el manual de funciones que puede acompañar al mapa de organización se corresponde en buena medida con esas tareas y funciones que realizan las unidades de la organización. Además, una reingeniería, caso de ser profunda, puede afectar no sólo a los procesos sino también a la propia organización (recuérdese que algunas de las estrategias de mejora de procesos hacían referencia a la organización). Por todo ello, el mapa de organización debe existir y ser coherente con los procesos de negocio, tanto en la situación de partida (AS-IS) como en la objetivo (TO-BE).

 

Los dos elementos anteriores, mapa de procesos y organización, son tan evidentes, que casi no había lugar a la discusión. Los dos siguientes necesitan algo más de explicación, pero tampoco será dif´ícil de comprender su utilidad/necesidad.

 

Mapa de sistemas

 

La argumentación en favor de la necesidad de un mapa de sistemas es inicialmente parecida a la relativa al mapa de organización. Hoy en día es casi inconcebible hablar de procesos sin que existan unos sistemas que los soporten, al menos parcialmente.

 

Muchas de las tareas que realizan las personas se llevan a cabo sobre un sistema de información o bien dejan trazas en él de la tarea realizada y los datos obtenidos. Y las tareas automáticas, por definición, se ejecutan sobre un sistema.

 

Por tanto, en la descripción de un procesos de negocio resulta hoy en día casi imprescindible identificar sobre qué sistema de información se realizan o dejan traza las tareas que componen los procesos. Además, un sistema puede condicionar los cambios que podemos hacer en un proceso o, más bien, la facilidad o dificultad de implantar esos cambios. En esa línea, una utilidad no menor de disponer de un mapa de sistemas es poder identificar a qué sistemas afectan los cambios de proceso que proponemos. Esa afectación tiene rerpercusiones evidentes en el coste y tiempo de llevar a cabo esos cambios y es, por tanto, un criterio de decisión.

 

Mapa de información

 

De los cuatro elementos obligatorios de la arquitectura empresarial, el menos común en la realidad de las empresas y el menos evidente es, probablemente, el mapa de información.

 

Disponer de un mapa de información nos ayuda a entender dónde podemos encontrar los datos de cara a realizar un informe o un análisis. Esa utilidad es independiente de una reingeniería de procesos.

 

Sin embargo, en el ámbito ya de una reingeniería, dado que es casi inevitable que afecte a los sistemas de información, debe realizarse de forma que se simplifique y mejore el gobierno y calidad de los datos.

 

Debe definir con claridad, y concentrándola en el menor número de procesos y actividades posible, dónde se crean o modifican los datos clave para la empresa. En ese sentido, es muy deseable que, caso de que exista en la empresa una política de master data management, exista un trabajo conjunto con la iniciativa de reingeniería para clarificar y establecer políticas de maestría de datos (organizativa y en sistemas).

 

Aunque disponer de un mapa de información actualizado es, probablemente, la tarea más compleja del establecimiento de una arquitectura empresarial, sus réditos pueden ser importantísimos especialmente hoy en día que, dado el auge de disciplinas como el Big Data o el Machine Learning, caminamos hacia organizaciones data-centric o data-driven.

 

La utilidad de los modelos complementarios

 

Los otros elementos son útiles pero en general sirven más bien como contexto.

 

El modelo de negocio es siempre interesante como información de contexto, pero se convierte en muy importante si la reingeniería va a ser tan profunda que va a afectar a ese modelo de negocio. En ese caso, deberíamos también de disponer de ese modelo de negocio tanto en su versi`ón AS-IS como TO-BE, al igual que en el caso de los modelos vistos hasta ahora.

 

La información del mapa de tecnologías es interesante teniendo en cuenta que, con casi total probabilidad, la reingeniería va a modificar los sistemas de información y, eventualmente, el mapa de sistemas. Si como consecuencia de la reingeniería se hace conveniente implantar un nuevo sistema, conviene disponer de la información de las arquitecturas y tecnologías ya presentes en la compañía para tomar una decisión coherente con esa situación.

 

Finalmente, la información del porfolio de productos y servicios actúa en la mayoría de los casos, simplemente como contexto. Aunque, en el caso de reingeniería de procesos que afecte a los procesos comerciales o de relación con el cliente, puede condicionar algún detalle. Igualmente, si acompañando a la reingeniería de procesos se está realizando una transformación digital que afecte a ese porfolio, muy especialmente si se están incluyendo elementos digitales en los productos y servicios, es probable que los procesos que los gestionan cambien también.

 

Vale la pena

 

Es preciso saber y reconocer que establecer una arquitectura empresarial completa y coherente, precisa un esfuerzo. Y mantenerla al día también. Sin embargo, los beneficios de cara a una reingeniería, como hemos visto, son muy, muy grandes y la hacen casi imprescindible. Más allá de la reingeniería, una arquitectura empresarial clara, documentada y actualizada puede ser un tesoro para la gestión de las compañías digitales.

 

Nosotros creemos que el esfuerzo vale la pena.

 

Concepto y elementos de una arquitectura empresarial

arquitectura empresarial

La idea de arquitectura empresarial tiene ya un largo recorrido y es importante para proyectos ambiciosos de reingeniería y transformación digital. Sin embargo no es, probablemente, ni muy conocida ni tampoco suficientemente aplicada.

 

Es cierto que la idea de arquitectura empresarial probablemente sólo tenga pleno sentido cuando tenemos la intención y capacidad de contemplar y gestionar la empresa en su conjunto, y realizar transformaciones de calado especialmente en las dimensiones de organización, procesos y sistemas.

 

Y es bastante cierto también que no ha llegado a consolidarse suficientemente ningún estándar en el mercado siendo qui´za lo más parecido a ese respecto las aportaciones de TOGAF y su método ADM.

 

De todas formas, ya volveremos en un siguiente artículo a razonar sobre la utilidad y aplicabilidad de una arquitectura empresarial. En éste sólo vamos a intentar proporcionar algo parecido a una definición e identificar los elementos que componen esa arquitectura empresarial. En ambos cometidos, y a sabiendas de que no hay ni definiciones ni estándares ampliamente aceptados, aportaremos nuestra particular visión al respecto.

 

De una forma sencilla, podemos decir que:

 

Una arquitectura empresarial es un marco conceptual que explica la estructuración y funcionamiento de una organización.

 

Seguramente, para quien nunca se haya tropezado con este concepto la definición anterior parezca vaga. Y en cierto modo lo es, pero no es fácil dar con otra que sea correcta y al tiempo sencilla. Mejor que eso probablemente sea conocer sus componentes y cómo se debe usar.

 

En nuestro entendimiento, una arquitectura empresarial debe incluir los siguientes elementos:

  • Mapa de organización
  • Mapa de procesos de negocio
  • Mapa de sistemas
  • Mapa de Información

 

Veamos algo más de cada uno de esos elementos.

 

Mapa de organización

 

Éste es, quizá, el elemento más sencillo de conseguir y entender en la práctica.  Se trata de un dibujo o modelo de la estructura de organización en sus vertientes jerárquica y funcional.

 

Por un lado, una estructura jerárquica (lo que, familiarmente llamaríamos el organigrama) donde se reflejan unidades organizativas, cadenas de mando y responsabilidades.

 

Por otro lado una estructura funcional que complementa la anterior y que identifica grupos operativos o de trabajo para la ejecución de tareas que no constan en la organizaci´ón jerárquica. Con frecuencia, la estructura jerárquica y funcional son coincidentes. Sin embargo, existen situaciones en que no es así y, en ese caso, debemos también disponer de la organización funcional. Algunos casos en que pueden no coincidir completamente la estructura jerárquica y la funcional serían, por ejemplo:

 

  • La organización jerárquica no llega a suficiente nivel de detalle (quizá porque no existe ningún mando o directivo específico) y existen grupos operativos o de trabajo relevantes para los procesos y la operación, que no constan en la organización jerárquica.
  • La organización no es una jerarquía simple sino que existen dependencias múltiples y complejas como en organizaciones matriciales o en red.
  • etc

 

Es conveniente que el mero dibujo e identificación de unidades y dependencias entre ellas, venga acompañado por lo que denominaremos un manual de funciones, es decir, una descripción somera pero clara de las responsabilidades y actividades de esas unidades. Ese manual de funciones debe de ser, además, coherente con el mapa de procesos de negocio del que tratamos a continuación.

 

Mapa de procesos

 

Se trata de un esquema de alto nivel de los procesos de negocio que se ejecutan en la compañía. Cuando estamos en el ámbito de una arquitectura empresarial no es preciso bajar a un modelado detallado de procesos sino más bien, sino una identificación en un primer nivel de detalle, una descripción de alto nivel del proceso, sus entradas y salidas y los otros procesos del mapa con que interacciona.

 

Aunque el mapa de procesos que se incluye en una arquitectura empresarial es de alto nivel, es muy importante que cualquier modelado de mayor nivel de detalle sea plenamente consistente con el mapa de alto nivel y se desarrolle sólo a modo de ‘zoom’ de este mapa de procesos de la arquitectura.

 

Mapa de Sistemas

 

Tanto los procesos de negocio en su mayor parte, como la información de la compañía se soporta hoy en día sobre sistemas de información.

 

Es importante disponer de un mapa de sistemas. En el mapa de sistemas se identificarán todos los sistemas que soportan el funcionamiento de la compañía, las interacciones y las interacciones fundamentales entre ellos,

 

De cada sistema deberemos saber, al menos, un esbozo de alto nivel de su funcionalidad, sus interacciones principales con otros sistemas y los elementos de información que gestiona.

 

Como en todo lo que tiene que ver con la arquitectura empresarial es muy importante la coherencia. Dado que los sistemas soportan los procesos las piezas deben encajar perfectamente. De igual manera, dado que los sistemas almacenan y consultan información, el mapa de sistemas debe ser plenamente coherente con el elemento que veremos a continuación, el mapa de información.

 

Mapa de Información

 

El mapa de información, que siempre ha sido relevante, cobra mucha mayor importancia hoy en día con el auge de las tecnologías muy basadas en datos (Big Data, Machine Learning, etc)

 

Lo que contiene un mapa de información es una identificación de las entidades de información fundamentales que se manejan en la compañía como, por ejemplo: clientes, productos, facturas, pedidos, etc, los principales datos asociados a ellas y sus relaciones.

 

Por cada entidad de información hay que identificar los procesos y sistemas que las gestionan, distinguiendo, además, si esa gestión es creación de la información, modificación, consulta o borrado.

 

Y, de nuevo, con una llamada a la coherencia y al rigor. Coherencia porque lo que se diga en cuanto a la generación y uso de la información en procesos y sistemas debe ser coherente con lo identificado en el mapa de procesos y el de sistemas. Y rigor, porque, al igual que ocurre en los procesos, el mapa de información se desarrolla luego en mayores niveles de detalle llegando a mapear a entidades y tablas de bases de datos.

 

Otra información interesante

 

No lo consideramos plenamente integrado dentro de la arquitectura empresarial pero, cuando se va a acometer un cambio importante, una reingeniería o transformación digital, conviene que, acompañando a la arquitectura empresarial dispongamos del modelo de negocio (típicamente realizado con el lienzo de modelo de negocio), una descripción del porfolio de productos y servicios y un censo de las tecnologías más relevantes usadas en el mapa de sistemas.

 

***

 

Entendemos que no es fácil empaparse a la primera del significado y utilidad de una arquitectura empresarial pero estamos convencidos de que merece la pena. Esperamos que este artículo proporcione una primera aproximación o , al menos, que despierte en el lector el interés por el tema.

 

En el próximo post explicaremos un poco más su importancia y cómo se utiliza y seguro que entonces se entenderá mejor. Hasta entonces.

 

Estrategias de mejora de procesos (y VII). Perspectiva de tecnología

Perspectiva de tecnología

Finalizamos con este artículo la larga serie de posts dedicados a estrategias generales de mejora de procesos de negocio. En este caso adoptamos la Perspectiva de tecnología, es decir cómo usar las posibilidades que la tecnología nos brinda para mejorar los tiempos de proceso, la eficiencia o la calidad.

 

Como en toda la serie, nos apoyamos en la clasificación y aportaciones que se mencionan en el libro ‘Fundamentals of Business Process Management‘ de Marlon Dumas, Marcello La Rosa, Jan Mendling y Hajo A. Reijers. Pero, como en toda la serie, hacemos una interpretación libre y añadimos nuestra propia visión e ideas cuando nos parece conveniente. En este artículo, en concreto, nos separaremos algo más de la habitual con el ánimo de dar una visión más amplia de las posibilidades de la tecnología.

 

Dos son las estrategias que nos proponen originalmente los autores.

 

Por un lado tenemos la automatizar actividades, es decir, hacer que ‘las máquinas’ hagan todo o parte de las actividades que componen el proceso. En algunos casos, fundamentalmente en procesos industriales, esas máquinas serán máquinas físicas (robots), pero con mucha frecuencia estaremos hablando más bien de software, de sistemas. Automatizar tiene el beneficio en general de reducir tiempos y errores. Suele traer también consigo grandes ahorros de costes, fundamentalmente en mano de obra, pero siempre hay que tener en cuenta que desarrollar e implantar una automatización conlleva una inversión, que no es raro que sea de cierta envergadura. Además, automatizar, hay que tenerlo en cuenta, tiende a introducir cierto grado de inflexibilidad.

 

Los autores nos aportan una segunda estrategia algo ambigua que denominan tecnología integral y que parece indicar que se aplique la tecnología de la forma más amplia posible. La aplicación de tecnología abre nuevas posibilidades aunque también implica costes y puede encontrarse con resistencias.

 

Vamos a hablar ahora algo más de tecnología y lo que ésta puede hacer por los procesos de negocio. Próximamente abriremos una nueva serie en que repasaremos las tecnologías más relevantes aplicables a la automatización y digitalización de procesos de negocio así que, en este artículo, vamos a adoptar más bien la perspectiva de funciones o aportaciones genéricas que puede realizar una tecnología a un proceso.

 

La primera aportación sería estructurar el proceso de negocio o, si se prefiere, obligar a que se siga el diseño. Es decir, se trata de que el proceso que hemos definido ‘en papel’ o sobre una herramienta de modelado, realmente se ejecute tal cual se ha definido. El hecho de que exista un sistema que vaya enlazando las tareas según las reglas definidas, y asignándosela a los roles o grupos que se hayan definido, obliga, dicho en sentido positivo, a que se aplique el proceso de negocio. Esta es una labor que realizan muy bien, por ejemplo, los BPMS (Business Process Management Systems) y, en algunos casos, aunque en menor medida, sistemas empresariales como ERPs o CRMs.

 

La segunda aportación, probablemente la más común y donde intervienen más tecnologías, es en la automatización de tareas concretas que forman parte del proceso de negocio. En esta faceta  son aplicables multitud de tecnologías incluyendo algunas muy especializadas como las dedicadas, por ejemplo, a diagnóstico médico o de redes de telecomunicaciones. Sin embargo, por su relevancia actual, destacaríamos la aportación de RPA (Robotic Process Automation) dedicada a automatizar las tareas manuales que típicamente dejan para su realización por personas los sistemas empresariales o los BPMS. En la misma línea, aunque pensando en el apartado más específico de la interacción con clientes y usuarios, situaríamos los chatbots y las interfaces conversacionales.

 

Una tercera función es el almacenamiento y recuperación de información. Esa es una labor que realizan casi todos los sistemas dedicados a proceso, incluyendo los sistemas empresariales y los BPMS. Pero, en general, estos sistemas se centran más en los datos estructurados. Por su relevancia, añadiríamos en este apartado también los sistemas de gestión documental que suelen llevar a una automatización débil de los procesos de negocio pero, a cambio, son sencillos y permiten conservar y manejar información desestructurada en forma de documentos.

 

La cuarta función que podríamos añadir es la de analizar y explotar la información de proceso. Es decir, se trata de medir no ya sólo los parámetros de una instancia de proceso, sino indicadores agregados del proceso e incluso minería de información. Aquí las tecnologías dominantes son las provenientes del tradicional Business Intelligence, hoy en día complementadas y ampliadas para las situaciones en que se justifique, con las posibilidades que ofrece Big Data.

 

Podríamos hablar de una quinta función que sería el soporte a la decisión. Esta función tiene a su vez algunos matices o variantes. Podemos estar hablando de un soporte a la decisión de naturaleza empresarial y agregada, una visión ejecutiva que, en general se apoyará enlas herramientas que vimos antes: Business Intelligence o Big Data. Pero también podemos hablar de una visión mucho más operativa, es decir, ayudar al usuario a decidir ante opciones concretas en una tarea concreta. En este caso, tendríamos a nuestra disposición desde los sistemas de gestión de reglas de negocio (BRMS, Business Rules Managemenr Systems) generalmente empotrados como componentes en los BPMS hasta, ya de forma más emergente, la aplicación de inteligencia artificial/machine learning. Este último campo es todavía más una expectativa o realización temprana que una realidad extendida.

 

Una sexta función sería la integración. Es decir, se trata de poder unir sistemas tanto propios como de proveedores y/o clientes para conseguir una digitalización extremo a extremo. En realidad, se trata de extender el resto de las funciones más allá de las fronteras de un sistema e incluso de una empresa. Existen muchas tecnologías de integración pero mencionaremos SOA (Service Oriented Architecture) y los Web Services como la arquitectura y tecnología dominantes para la integración de sistemas y procesos de una forma estándar.

 

Una séptima función sería la definición y flexibilización de la estructura del proceso. Muy relacionada con la primera función, en este caso lo que buscamos es que la definición del proceso no esté embebida en el código sino disponible como una definición externa fácilmente modificable, en general mediante herramientas gráficas y poca codificación. Esta función la traen de serie, de hecho es una de sus grandes aportaciones, los sistemas BPMS. Aunque con  un alcance algo más modesto, también es algo que traen consigo las herramientas RPA siguiendo la filosofía low-code.

 

Finalizamos con una octava función, emergente, que es la de aprendizaje y adaptación es decir, que el comportamiento del proceso se modifique ligeramente, respetando su estructura básica, para responder a variaciones en el entorno. Eso el algo que hasta hace poco se orientaba más bien a que se modificasen parámetros del proceso utilizando la función de flexibilización que acabamos de mencionar. Sin embargo hoy en día con la popularización del machine learning y la inteligencia artificial podemos esperar dosis crecientes de adaptación autónoma por parte de  los sistemas tanto software como físicos (robots, coches autónomos, etc).

 

Y con esto acabamos el repaso de posibles aportaciones, a nivel de funciones, de la tecnología a los proceso de negocio.

 

Y con esto cerramos también la serie de artículos dedicados a estrategias genéricas de procesos de negocio.

 

Dado que nos encontramos en fechas estivales, interrumpiremos durante dos semanas las publicaciones en este blog. Volvemos con vosotros el Jueves 30.

 

¡Os esperamos!

 

Artículos anteriores relacionados

 

Imagen: Fuente untitled exhibitions en Flickr

Estrategias de mejora de procesos (VI). Perspectiva del contexto empresarial

contexto empresarial

Encaramos con éste ya el penúltimo de los artículos dedicados a las estrategias de mejora de procesos, En esta ocasión hablamos de la perspectiva de contexto empresarial, es decir, aquellos socios u otras entidades que rodean a la empresa que quiere optimizar los procesos, pero que no forman parte de ella.

 

Como hasta ahora en esta serie, seguimos la tipología y aportaciones que se identifican en el libro ‘Fundamentals of Business Process Management‘ de Marlon Dumas, Marcello La Rosa, Jan Mendling y Hajo A. Reijers, haciendo una interpretación libre de ellas.

 

Tenemos que avisar que nos hemos saltado la perspectiva de tecnología que tocaba hoy, pero preferimos tratarlo en el cierre de la serie que se producirá en el siguiente post.

 

Entrando ya en materia, una estrategia que podríamos denominar extrema es la del outsourcing. Es decir, externalizamos un proceso de negocio o una parte relevante de él en otra compañía, quizá porque pensamos que lo va a hacer de forma más eficiente que nosotros, (y, puede resultar más barato) o con mayor calidad, quizá porque carecemos de los conocimientos o recursos necesarios o quizá porque lo vemos como fuera de nuestro ‘core‘ de negocio y preferimos dedicar los recursos a otras tareas. El outsourcing es unapráctica muy común aunque puede que no siempre se cuide la optimización de los procesos extremo a extremo.

 

Una estrategia complementaria, que no est´á ligada necesariamente al outsourcing pero que suele asociarse en la práctica a él, especialmente cuando se ejecuta en su modalidad off-shoring, es lo que vamos a llamar el aprovechamiento de husos horarios. Se trata de distribuir las tareas en centros situados en países diferentes en husos horarios claramente diferenciados, de forma que el proceso puede ejecutarse a lo largo de todo el día porque sus tareas se realizan en diferentes lugares del globo. Se utiliza mucho esta estrategia en centros de atención a cliente en que se montan, por ejemplos tres centros de atención f´ísicos en zonas con husos horarios separados por 8 horas. De esta forma, se puede prestar un servicio 7×24 sin que los trabajadores tengan que hacer ni turnos ni horarios extraños. Otro ejemplo muy usado por consultoras es que el consultor trabaja con el cliente digamos en España y termina una sesión de análisis por la tarde. Con sus notas, este consultor solicita a otro centro de apoyo, digamos que en la India, elabore el material y así dispone de una presentación al día siguiente a primera hora.

 

Otra estrategia, que acude a la tecnología, es el establecimiento de interfaces automatizados entre sistemas de diferentes empresas. Esto acelera mucho los intercambios y elimina errores, aunque precisa de una asociación a largo plazo entre los socios que compense los costes de desarrollar la interfaz. Un entorno típico de aplicación es en Supply Change Management, especialmente cuando se utilizan las técnicas de Just In Time. En ese caso, la información de stock tiene que ser compartida tanto por cliente como proveedores. Otra caso que he visto con cierta frecuencia es el establecimiento de una interfaz entre un sistema de ‘ticketing’ (averías) de un cliente con el sistema de ticketing de sus proveedores de servicios de mantenimiento.

 

Una última estrategia en esta perspectiva sería la de eliminación de tareas basada en la confianza en un tercero. Se basa en confiar en la información que nos da un tercero para evitar tener que hacer nosotros ese análisis y calcular o encontrar esa información. Un caso de aplicación podría ser, por ejemplo, la compartición de ‘scoring‘ de riesgo ante préstamos o primas de seguros si las partes desean realmente compartir esa información y confiar en el otro.  Al no tener que hacer nosotros ese cálculo, ahorramos coste y disminuimos tiempos.

 

En general, como vemos, todas las estrategias de esta perspectiva de entorno externo implican una relación de confianza y, en general, a largo plazo entre las partes involucradas. por lo que su ámbito de aplicación puede ser comparativamente reducido aunque sus beneficios muy interesantes.

 

En el próximo artículo, cerraremos ya esta seria hablando, ahora sí, del uso de la tecnología para la mejora de procesos, más allá de lo que ya hemos ido viendo salpicado por los artículos anteriores.

 

Artículos anteriores relacionados

 

Imagen: Fuente pixabay, dominio público

 

Estrategias de mejora de procesos (V). Perspectiva de información

Perspectiva de información

En esta quinta entrega sobre estrategias de mejora de procesos, adoptamos la Perspectiva de información.

 

Se trata, como hasta ahora, de identificar una serie de estrategias más o menos generales para mejorar los procesos de negocio, siguiendo la tipología y aportaciones que se identifican en el libro ‘Fundamentals of Business Process Management‘ de Marlon Dumas, Marcello La Rosa, Jan Mendling y Hajo A. Reijers, pero haciendo una interpretación libre de ellas y aportando nuestra propia visión donde lo consideramos oportuno.

 

La perspectiva que hoy nos ocupa, la de información, es una perspectiva algo diferente a las anteriores porque toca muy de cerca no tanto (o no sólo) el proceso en sí como el o los sistemas que lo soportan. Por eso, en esta ocasión nos vamos a tomar muchas más libertades para comentar estrategias que tienen que ver mucho con los sistemas.

 

Los autores nos proponen dos estrategias. La primera a comentar es la que denominan ‘buffering‘ y que nosotros quizá llamaríamos observador o publicación/suscripción por el motivo que en seguida comentar´emos. La estrategia consiste en lo siguiente: si  nuestro proceso depende de información que se proporciona de forma externa, para evitar consultas constantes, almacenarla (meterla en un ‘buffer‘) y suscribirnos ante esa fuente externa a las actualizaciones de esa información. Es una estrategia inteligente y que, de hecho, responde a un patrón de la ingeniería de software denominado ‘publish & suscribe‘ u ‘observer‘ y aplicable en muchos otros contextos que no son sólo la automatización de procesos de negocio. Quizá por nuestra sensibilidad hacia los sistemas de información, quizá porque conocimos antes el patrón en ese contexto, nos gusta más hablar de ese patrón de publicación/suscripción para definir la estrategia.

 

La otra estrategia que nos proponen los autores es la de adición de control. Consiste en añadir unos controles en entrada y en salida para garantizar que tanto lo que recibimos como lo que entregamos (información o materiales) es correcto. Es una estrategia con su cara y su cruz. Claramente, va en contra de la velocidad, la flexibilidad y la eficiencia pero, a cambio, tiende a garantizar la calidad. En nuestra experiencia directa nos ha sido mucho más común observar un exceso de control que la falta de él, por lo que esta estrategia estaría ya aplicada (quizá en exceso). No obstante, cuando el foco es la calidad y la exactitud, es una estrategia a nuestra disposición.

 

Los autores no nos aportan más estrategias en esta perspectiva pero si vamos a añadir nosotros algunas aportaciones propias, muy orientadas hacia los sistemas y las bases de datos.

 

Una primera estrategia sería la de la unicidad de identificadores. ¿Qué quiere decir esto?. Cuando manejamos una entidad en varios sistemas de la compañía, para poder traspasar información de forma sencilla y correcta, para conseguir informes extremo a extremo y para evitar errores, es importante ‘llamar a las cosas siempre por el mismo nombre‘ en todos los sistemas’ . Por ejemplo: si queremos identificar a un cliente, podemos elegir el CIF, o un identificador propio, pero, sea el que sea, debería ser el mismo en todos los sistemas. Si vamos a identificar equipos de red, podemos utilizar por ejemplo, su número de referencia, su dirección MAC o un identificador propio. Sea lo que sea, en todos los sistemas deberíamos utilizar el mismo.

 

Complementaria de la anterior, apostaríamos por una estandarización de identificadores. Quiere decir que, si para la entidad que vamos a identificar, existe algún tipo de identificador que domine en la industria que nos movemos, normalmente será mejor usar ése que inventar uno propio. Así, en los ejemplos anteriores, tenderíamos a escoger el CIF del cliente o el número de serie de los equipos antes que los identificadores propios. ¿Por qué? Pues porque eso nos facilita la interacción con otras organizaciones, otros sistemas y otros informes.

 

Una estrategia doble muy aconsejable (aunque no sencilla) es la de la maestría de datos, es decir, establecer qué organización y qué sistema es el maestro de aquellos datos que son compartidos. Decimos que es una estrategia doble porque es tanto técnica como organizativa. La maestría técnica indica qué sistema o base de datos es la que consideramos maestro de un cierto dato. En caso de discrepancias se tomará como bueno el dato de esa base de datos y se tenderá a propagar su información hacia el resto de sistemas que la usen. Pero también es una decisión organizativa  porque define qué unidad organizativa establece las normativas de gestión de ciertos datos y, en caso de problemas de calidad del dato, qué criterios adoptar para decidir el más correcto. Así, por ejemplo, la unidad de marketing y ventas podría ser la maestra de la información de clientes, la unidad de logística la maestra de los datos de stocks y la unidad de sistemas la maestra del censo de ordenadores personales. No siempre es fácil aplicar esta estrategia cuando partimos de un mapa de sistemas legados que no la han respetado hist´óricamente, pero eso no invalida la estrategia sino que dificulta su implantación.

 

Otra estrategia, que tiene que ver con la anterior es la concentración de las altas y actualizaciones. Idealmente cada dato debería poder ser dado de alta y modificado en un único sistema, en concreto, en el maestro y en un único punto de proceso, en general en una actividad ejecutada por la organización maestra del dato. Al concentrar en un único punto el alta y la actualización, y un punto gestionado por la organización y sistema maestro, es muy sencillo forzar la aplicación de políticas correctas de datos y evitar errores. En la práctica, puede ser poco realista en procesos complejos y mapas de procesos complejos, conseguir hacer esto en un solo punto y sistema. En cualquier caso, deben a reducir al mínimo los puntos, y aún más los sistemas, en que se produce la actualización.

 

Ya que hablamos de estrategias de difícil implementación, la reina de las estrategias sería la de normalización de los modelos de información. Se trata de conseguir que en una empresa se utilice un modelo de información similar, independiente del sistema. Esto es más una aspiración que una posibilidad realista (salvo en empresas de nuevo cuño o pequeñas). Pero sí marca una aspiración: simplificar y unificar lo máximo posible los modelos de información. Cuando se aplica SOA como arquitectura base del mapa de sistemas, se puede intentar esa normalización en los modelos de información que se intercambia en los web services dando libertad al modelo de información interno de cada sistema.

 

Una estrategia muy evidente, pero no siempre respetada, es la de utilizar los campos de información para un único propósito.  Puede parecer trivial, pero no es extraño ver que, para evitar tener que hacer modificaciones en un sistema ya en producción, se opta por reutilizar un campo destinado a otro fin. Así, por ejemplo, se puede plantear usar el campo destinado a recoger las observaciones del cliente para anexar información de una campaña comercial. A corto plazo parece inteligente porque evitamos desarrollos pero, en seguida invalida la información y hace casi imposible la obtención de informes y análisis coherentes.

 

Aunque probablemente en esta perspectiva de información se puedan añadir muchas otras posibilidades y precauciones, vamos sólo a tocar una más que es evitar los campos abiertos, es decir, el famoso texto libre. Los campos de texto libre son cómodos y en muchos casos son un gran recurso puesto que permiten añadir observaciones, comentarios, informaciones personalizadas, etc. Sin embargo, abusar de los campos de texto libre puede hacer que la información sea intratable, no tanto durante la ejecución del proceso (un humano se supone que entenderá ese texto libre) como a la hora de obtener informes o automatizar tareas ya que el texto libre es difícilmente automatizable.

 

En nuestra experiencia, hay mucho que mejorar en las prácticas habituales de tratamiento de la información en los procesos de negocio y es una pena porque de una buena información se pueden obtener muchísimos beneficios y más hoy en día con el desarrollo del Big Data, el Machine Learning y, en general, todas las tecnologías apoyadas en datos.

 

Esperamos que las estrategias indicadas, que sin duda no agotan el tema, sí aporten algo de luz.

 

En el próximo artículo, nos centraremos claramente en la tecnología puesto que abordaremos, precisamente, la perspectiva de tecnología.

 

Artículos anteriores relacionados

 

Imagen: Fuente pixabay, dominio público

 

Estrategias de mejora de procesos (IV). Perspectiva de organización

Perspectiva de organización

Damos un nuevo paso en nuestro recorrido por las diferentes estrategias de mejora de procesos de negocio y en esta ocasión nos ocupamos de la perspectiva de organización, es decir, de aquellas posibilidades que se nos abren cambiando la organización, la asignación de tareas o la capacitación y empoderamiento de los profesionales.

 

Y, como en toda la serie, nos apoyamos en la tipología y aportaciones de Marlon Dumas, Marcello La Rosa, Jan Mendling y Hajo A. Reijers en su libro ‘Fundamentals of Business Process Management‘ pero haciendo una interpretación libre de ella.

 

Varias de las estrategias que tenemos en éste bloque derivan de una estrategia general de optimización de procesos, a saber, disminuir el traspaso de trabajos entre áreas o responsables. ¿Por qué? Porque cuando se traspasa un trabajo éste normalmente entra en un buffer, una cola, y tarda un tiempo en ser atendido. Esto perjudica al tiempo total de operación y probablemente a los costes y a la satisfacción de cliente. Si el trabajo tiene además materiales asociados, estamos creando un inventario, y es bien sabido que los inventarios son elementos a disminuir todo lo posible.

 

En esa línea de eliminar traspasos está una primera estrategia que los autores mencionados llaman asignación de casos y que aboga por que la misma persona realice la mayor proporción posible de tareas asociadas a un caso. En el extremo, que una persona que gestione un caso completo. Aparte de evitar traspasos con los beneficios vistos en el párrafo anterior, el que una misma persona ejecute un caso completo, también aprovecha el conocimiento global que sobre el caso adquiere quien lo ejecuta, lo que le hace actuar más rápido y con menor probabilidad de errores y malentendidos.

 

Teniendo en cuenta que, a pesar de todo, no siempre es posible que la misma persona gestione un caso completo, son de aplicación cuatro estrategias complementarias.

 

Por un lado, el que cada caso tenga un gestor responsable. Esto es especialmente relevante en procesos de relación con cliente, ya que ese gestor responsable, no sólo coordina, facilita e impulsa la ejecución del caso, mejorando con ello tiempos y disminuyendo errores, sino que además puede actuar como interlocutor y ventanilla única con el cliente, lo cual es importantísimo de cara a la relación y a la percepción de calidad de éste.

 

Además, conviene formar equipos de cliente, especialmente al tratar con grandes cuentas, es decir, aunque deban intervenir diferentes unidades o departamentos, que los casos de un cliente los atienda el mismo equipo multidisciplinar. Esto facilita la labor del gestor del caso, aprovecha el conocimiento y sensibilidad hacia el cliente y mejora el funcionamiento general redundando en los habituales parámetros: menores tiempos, menos errores, y mayor satisfacción de cliente.

 

De cualquier forma, minimizar en lo posible el número de áreas involucradas en un caso, lo cual, de nuevo, disminuye traspasos y facilita el trabajo en equipo (como los equipos de cliente) y la labor de coordinación del gestor de caso.

 

Y, como cuarto punto complementario, hay que evitar responsabilidades compartidas entre áreas. Las responsabilidades compartidas generan roces, malos entendidos y falta de agilidad.

 

Ya en otro orden de cosas, otra posible estrategia es la de centralización virtual de equipos dispersos, es decir, tratar a los equipos que realizan la misma función como si fuese un único equipo centralizado, aunque residan en oficinas e incluso ciudades o países diferentes. Esta estrategia aprovecha las capacidades que nos ofrece la tecnología y que posibilita que para muchas tareas, la situación geográfica de la persona que la realiza sea irrelevante. Los BPMS hacen ésto posible y lo que conseguimos, en el fondo, es disminuir el número de unidades que intervienen en el proceso, ya que usamos una sola unidad operativa en lugar de tener una por cada ubicación física.

 

Una estrategia muy evidente, pero no siempre adecuada es, simplemente, aumentar los recursos dedicados a alguna tarea. Esto puede tener sentido cuando estamos sufriendo retardos en alguna tarea por falta de recursos, cuando realmente disponemos de ellos y además preferimos priorizar la minimización de tiempos de respuesta y satisfacción de cliente antes que la eficiencia en costes y recursos.

 

Una estrategia relativamente sencilla y muy potente es dar poder a los profesionales. Se trata de dar autonomía de decisión a las personas que ejecutan el proceso.  Evidentemente, esos profesionales tienen que tener capacidad técnica y demostrar que son dignos de confianza pero esa autonom´ía elimina escalados a mandos y los escalados no dejan de ser otra forma de traspaso de una tarea. Es decir, algo que, si evitamos, nos permite mejorar tiempos y costes. En este caso, además, hay otro beneficio intangible que es la mejora en la motivación de los profesionales.

 

Finalmente, hay dos estrategias que juegan un poco con la capacitación y flexibilidad de los profesionales.

 

La primera sería asignar al recurso más especializado primero. Es decir, cuando una tarea la pueden realizar dos recursos, uno más especializado y otro más generalista, asignar siempre el más especializado. ¿Por qué? Porque el más generalista tiene capacidad de tratar mayor tipología de situaciones. Asignando el más especializado primero y dejando disponible al más generalista aumentamos la probabilidad de disponer de un recurso válido para el siguiente caso y, por tanto, disminuimos la probabilidad de que una tarea se quede en espera por no disponer de un recurso. En valores medios o agregados, esto debe disminuir el tiempo de operación.

 

La última estrategia, que en realidad tiene doble cara es jugar con la especialización. A partir de la estrategia anterior ya nos damos cuenta de que disponer de recursos generalistas puede ayudar a mejorar. Pero también hay que tener en cuenta que los recursos especializados tienen capacidad para revolver casos más complejos (por ejemplo, en el caso de averías técnicas) y suelen ejecutar su tarea más rápido. Por tanto, son posibles los dos empeños, el de aumentar la especialización y el de aumentar la generalidad de los equipos. Se elegirá casa opción según las circunstancias particulares de los procesos y la plantilla disponible.

 

Con esto cerramos la revisión de las estrategias desde la perspectiva de organización. En el próximo art´´ículo veremos estrategias que tienen que ver con la información y, en esa perspectiva, sí que tendrá mucho que decir la tecnología.

 

Artículos anteriores relacionados

 

Estrategias de mejora de procesos (III). Perspectiva de diseño de procesos

diseño de procesos

En esta serie de posts que estamos acometiendo para revisar estrategias para mejorar los procesos de negocio, ahora le toca el turno al diseño de procesos. Y como siempre en esta serie de artículos nos apoyamos, aunque haciendo una interpretación propia, en las perspectivas e ideas que se recogen en el libro ‘Fundamentals of Business Process Management‘ de Marlon Dumas, Marcello La Rosa, Jan Mendling y Hajo A. Raijers.

 

Cuando hablábamos de la perspectiva de operación decíamos que en realidad nos concentrábamos más en las actividades concretas del proceso que en la visión completa. La nueva perspectiva que acometemos ahora presenta de nuevo un nombre algo engañoso (al fin y al cabo, todas las estrategias son en último término de diseño de procesos) pero a lo que se refiere diseño de procesos en este contexto es a una visión que trasciende la actividad individual para centrarse en la visión conjunta del proceso, cómo las actividades se ordenan y estructuran entre si.

 

La estrategia más evidente en esta perspectiva, quizá la más potente también, es la paralelización de actividades. Es decir, si no existe una restricción en la naturaleza de las actividades o una limitación de los recursos (por ejemplo, las personas o máquinas herramientas necesarias) las actividades se deben realizar en paralelo siempre que sea posible en lugar de hacerlo secuencialmente, en serie. ¿Por qué? Pues simplemente porque se optimiza el tiempo total del proceso. Eso, que es bueno en sí mismo, puede arrastrar consigo otros beneficios en cuanto ahorro de costes, mejora de la experiencia de cliente, etc.

 

Otra estrategia que puede ser práctica aunque también podría desvelar algún error de fondo es posponer actividades independientes. Esto lo que quiere decir es que si ninguna actividad posterior del proceso necesita de la ejecución de la actividad actual para poder hacer su parte, es mejor no apresurarse en realizar la actividad de la que nadie depende. ¿Por qué? Porque a lo mejor al final se demuestra innecesaria y nos ahorramos el trabajo. Si este caso se diese, en efecto habríamos ahorrado recursos en el caso concreto pero merecería la pena una posterior revisión del proceso y comprobar si esas actividades independientes son realmente necesarias o se pueden eliminar, no ya de la ejecución de un caso concreto, sino del diseño del proceso en su conjunto.

 

Una estrategia muy orientada a la eficiencia es diseñar con foco en el caso más frecuente, el ‘happy path‘. En todos los procesos reales se producen caso especiales, errores y excepciones pero el número de ejecuciones que siguen esos caminos alternativos  deberían constituir un subconjunto numéricamente pequeño comparado con el caso principal. Por tanto, a la hora de diseñar un proceso se debe optimizar el caso principal aunque eso sea en perjuicio de los casos especiales. La idea es que la eficiencia global mejorará ya que el happy path se ejecuta un mayor número de veces. Hacerlo así, sin embargo, puede en algún caso, convertir al proceso en más rígido o generar experiencias de cliente negativas cuando se ven afectados por los casos especiales.

 

Una estrategia que en ocasiones se centra más en la actividad y en otras en el proceso conjunto es la que podemos denominar priorizar el KO. El nombre no es intuitivo en primera instancia pero tiene mucha lógica. Esta estrategia se aplica en situaciones en que hacemos una batería de comprobaciones que debe cumplir la instancia concreta del proceso antes de ser realmente ejecutado. La estrategia consiste en priorizar las comprobaciones de forma que la primera que apliquemos sea la que más probabilidad tenga de descartar el caso (es decir, de generar un KO). La segunda comprobación, la segunda en probabilidad de descartar el caso, y así sucesivamente. De nuevo, la lógica que hay detrás de esta estrategia es una lógica de eficiencia y ahorro de recursos. Lo más barato en cuestión de ejecución de procesos es, simplemente, no ejecutarlos. Por tanto, si hay varias opciones para descartar esa ejecución, intentamos hacerlo cuanto antes, sin realizar comprobaciones adicionales que consumen tiempo y recursos.

 

Una variante de priorizar el KO sería el priorizar la clasificación. La idea es exactamente igual pero en este caso, más que descartar la ejecución de un caso, estamos intentando averiguar cómo debe seguir el proceso en las etapas siguientes para lo cual hacemos varias comprobaciones o pruebas previas. La idea en este caso es priorizar las comprobaciones más resolutivas, es decir, aquellas que con más probabilidad nos van a clasificar el caso sin necesidad de nuevas comprobaciones. Esta estrategia es muy aplicable, por ejemplo, en los primeros niveles de atención a cliente en un contact center o en el triage de las urgencias de un hospital o incluso en la atención primaria.

 

Aunque ninguna de las estrategias de esta perspectiva es muy tecnológica, la priorización del KO y, sobre todo, la priorización de la clasificación pueden verse potenciadas o incluso modificadas por una automatización de las comprobaciones. La idea para potenciar estas estrategias sería automatizar las comprobaciones siempre que sea posible, comenzando con aquellas que antes producen un KO o una clasificación. Y la modificación de la estrategia se produciría cuando lográsemos automatizar unas comprobaciones si y otras no porque, en esa situación, las comprobaciones que primero habría que aplicar serían las automáticas, incluso aunque fuesen algo menos resolutivas. La ganancia en eficiencia proveniente de la automatización superaría en este caso a la ganancia en eficiencia por capacidad de discriminación.

 

Es interesante constatar que algunas de estas estrategias (la paralelización o posponer actividades independientes) no se tratarían de manera muy diferente si de lo que hablásemos fuese de las actividades de un diagrama de Gantt correspondiente a un proyecto y estuviésemos intentando optimizar el camino crítico. Y eso es lógico porque, en el fondo, la ejecución de un proyecto es también un proceso con la salvedad de que al tratarse de un proceso personalizado, que no se repite, no tiene sentido el aplicar de forma general las técnicas de gestión de procesos sino las de gestión de proyectos.

 

En el próximo post de esta serie, hablaremos de estrategias que tienen que ver conla organización.

 

Artículos anteriores relacionados

 

Estrategias de mejoras de procesos (II). Perspectiva de operación

Perspectiva de operación

Vamos a seguir hablando de estrategias de mejoras de procesos de negocio, siguiendo la línea iniciada la semana pasada cuando adoptamos la perspectiva de relación con el cliente. En esta ocasión adoptamos la Perspectiva de operación.

 

Continuamos aplicando una interpretación libre la tipología y heurísticas propuestas por Marlon Dumas, Marcello de la Rosa, Jan Mendling y Hajo A. Reijers en el libro ‘Fundamentals of Business Process Management‘ y, según esa fuente, la perspectiva de operación se refiere a poner el foco en los elementos de un proceso de negocio, es decir, fundamentalmente nos vamos a concentrar en las actividades que componen los procesos.

 

En esta perspectiva la mejor estrategia es, simplemente, eliminar actividades.

 

Con frecuencia los procesos de negocio incluyen actividades que no aportan valor. En ocasiones, no aportan absolutamente nada. ¿Cómo es posible? Pues porque responden a una situación, una regulación, unas circunstancias o una tecnología desaparecidas pero sin que nadie haya advertido que esa actividad ya no es necesaria y se sigue haciendo por costumbre.

 

En otras ocasiones se trata de actividades que no aportan un verdadero valor o que el valor que aportan es inferior al coste que conllevan. Hay ocasiones en que lo que ocurre es que existen actividades redundantes.

 

Un caso muy común y al que conviene por ello prestar atención es a las actividades de control, es decir, actividades por las que un responsable o unidad, comprueba el trabajo de su equipo o de otra unidad. Estas actividades no aportan verdadero valor para el cliente. Vale más la pena concentrarse en hacer correctamente las actividades que sí aportan valor y eliminar controles y, en todo caso, hacer un control de calidad por muestreo estadístico en lugar de un control aplicable a todos los casos.

 

La estrategia de eliminar actividades es, con diferencia, la fundamental en este bloque, pero hay más posibilidades.

 

Una de ellas es apostar por trabajo orientado al caso espec´ífico, es decir, a trabajar individualmente con cada instancia del proceso. Dicho de otra forma, se trata de evitar los tratamientos masivos en batch. Aunque esos tratamientos masivos en batch puede traer consigo eficiencias, también tienen a aumentar tiempos medios de ejecución ya que esos batch suponen una ejecución periódica tras un tiempo de acumulación de casos en el lote.

 

Otra estrategia sería la de especialización o ‘triage, es decir, especializar una actividad en dos, tres, cuatro variantes, o las que hagan falta, para dar un tratamiento especializado, por ejemplo, por necesidad de un conocimiento especializado. Muchas veces el tratamiento especializado viene precedido por una etapa anterior de tratamiento más básico y capacidad de discernimiento de qué actividad y/o organización debe hacer el tratamiento especializado. Esta estrategia puede venir exigida por necesidades del negocio y es la que se suele utilizar, por ejemplo, en centros de atención a clientes o en la atención sanitaria, pero tienen la contrapartida de procesos menos flexibles.

 

También se puede jugar con las actividades agregando varias actividades en una (con lo que se pueden ahorrar tiempos de preparación  y, en general, ganar en calidad con la contrapartida de una menor flexibilidad e incluso de pérdida de calidad si la actividad resultante es excesivamente amplia) o, por el contrario, subdividiendo una actividad en varias con lo que tenemos los efectos opuestos, tanto positivos como negativos.

 

En todas estas estrategias la tecnología interviene, por su puesto, ya que con base en ella se realiza la automatización de las actividades tal y como se decide en el diseño de negocio. De la misma forma, por ejemplo, el triage en un centro de atención de llamadas precisa de la capacidad de transferencia de llamadas que proporciona un ACD (Automatic Call Distributor). Sin embargo, en los casos vistos no es necesario acudir a la tecnología para decidir sobre las estrategias sino sólo apoyarnos en ella.

 

Continuaremos identificando estrategias de mejora de procesos. En el próximo artículo, en concreto, nos centraremos en el diseño del proceso, su estructura.

 

Estrategias de mejoras de procesos (I). Perspectiva de relación con cliente

relación con cliente

Vamos a iniciar con este artículo, una breve serie en que revisaremos algunas estrategias generales de mejora de procesos desde diferentes perspectivas. En concreto, y empezando por la relación con cliente, tocaremos las siguientes dimensiones:

 

  • Relación con cliente
  • Operación
  • Diseño de proceso
  • Organización
  • Información
  • Tecnología
  • Entorno externo

 

Nos vamos a apoyar para ello en la excelente obra ‘Fundamentals of Business Process Management‘ de Marlon Dumas, Marcello de la Rosa, Jan Mendling y Hajo A. Reijers, libro que no podemos dejar de recomendar,  pero también adaptaremos en cierta medida lo que allí se indica y aportaremos información y estrategias adicionales fruto de nuestra propia experiencia e intentando reforzar el papel de la tecnología digital en estas mejoras.

 

Pero quizá, lo primero que conviene aclarar antes de dar inicio al estudio de la primera dimensión, es que en el rediseño de procesos no existen fórmulas matemáticas ni procedimientos completamente cerrados, por lo que siempre queda un necesario espacio para la experiencia, conocimientos e incluso creatividad del analista de procesos.

 

Lo que sí existen son una serie de heurísticas, buena prácticas y patrones repetitivos que son los que, en el fondo, vamos a recoger en esta serie de artículos.

 

Y sin más dilación, pasamos a ver estrategias posibles para la mejora de procesos en su dimensión de relación con cliente.

 

La primera estrategia es el fomento del autoservicio, es decir,  se trata de que ciertas labores las haga el cliente por sí mismo sin necesidad de ayuda humana por parte de la empresa que vende el producto o presta el servicio. En el entorno más físico podríamos pensar por ejemplo en la práctica que se está empezando a extender en los supermercados de que el propio cliente ‘se cobre’ en cajas preparadas al efecto. Esta estrategia se ve facilitada en los entornos digitales permitiendo, por ejemplo, que un cliente se configure el servicio que desea, o que se haga un autodiagnóstico de una eventual avería. Los beneficios del autoservicio son dobles. Por un lado, el cliente tiende a sentirse bien atendido y además, evidentemente, de forma inmediata. Para poder recoger este beneficio, sin embargo, es muy importante que la interfaz de usuario esté muy cuidada y muy bien diseñada con muchísimo foco en el cliente y la usabilidad, de forma que la interfaz sea agradable, fácil de usar y entender y se muestre efectiva. Por otro lado, la empresa obtiene una evidente reducción de costes de atención a cliente.

 

Este fomento del autoservicio se puede ver también reforzado por la estrategia de personalización de la interacción, para lo cual nos podemos apoyar en tecnologías muy sencillas como la gestión de cookies o muy avanzadas como Big Data o Machine Learning. Lo que se trata es de que la interacción con el usuario se adapte a sus gustos, necesidades y relación anterior con la empresa. El conocimiento del cliente puede aumentar la efectividad de acciones comerciales que se produzcan durante la interacción ofreciéndole productos cercanos a sus preferencias, por los que se ha interesado antes, o que suelen interesar al perfil del cliente. La personalización también puede ser una forma de simplificar la interacción y hacerla más eficiente ya que se reutilizan todos los datos que tenemos del cliente y se le dirige directamente al punto del proceso que interesa sin decisiones o bifurcaciones previas.

 

Otra estrategia es la reducción de contactos. Esto es preciso entenderlo bien. Los contactos con los clientes son desde un punto de vista comercial un magnífico activo para la empresa. La reducción de contactos no se refiere, por tanto, a la reducción de interacciones de naturaleza comercial o que generan experiencias positivas en el cliente. Se trata de evitar contactos de cariz más burocrático, de toma de datos, envío de documentos, etc. Ese tipo de contactos, al multiplicarse se hacen ineficientes puesto que cada contacto implica un consumo de tiempo y recursos. Además, cuando el contacto es de naturaleza asíncrona (por ejemplo, el envío de una información por correo) tiende a alargar el tiempo total de proceso. A esto se añade el que este tipo de contactos de toma de datos y documentación no suelen ser satisfactorios para la experiencia del cliente, motivo adicional para reducirlos a lo mínimo imprescindible. Si además, los contactos no están bien coordinados y se solicitan al cliente datos que ya proporcionó con anterioridad estamos generando una experiencia exasperante. Un último factor, la multiplicidad de contactos hace aumentar la probabilidad de incoherencias y errores en la información recabada.

 

Una estrategia no siempre aplicable pero muy interesante es la integración con los sistemas del cliente.  Normalmente esta opción se da sólo en entornos B2B, entre dos compañías con un aceptable nivel de digitalización y con una relación ya sea comercial o de partnership de largo plazo. Se trata de unir mediante interfaz diferentes sistemas, por ejemplo, el sistema de pedidos del cliente con el de provisión/logística del proveedor, o comunicar sistemas de gestión de almacén para logísticas de tipo Just In Time, o de conectar sistemas de atención a usuarios del cliente con los sistemas de ticketing del proveedor de un servicio. En cualquier caso, se trata de automatizar la relación y el intercambio de información consiguiendo inmediatez, ahorro de costes en operadores humanos y eliminación de errores.

 

Otra estrategia, o casi una buena práctica, es tener en cuenta la visión cliente, el llamado ‘customer journey‘. Esta estrategia es algo menos concreta que las anteriores pero su objetivo está muy claro: conseguir una excelente experiencia de usuario. Se trata de enfocar el diseño de los procesos de relación con el cliente siempre desde la perspectiva de éste, detectando y definiendo todos los puntos de contacto, y haciendo que la interacción sea para el cliente natural, sencilla y agradable. Puede parecer evidente, pero lo cierto es que el diseño de los procesos muchas veces se orienta desde una perspectiva interna, de la compañía y buscando únicamente la eficiencia en tiempo y costes. Aunque, evidentemente, la eficiencia de tiempo y costes siempre son un objetivo, en el caso de los procesos de relación con el cliente, la calidad de la interacción, siempre desde la perspectiva del cliente, pueden pesar tanto o más que esa eficiencia.

 

Y abundando en esa perspectiva de cliente, y con un enfoque más comercial que operativo, puede tener sentido la estrategia de efecto WOW donde la tecnología nos puede echar una mano. En este caso, de nuevo, no se busca tanto la eficiencia como el sorprender positivamente al cliente, mejorando su experiencia. Lo podemos conseguir, por ejemplo, mediante una interfaz basada en gráficos 3D, en realidad virtual o aumentada o con un chatbot de voz inteligente. A veces la búsqueda del efecto WOW puede suponer una ineficiencia desde un punto de vista meramente económico, pero una ineficiencia que se entiende se verá compensada comercialmente por la captación o retención de clientes que ese efecto WOW pueda producir. Además, hay ocasiones en que conseguimos la cuadratura del círculo aunando una experiencia excelente con una gran eficiencia. Así, aunque es cierto que un probador virtual o un chatbot de voz son desarrollos complejos y por tanto caros, lo cierto es que, una vez en operación, el ahorro en operadores humanos puede justificar perfectamente una inversión que, además, va a conseguir unos efectos excelentes en experiencia de cliente.

 

Hemos visto, pues, seis estrategias de rediseño de procesos en la dimensión de relación con el cliente. En el próximo artículo, hablaremos de estrategias para la operación interna.

 

Imagen: Brian Solís en Flickr