Tecnología para la digitalización de procesos (IV). Chatbots e interfaces conversacionales

CHatbots e interfaces conversacionales

Dentro de las posibilidades de digitalización de procesos de negocio, quizá una de las más llamativas, a veces rozando lo espectacular, son los Chatbots e interfaces conversacionales. Estamos ante un caso de automatización que no aspira a la digitalización extremo a extremo sino únicamente, y no es poco, a la interacción con las personas, normalmente con clientes.

 

Pero interactuar con las personas ya se hace con todo tipo de tecnologías ¿no? Si, así es, pero lo que cambia con este tipo de tecnologías es que la interacción adopta la forma de una conversación natural, más desestructurada y mucho más cercana a la que mantienen las personas entre sí.

 

Variedad de interfaces conversacionales

 

Este nuevo tipo de soluciones se nos pueden presentar de diferentes maneras.

 

Así, cuando hablamos de chatbots nos solemos referir a software que mantiene la conversación usando texto escrito, botones, etc y normalmente a trav´és chats o  herramientas de mensajería, de ahí su nombre.

 

Cuando además de los elementos de naturaleza textual, le añadimos la capacidad de usar y entender la voz se habla a veces de voicebots.

 

Cuando esos voicebots se dedican a prestar ayuda a las personas en multiplicidad de tareas, muchas veces relacionadas con un sistema operativo, hablamos a veces de asistentes virtuales o asistentes digitales y ahí nos encontraríamos a los Siri, Cortana, etc

 

Todos los anteriores, son meramente software empotrado en sistemas operativos, web, mensajería etc y que se apoyan en un hardware de propósito general como ordenadores o smartphones. Sin embargo, de cara a su uso fundamentalmente en el hogar, también los hay que utilizan hardware especializado, como es el caso de los Google Home, Amazon Echo o Movistar Home.

 

La forma de presentarse y los recursos que utilizan todos ellos varían entre las distintas opciones, pero todos exhiben la misma característica común:

 

son elementos tecnológicos que dialogan con humanos en forma de conversación y que sirven de intermediarios con otros recursos (programas, sistema operativo o equipos).

 

De ahí que el nombre genérico más adecuado, aunque no el más conocido, sea el de interfaz conversacional.

 

Canales de interacción

 

Como los sistemas digitales son muy variados y los escenarios para mantener una conversación también, las interfaces conversacionales pueden usar muy diferentes canales.

 

Así, los más tradicionales se apoyan en herramientas de chat o mensajería como Facebook Messenger, Slack o Skype. O también, de forma muy parecida, encontramos interfaces conversacionales en páginas web de todo tipo.

 

Pero también se pueden mover en Twitter o incluso usando los tradicionales SMS

 

En los casos como los ya mencionados y famosos Siri o Cortana su mundo es el sistema operativo (Windows o IOS) en que se incrustan.

 

Y cuando hablamos de los asistentes para el hogar u oficina del tipo como los Amazon Echo o Google Home, se mueven en un hábitat específico: el propio dispositivo hardware especializado.

 

En realidad, lo diferencial de las interfaces conversacionales es esa capacidad para el diálogo natural. El canal es, en cierto sentido, un accidente y podemos ver otros canales diferentes en el futuro.

 

Las tres partes de un bot conversacional

 

Podríamos decir que un robot conversacional se compone de tres elementos:

 

  • Las capacidades de interacción: se trata de las capacidades tanto hardware como software para realizar la interacción. Por ejemplo, si vamos a utilizar la voz como medio de comunicación, necesitamos un hardware que incluya micrófonos y altavoces. Además, necesitamos un software complejo capaz de hacer reconocimiento y síntesis de voz, procesamiento de lenguaje natural (NLP, Natural Language Processing) y entendimiento de lenguaje natural (NLU, Natural Language Undrstanding).
  • Los servicios de backoffice: es decir, aquellas capacidades finales para las cuales el bot sirve de intermediario. Por ejemplo, Cortana nos sirve de intermediario con Windows. Para ello, aparte de saber dialogar con as personas debe ser capaz de invocar funcionalidades que nos las ofrece directamente Cortana sino el propio Windows. Igualmente, si pensamos en el típico ejemplo del chatbot que proporciona información sobre el tiempo atmosférico, aparte de saber conversar con la persona, tiene que ser capaz de invocar a un servicio (que no es del propio chatbot sino externo) que proporciona la información en crudo y que luego el chatbot transmite a la persona de manera más comprensible y consistente con la conversación.
  • La conversación: es el núcleo del bot conversacional: la propia conversación, es decir, aquellos temas que el bot es capaz de entender, qué tipo de respuestas ofrece, por qué medios se relaciona con el humano en cada caso, etc. Se trata tanto del flujo de la conversación en sí como del ‘estilo’ (formal, simpático, espontáneo, bromista, etc)

 

De estas tres piezas, los servicios de backoffice en cierto modo no forman parte de la interfaz conversacional y ésta sólo debe saber que existen y ser capaz de invocarlos. Lo que es específico de una interfaz conversacional son las capacidades de interacción y la conversación propiamente dicha.

 

Explicando el ‘boom’

 

¿Por qué el éxito de las interfaces conversacionales?

 

Antes decir muy brevemente que una empresa que use interfaces conversacionales obtiene claramente un beneficio en forma de eficiencias porque el interfaz conversacional sustituye a personas y, por tanto, exhibe las t´ípicos beneficios de los robots: eliminación de trabajo no deseado para personas, disponibilidad 7×24, escalabilidad, etc

 

Además, y si el bot está bien diseñado e implementado, la experiencia de cliente / usuario puede ser muy satisfactoria, con lo que la empresa gana también en intangibles.

 

¿Y por qué ahora este ‘boom’?

 

Podríamos decir que porque se ha abaratado y democratizado mucho la tecnología que los sustenta:

 

  • Por un lado, los innegables avances de la Inteligencia Artificial, especialmente y precisamente, en materia de procesamiento de lenguaje y de voz hacen viable una conversaciones realmente naturales.
  • Además, el acceso a esta tecnología es muy barato, cuando no gratuito
  • Y, finalmente, también es muy accesible el hardware con las capacidades suficientes para soportar las conversaciones.

 

Estos tres factores han hecho que, de las tres piezas que veíamos antes, la que tiene que ver con capacidades de interacción, probablemente la más compleja tecnológicamente, se haya resuelto de una forma brillante y muy accesible.

 

Además, y en lo relativo al segundo elemento, la conversación, han surgido productos, por ejemplo Chatfuel o Dialogflow, de nuevo muy accesibles, que hacen muy, muy sencillo el diseño de conversaciones, al menos conversaciones básicas, con filosofía ‘low-code‘ y sin requerir grandes conocimientos técnicos.

 

Es decir, que las dos piezas que forman parte de la interfaz conversacional propiamente dicha, las capacidades de interacción y la conversación, están muy bien resueltas técnicamente y muy accesibles en coste y curva de aprendizaje. Si a esto unimos los beneficios que aportan los bots conversacionales, se puede entender su éxito.

 

El diseño de la conversación

 

Eso sí, resuelto el problema tecnológico de la interacción, del procesamiento del lenguaje, etc es muy importante el diseño de la conversación en sí misma. Hay que ser capaz de reconocer las intenciones (‘intents‘) del usuario, guardar información de contexto (‘context‘) y ser capaz de usarla, decidir qué elementos de interacción se van a usar (voz, texto, botones, imágenes, enlaces…). Además hay que establecer unos flujos de conversación naturales, cómodos y que estén preparados para tratar todo tipo de situaciones y contingencias.

 

Por último, y dado que el robot va a representar a nuestra marca, hay que dotarle de un cierto estilo, de una personalidad, una imagen…

 

Una vez que los productos existentes nos han resuelto los complejos problemas técnicos subyacentes a la conversación, el verdadero desafío al desarrollar una interfaz conversacional es ahora mismo el diseño de una buena conversación.

 

Conclusiones

 

Las interfaces conversacionales son soluciones que están orientadas, no a la digitalización extremo a extremo de un proceso, sino a las partes que tienen que ver con la interacción con el usuario, especialmente, la interacción con clientes.

 

Y lo diferencial es que esa interacción se produce mediante una conversación bastante natural (en algunos casos, completamente natural) usando diversos medios incluyendo la voz y el lenguaje natural.

 

Cuando están bien diseñados, las interfaces conversacionales aportan una gran experiencia de cliente a la que se unen, en visión interna, unos importantes beneficios en materia de eficiencia y escalabilidad.

 

Artículos anteriores relacionados

 

 

Imagen: Pixabay, dominio p´´ublico

 

Tecnología para la digitalización de procesos (III). Robotic Process Automation (RPA)

RPA

Probablemente si una tecnología de automatización y digitalización de procesos esté en de moda hoy en día, esa es RPA (Robotic Process Automation). Se trata de una de las áreas de mayor crecimiento en materia de software y dos de sus principales actores, UiPath (del cual, por cierto, Reingeniería Digital es partner, como contaremos en breve) y Automation Anywhere han recibido recientemente unas espectaculares rondas de financiación.

 

Se trata, sin embargo, de un tipo de soluciones afectadas por un gran bombo publicitario y no poca confusión que a veces puede hacer difícil su asimilación. Vamos a intentar entender qué es la automatización robótica de procesos y lo que puede ayudar en materia de digitalización de procesos.

 

Robots software

 

El primer punto de confusión sea, probablemente, su propio nombre. Hablamos de automatización robótica y en general, cuando se habla de robots tendemos a pensar o bien en robots androides cercanos a la ciencia ficción o bien a los típicos robots de brazo articulado en cadenas de montaje como por ejemplo de automóviles.

 

Los robots de que se habla en RPA nada tienen que ver con eso. Los robots de RPA son robots software, es decir, no son más que programas o módulos software y, por tanto, no son más tangibles que cualquier otro programa que podamos pensar.

 

Es más, aunque el campo de aplicación de RPA es muy amplio, tiende a estar más ligada a entornos de oficina que de fabricación.

 

Entender lo que es RPA

 

Ahora que ya sabemos que estamos hablando de software vamos a intentar explicar qué tipo de cosas hace ese software. Sin ánimo de dar una definición absolutamente definitiva, proponemos esta definición de RPA

 

RPA (Robotic Process Automation) es un tipo de soluciones software que permiten desarrollar y ejecutar unos módulos denominados robots que interactúan con aplicaciones, ficheros y APIs de sistemas computerizados para  realizar tareas normalmente confiadas a personas e imitando la forma en que las realiza un humano y sin requerir modificaciones en esas aplicaciones, ficheros o APIs.

 

La definición es un poco larga pero nos permite ver algunos elementos fundamentales de este tipo de soluciones, a saber:

 

  • Crean unos módulos software que denominamos robots
  • Permiten tanto el desarrollo como la ejecución de esos robots
  • Estos robots interactúan no con elementos físicos sino con sistemas informáticos.
  • Dentro de esos sistemas informáticos, la interacción se produce con aplicaciones (por ejemplo un ERP o una página web), con ficheros (por ejemplo una hoja de cálculo, un documento PDF o una base de datos) o con APIs (por ejemplo, para la gestión del correo electrónico o la transferencia/recogida de ficheros vía FTP)
  • Esos robots realizan tareas normalmente confiadas a personas. La mera mención a la palabra tarea ya nos hace pensar en su relación con los procesos de negocio, aspecto que luego veremos un poco más en detalle. Y el que sean tareas normalmente confiadas a personas sobre sistemas computerizados ya nos hace darnos cuenta de que hablamos con frecuencia de lo que en BPMN se llamaría una ‘User Task‘, es decir, tareas realizadas manualmente pero sobre sistemas informáticos: una cumplimentación de un formulario (por ejemplo con un pedido), un traspaso de información de ficheros a una aplicación (por ejemplo, introducción de datos de facturas en un ERP) etc.
  • Imitando la forma en que realizan esas tareas los humanos nos lleva a una característica muy diferencial e importante de entender de RPA. Aunque es cierto que en algunos casos los robots interactuan con APIs, la mayor parte de su trabajo es con aplicaciones y/o ficheros existentes. A la hora de interactuar con aplicaciones, por ejemplo, RPA utiliza las mismas pantallas que los humanos, con los mismos campos, los mismos botones, etc y trabaja con ellos exactamente igual que las personas. Los robots son capaces de interpretar los campos de las pantallas y de transmitir órdenes simulando el uso del ratón y el teclado. De la misma forma con ficheros. Así, por ejemplo, pueden trabajar con una hoja de cálculo y abren también el fichero, buscan celdas, cortan y pegan, introducen nuevos datos, ordenan por columnas, etc.
  • El punto anterior, interactuar igual que lo hacen los humanos tiene una consecuencia importantísima: no modifican los sistemas sobre los que actúan. No es difícil de entender. Pongamos un robot que trabaja sobre un ERP. Si el robot software utiliza las mismas pantallas, campos y datos que el humano, e interacciona con el sistema simulando movimiento de ratón, click e introducción de datos en teclado, el ERP ‘no sabe‘ si quien está interactuando con él es un humano o un robot porque la interacción es exactamente la misma. Por tanto, no es necesario modificar ni las pantallas ni la lógica del ERP.

 

¿Qué aporta RPA?

 

Además de las capacidades de las soluciones RPA que hemos visto al desmenuzar la definición, conviene decir que las herramientas de RPA del mercado ponen énfasis en hacer que el diseño y desarrollo de robots sea muy sencillo, según una filosofía de tipo ‘low code‘ lo que hace que el desarrollo sea más rápido que el de un software tradicional y requiera menos conocimientos técnicos (en el caso de robots sencillos ni siquiera son necesarias habilidades técnicas o de programación).

 

Con lo que hemos visto, sabemos que RPA es capaz de automatizar tareas (por tanto partes de un proceso de negocio) y lo hacen:

  • Sin requerir modificación de los sistemas con que interactuan
  • Con un desarrollo comparativamente rápido y sencillo

 

Más abajo veremos escenarios típicos de aplicación, pero vemos que la aportación diferencial de RPA al campo de la automatización y digitalización de procesos es:

 

RPA aporta una automatización comparativamente rápida sencilla de tareas de usuario sin requerir modificaciones en las aplicaciones, ficheros o APIs con que interactua.

 

Antes de pasar a ver sus campos de aplicación habituales, detengámonos a intentar aclarar el punto de mayor confusión: cuál es la relación de RPA con la Inteligencia Artificial.

 

RPA e Inteligencia artificial

 

La literatura comercial y poco profunda tiende a confundir RPA e Inteligencia artificial y no son lo mismo ni mucho menos. Ahora lo aclaramos un poco pero primero afirmemos con rotundidad lo siguiente:

  • RPA no es inteligencia artificial…
  • … pero RPA incluye algunas capacidades de inteligencia artificial.

 

Podríamos decir que en relación con las tareas que automatiza RPA hay dos puntos donde el humano aporta capacidades cognitivas diferenciales:

  • Sentidos: es decir, en la interacción con el exterior fundamentalmente mediante la vista para entender pantallas, documentos, imágenes, etc
  • Análisis y decisión: A la hora de decidir qué hacer

 

Aunque las fantasías alrededor de RPA e inteligencia artificial llevan erróneamente a pensar en una inteligencia completa, capaz de razonar, crear y decidir (es decir, actuando sobre todo en análisis y decisión), lo cierto es que las técnicas de inteligencia artificial que se usan en RPA hoy en día van más en la línea de los ‘sentidos’.

 

Veamos un poco cómo funcionan ambas variantes.

 

Cuando RPA trata con pantallas y documentos, puede suceder que estos se encuentre muy claramente estructurados, con los datos perfectamente definidos, etiquetados y en los mismos puntos de la pantalla o el documento. En esos casos, RPA es capaz de extraer o introducir información mediante tecnología software digamos ‘estándar’. Sin embargo, cuando los datos son desestructurados (por ejemplo, correros electrónicos o ficheros PDF en texto libre o cuando las pantallas vienen en forma de imágenes como sucede en aplicaciones virtualizadas) normalmente RPA necesita aplicar técnicas de inteligencia artificial del campo de reconocimiento de imágenes, procesamiento de lenguaje natural (NLP, Natural Language Processing), entendimiento del lenguaje natural (NLU, Natural Language Understanding) u OCR (Optical Character Recognition) avanzado. Ahí es fundamentalmente donde hoy día aplican inteligencia artificial las soluciones existentes.

 

En la toma de decisiones, éstas pueden estar regidas por unas reglas de negocio sencillas y claramente procedimentadas o bien requerir juicio humano. En el caso de la existencia de reglas de negocio claro, no se precisa de inteligencia artificial y un software ‘normal’ lo puede hacer perfectamente. En el caso de decisiones complejas y sin reglas claras, puede tener sentido la aplicación de Machine Learning e Inteligencia Artificial. Sin embargo, conviene evitar fantasías y tener claro que las soluciones actuales de RPA están orientadas a la decisión basada en reglas de negocio sencillas, es decir, a que el análisis y decisión se realice con algoritmos sencillos tradicionales. Cierto es que ya existen algunas posibilidades de enganchar módulos más avanzados, por ejemplo en Python, y que se trabaja mucho en la dirección de incluir nuevas capacidades cognitivas. Pero, por ser prácticos, a día de hoy hay que pensar que las capacidades de análisis y decisión de las soluciones RPA son básicas y no incluyen inteligencia artificial.

 

¿Cuándo usar RPA?

 

Con todo lo visto, ya nos hacemos una idea de e qué tipo de tareas se aplica RPA. Como regla básica podemos decir que:

 

RPA se aplica a la automatización de tareas repetitivas, masivas y basadas en reglas realizadas actualmente por humanos interactuando con aplicaciones y ficheros.

 

  • Se aplica a tareas repetitivas y basadas en reglas porque es viable de una forma sencilla automatizar su lógica (a la espera de un desembarco de mayores capacidades de inteligencia artificial)
  • Se aplica a tareas masivas por un razonamiento económico: porque si son tareas masivas se recogen mayores frutos con la automatización en forma de liberación de recursos humanos, eliminación de errores, etc
  • Y se aplica a tareas basadas en la interacción con aplicaciones y ficheros porque esa es la naturaleza misma de lo que hace RPA y uno de sus mayores beneficios diferenciales frente a otras formas de digitalización de procesos: no precisa modificar las aplicaciones y ficheros existentes.

 

Algunas de las tareas normalmente confiadas a RPA pueden ser: carga de datos en aplicaciones a partir de datos de ficheros (por ejemplo, carga de información de facturas en un ERP), paso de datos entre sistemas (por ejemplo, paso de los pedidos del CRM al ERP), traspaso de datos entre ficheros (por ejemplo, en una migración entre sistemas o en cargas masivas periódicas entre sistemas), repetición indefinida de tareas concretas sobre aplicaciones (por ejemplo, en pruebas de regresión de software), procesamiento de correos (tratamiento automatizado de la entrada o envíos automatizados), etc

 

Adem´ás de tareas puntuales, las soluciones de RPA permiten construir flujos de proceso que enlazan diversas actividades y permiten elementos como las condiciones, los bucles o el tratamiento de errores. En ese sentido, en teoría RPA puede automatizar un proceso extremo a extremo de forma similar a un BPMS pero, en la práctica, las capacidades de RPA son algo más limitadas y están orientadas o bien a la automatización de procesos muy sencillos o bien a colaborar en la automatización de procesos mayores cuyo núcleo reside en otro sistema o sistemas.

 

Sin embargo, hay un punto que no suele tratar la literatura sobre RPA y que en una perspectiva amplia de digitalización de procesos hay que tener claro: ¿por qué automatizar usando RPA en lugar de hacerlo, por ejemplo, evolucionando un sistema de gestión empresarial o un BPMS?

 

Para contestar esa pregunta hay que tener claro lo que decíamos más arriba que es diferencial de RPA, a saber que es rápido (vamos a añadir que comparativamente barato) y no afecta a los sistemas actuales. Si la automatización que queremos hacer es muy importante para la empresa, tiene mucho retorno y se va a mantener en el tiempo probablemente debamos pensar en una automatización vía sistema empresarial o BPMS. Sin embargo, escenarios típicos de aplicación de RPA son:

 

  • Se trata de automatizaciones de tareas en que no podemos o no queremos tocar los sistemas responsables de los procesos en que se enmarcan. Motivos por los que podemos no querer/poder tocar los sistemas responsables pueden ser, por ejemplo:
    • No tenemos poder de negociación suficiente como para cambiar ese software. Por ejemplo, hablamos de una suite ofimática o un SaaS cuyo software es utilizado en el mundo por miles o millones de clientes y por tanto no es su funcionalidad la que se adapta a nuestras necesidades sino nosotros al software. O bien somos una PYME y no podemos aspirar a disponer de una versión personalizada de un ERP.
    • De naturaleza presupuestaria (no disponemos de fondos suficientes)
    • Por obsolescencia del sistema (queremos automatizar sobre un sistema que se supone va a ser sustituido en el plazo de unos meses o como mucho un año o dos)
    • Por falta de capacidades tecnológicas o de desarrollo en el momento actual
  • Queremos automatizar en corto plazo ciertas tareas masivas y poco eficientes mientras nos damos tiempo a modificar el sistema empresarial/BPMs. Para que esto tenga sentido, el retorno de la inversión de usar RPA mientras se modifican los sistemas subyacentes tiene que ser claro.

 

No hay reglas fijas pero lo indicado arriba nos puede dar una idea clara de cuándo tiene sentido aplicar RPA.

 

Conclusión

 

En resumen, RPA son un tipo de soluciones que nos permiten automatizar tareas repetitivas, masivas y basadas en reglas actuando sobre unos sistemas, ficheros y APIs existentes sin modificarlos. RPA aplica técnicas algorítmicas clásicas para el tratamiento de pantallas y datos estructurados y recurre a la inteligencia artificial para el procesamiento del lenguaje natural y el tratamiento de ciertos datos no estructurados y, de momento, aplica lógica basada en reglas sencillas para el análisis y la decisión.

 

Las grandes ventajas diferenciales de RPA se basan en la sencillez y rapidez de desarrollo y en no afectar a los sistemas y ficheros sobre los que actúan.

 

Teniendo todo eso en cuenta, se debe decidir en cada situación concreta si queremos automatizar mediante RPA, mediante sistema empresarial, mediante BPMS o mediante algún tipo de combinación entre esas tres opciones.

 

Artículos anteriores relacionados

 

 

Imagen: Pixabay, dominio p´´ublico

 

Tecnología para la digitalización de procesos (II). Sistemas de Gestión de Procesos de Negocio (BPMS)

BPMS

Si hay una tecnología, o quizá mejor dicho, un uso de la tecnología más propio de los procesos de negocio, ese es el de los BPMS acrónimo que en ocasiones podemos encontrar como Business Process Management System y en otras como Business Process Management Suite.

 

Se trata de unos productos ya con historia, que se iniciaron como sistemas de gestión de workflow.

 

Los sistemas de Workflow

 

Originalmente los BPMS ni siquiera adoptaron ese nombre sino que se empezó con los denominados WfMS (Workflow Management System).

 

El elemento diferencial de los BPMS o WfMS es que el proceso se convierte en una entidad clave que se gestiona explícitamente. Es decir, si hasta entonces en diversas soluciones a medida o en los productos de software empresarial, el proceso estaba embebido en la lógica, pero no de trataba de forma independiente, ahora con los WfMS el proceso se diseña, modela y ejecuta sobre la propia herramienta.

 

Quizá se entienda algo más la idea contemplando el modelo de referencia que propuso, ya en 1995 la Workflow Management Coalition.

 

Workflow Reference Model
Workflow Reference Model

 

Se puede observar en la figura que las soluciones de workflow incorporaban, en primer lugar, un módulo de definición del proceso, una herramienta de naturaleza gráfica e interfaz intuitivo donde se establecían las diferentes actividades del proceso, los flujos, las condiciones y las variables de proceso. En algunos casos esa herramienta de edición también permitía la definición gráfica de los formularios o pantallas para las tareas de usuario. Una herramienta que volcaba la definición del proceso inicialmente a una base de datos en un formato propietario de cada herramienta pero que en seguida pasaron a ser capaces de almacenarlo en formatos estandarizados normalmente basados en XML como BPEL (Business Process Execution Language).

 

El segundo elemento es el motor de ejecución, es decir, la pieza que toma la definición hecha con el módulo anterior y lanza las instancias de los procesos para su ejecución real.

 

Normalmente, los sistemas de workflow no implementaban el detalle de cada tarea sino que actuaban más bien como coordinadores u orquestadores de otros sistemas,  `por lo que en el modelo de referencia se incluyen las aplicaciones cliente y las aplicaciones invocadas.

 

Finalmente, y como es de esperar, se añaden herramientas adicionales de monitorización de los procesos o de administración de aspectos como los roles y los usuarios.

 

Los BPMS y sus diversos nombres

 

Poco a poco, la denominación de sistemas de workflow ha ido desapareciendo y en su lugar se suele hablar de BPMS (Business Process Management System o Business Process Management Suites). Las ideas y funcionalidades son similares aunque cuando surgieron los sistemas de workflow eran unas soluciones más de nicho o para procesos más concretos mientras que con los BPMS se incrementa la ambición hacia una gestión corporativa completa de los procesos.

 

Han tendido por ello, y por la propia evolución de la tecnología y el mercado, a hacerse productos más complejos. Realmente, muchas veces son una familia de productos e incluyen elementos de gestión SOA como un Enterprise Service Bus. De ahí que la última ‘S’ suela tratarse con el significado de ‘suite‘ en lugar de ‘system‘.

 

También consultoras como Gartner los han denominado iBPMS donde la ‘i’ significa ‘intelligent‘ y que justifican con la introducción de funcionalidades avanzadas como analítica en tiempo real, tratamiento de eventos complejos (CEP, Complex Event Processing) o la monitorización en tiempo real BAM Business Activity Monitoring.

 

Por su lado Forrester, por ejemplo, nos habla últimamente de DPA (Digital Process Automation) justificando el cambio de nomenclatura en aspectos como la importancia del low-code o de facilidades basadas en inteligencia artificial.

 

La filosofía fundamental, sin embargo, sigue siendo la misma y la ya heredada de los sistemas de workflow.

 

Conclusión

 

Aunque con las lógicas evoluciones y los algo confusos cambios de denominación, BPMS es la tecnología por excelencia para la gestión corporativa de procesos. Aunque, más que de una tecnología propiamente dicha, quizá debamos hablar de una filosofía de productos de automatización de procesos de negocio, donde se gestiona explícitamente el proceso con sus actividades, sus flujos y sus roles tanto n lo relativo a su diseño, como su ejecución, monitorización y analítica.

 

Existen tecnologías adicionales, algunas muy modernas e impactantes, que veremos en próximos artículos pero, en general, serán tecnologías que complementarán a la columna vertebral de la digitalizaci´´on de procesos que se basa en los BPMS (con el nombre que sea) interactuando con sistemas de gestión empresarial, y bien apoyados por la filosofía y productos SOA.

 

Artículos anteriores relacionados

 

 

Imagen: Pixabay – Dominio público

 

 

Tecnología para digitalización de procesos (I). ERP, CRM y software empresarial

software empresarial

Nuestra firma, Reingeniería Digital, busca trabajar en esa zona intermedia en que se une la visión del negocio con las posibilidades que aporta la tecnolog´ía digital. En los artículos que en este blog hemos publicado en las últimas semanas (y meses), hemos adoptado una visión predominantemente de negocio, abordando en dos series consecutivas, las estrategias de mejora de procesos y los modelos de referencia.

 

Con este artículo iniciamos ahora una nueva serie en que vamos a ir examinando someramente diversas tecnologías, algunas ya tradicionales, y otras emergentes, que sirven para digitalizar, automatizar y, en general, mejorar los procesos de negocio.

 

El pasado ‘lejano’

 

Aunque en el mundo inicial de los mainframe o de desarrollos a medida locales, podemos dar por seguro que se realizó una cierta labor de digitalización de procesos, lo cierto es que inicialmente no se tenía esa visión transversal de la actividad que los procesos suponen ni tampoco la necesaria extensión de los sistemas de información como para cubrir grandes porciones de la actividad empresarial, Podemos entender, entonces, que más que procesos, lo que se digitalizaba eran tareas o actividades concretas.

 

La llegada del software empresarial: los ERP

 

El panorama cambió de forma importante con la llegada de los productos de software empresarial. Se trataba de grandes productos software que, aunque parametrizables, traían de serie incorporadas grandes dosis de funcionalidad de gestión de la empresa.

 

Con ello, no sólo recogían los principales datos a manejar en cualquier empresa sino que, además, y más importante para nosotros, venían con unos procesos de negocio ya incorporados. Estos procesos de negocio, se suponía, recogían las mejores prácticas del mercado o sector y, por tanto ahorraban a la empresa su revisión y le proporcionaban ‘sin esfuerzo’ los mejores procesos que pudiera desear.

 

Este tipo de productos se inició por los ámbitos empresariales más de back-office incluyendo la gestión contable y financiera, la gestión de recursos humanos y la producción. De ahí su nombre, ERP, Enterprise Respource Planning, siendo el producto más paradigmático el famoso SAP, pero también existían otros como Oracle Applications y los desaparecidos o absorbidos PeopleSoft o J.D Edwards. Existían versiones transversales y también los denominados ‘verticales’ por sector.

 

La extensión hacia los procesos de relación con cliente: el CRM

 

Con exactamente la misma filosofía que los ERP surgieron los CRM (Customer Relationship Management) cuya mayor diferencia era que se centraban en los procesos de relación con el cliente incluyendo la gestión de ventas, la automatización del marketing y la posventa.

 

Dado que se centraban en la relación con el cliente también solían incluir destacadas capacidades multicanal pero con especial foco en canal telefónico, incorporando tecnología ACD (Automatic Call Distribution) o IVR (Interactive Voice Response).

 

El representante más cualificado fue Siebel (posteriormente comprado por Oracle), aunque un movimiento lógico fue la extensión hacia el campo de CRM de productos ERP como SAP (iniciado con su mySAP), Oracle o Peoplesoft.

 

Luces y sombras

 

El éxito e impacto de este software empresarial: ERP y CRM ha sido y es innegable y supusieron un gran impulso a la digitalización (que entonces no se llamaba así) de muchas empresas, a la automatización de procesos (tampoco se solía llamar así) y a la disponibilidad de abundantes datos explotables mediante Business Intelligence.

 

Pero también han adolecido de ciertas problemáticas. Por una parte, las tarifas que aplicaban las consultoras que realizaban las parametrizaciones e implantaciones han sido tradicionalmente muy elevadas, a lo que pudimos un coste de licencia tampoco ‘frugal’. Se trata, por tanto, de soluciones, en general, caras.

 

Los productos de software empresarial están pensados para usarlos ‘como son’ por lo que las personalizaciones son costosas y, al apartarse del estándar ponen en peligro la evolución futura de las implantaciones personalizadas de las empresa.

 

Desde un punto de vista algo más estratégico y relacionado con los procesos, decir que, al adoptar unos procesos de negocio que aportaba la herramienta, la capacidad de diferenciación estratégica en esos procesos era mínima.

 

Además, los procesos, aunque formaban parte de la solución, solían ser más bien subproductos, sin una gestión directa.

 

Finalmente, se generaba unas altas y complejas necesidades de integración con otros sistemas que forzosamente necesitaban interaccionar con los ERP y CRM, convertidos en la columna vertebral de los sistemas de la empresa.

 

Siguientes tendencias

 

Aunque los sistemas de software empresarial están todavía muy presentes (y es previsible que se mantenga ese estado de cosas durante mucho tiempo), dos nuevas corrientes surgieron para superar algunas de sus problemáticas: las arquitecturas SOA (Service Oriented Architecture) y EAI (Enterprise Application Integration) para solventar la problemática de integración y los workflow y posteriormente los BPMS (Business Process Management Suites) para convertir a los procesos de negocio en ‘ciudadanos de primera’ en la gestión digital.

 

Pero de SOA y de los BPMS nos ocuparemos en futuros artículos.

 

Imagen: pixabay

 

 

Modelos de referencia de procesos (V). El modelo VCOR centrado en cadenas de valor

Cadena de valor y modelo VCOR

Terminamos esta serie de artículos dedicados a frameworks y modelos de referencia de procesos, comentando brevemente el modelo VCOR. Vamos a referirnos a él sobre todo por completitud porque, realmente, es difícil hoy en día obtener información del mismo y, por tanto, no sería práctico posiblemente usarlo como tal modelo de referencia.

 

VCOR (Value Chain Operation Reference model) es un modelo que fue desarrollado por Value Chain Group, entonces una organización sin ánimo de lucro, en 2007. El objetivo era planificar, gobernar y ejecutar cadenas de valor en busca de la eficacia y la eficiencia de los negocios.

 

modelo VCOR nivelesSe trata de un modelo jerárquico que establece tres niveles:

  • Nivel estratégico: se concentra en los procesos de alto nivel necesarios para conseguir una ventaja competitiva.
  • Nivel táctico: en el cual se implementa un plan estratégico y refleja decisiones tácticas.
  • Nivel operacional: representa ya procesos específicos. Es en este nivel en que se concentrarían unas eventuales iniciativas de mejora continua o reingeniería.

 

A nivel conceptual se reconocen otros dos niveles, el de actividades y acciones pero el modelo no entra en ellos ya que se considera, de forma parecida a lo que hacía SCOR, decisión individual de cada empresa.

 

En el nivel estratégico nos encontramos con tres categorías de procesos:

  • Plan: Alinea los objetivos estratégicos con las capacidades de ejecución y tácticas. Incluye la recogida de requisitos, la evaluación y alineamiento de recursos y la comunicación del plan resultante.
  • Govern: proporciona soporte a la operación de la cadena de valor mediante reglas, políticas y procedimientos. Trata de aspectos como las finanzas, personal, ciclos de vida, cumplimiento normativo, activos, información, red, etc
  • Execute: recoge la ejecución u operación efectiva de la cadena de valor.

 

En el nivel táctico, se produce una descomposición, en las tres categorías estratégicas, en 8 procesos (Market, Research, Develop, Acquire, Build, Fulfil, Sell, Support, Market) siendo su significado el siguiente:

 

  • Market: alineamiento de las necesidades de la cadena de valor con el desarrollo de producto, capacidades de la red de suministro y relaciones con otros proveedores.
  • Research: preparativos necesarios para el desarrollo de producto.
  • Develop: La definición y creación de los productos y servicios para su fabricación (productos) o prestación (servicios).
  • Acquire: Adquisición de bienes y servicios de proveedores que permiten la realización de las actividades de la cadena de valor.
  • Build: Transformación de materiales de acuerdo con los requisitos de la cadena de valor.
  • Fulfil: Preparativos para las entregas y demás actividades que satisfacen las demandas de cliente.
  • Sell: actividades relativa a la venta.
  • Support: actividades de posventa realizadas en relación con el cliente.

 

modelo VCOR descomposición

 

Estos ocho procesos forman parte del nivel táctico tanto para ‘Plan‘, como ‘Govern‘ y ‘Execute‘,  si bien en el caso de las categorías de ‘Plan‘ y ‘Govern‘, se incluye el prefijo de la categoría, mientras que en el caso de ‘Execute‘ se indica directamente con el nombre. Según lo anterior, la descomposición de los niveles estratégico y táctico sería la siguiente:

 

  • Plan
    • Plan, Market
    • Plan, Research
    • Plan, Develop
    • Plan, Acquire
    • Plan, Build
    • Plan, Fulfil
    • Plan, Sell
    • Plan, Support
  • Govern
    • Govern, Market
    • Govern, Research
    • Govern, Develop
    • Govern, Acquire
    • Govern, Build
    • Govern, Fulfil
    • Govern, Sell
    • Govern, Support
  • Execute
    • Market
    • Research
    • Develop
    • Acquire
    • Build
    • Fulfil
    • Sell
    • Support

 

En el nivel táctico se llega hasta una descomposición que, en total, abarca 191 procesos. A modo de ejemplo, en el caso del proceso táctico ‘Acquire‘ tendríamos la siguiente descomposición operacional:

 

  • Execute
    • Acquire
      • Issue Request
      • Evaluate Proposal
      • Negotiate Contract
      • Place Order
      • Receive Order
      • Verify Order
      • Transfer Inventory
      • Authorize Payment

 

En VCOR, además de la jerarquía, por cada proceso se recoge información adicional como unas definiciones de proceso que proporcionan una nomenclatura y semántica comunes, entradas y salidas del proceso, indicadores de desempeño y buenas prácticas. Hay un extenso conjunto de métricas que se agrupan según siete dimensiones de priorización:

 

  • Fiabilidad / entrega
  • Velocidad / Capacidad de respuesta
  • Flexibilidad / adaptabilidad
  • Efectividad / gestión de activos
  • Costes
  • Innovación
  • Cliente (relación)

 

Se trata VCOR de un modelo de referencia que parece hundir sus orígenes en la fabricación y con cierto foco en la cadena de suministro, aunque extiende conceptos hacia los servicios. Además, guarda bastante similitudes con el modelo SCOR que ya revisamos en un artículo anterior. Es un modelo, que aparenta estar bastante en desuso y sobre el que no es fácil, siquiera, obtener información por lo que, independientemente de sus méritos, no sería una buena opción de partida siendo preferible, quizá, si nos interesa esa visión de fabricación y cadena de suministro, optar por SCOR o, incluso, alguna variante de APFC.

 

Artículos anteriores relacionados:

 

 

Imagen de cabecera: Max Pixel

Modelos de referencia de procesos (IV). El modelo SCOR para la cadena de suministro

SCOR cadena de suministro

Damos hoy otro paso en la revisión de modelos de referencia de procesos. En concreto, en este artículo, vamos a comentar brevemente el caso de SCOR (Supply-chain Operations Reference Model), referente en el área funcional de la cadena de suministro.

 

Se trata de un modelo desarrollado originalmente por la organización denominada SCC (‘Supply Chain Council‘) fundada por un conjunto de consultoras con sede en Boston. Actualmente, la organización que gestiona este Framework es APICS.

 

Este modelo nació en 1996 y su versión actual es la 12.0 lanzada en 2017. SCOR es algo más que un modelo de referencia de procesos ya que en realidad consta de cuatro secciones:

 

  • Performance (desempeño): métricas para caracterizar el desempeño de los procesos y establecer metas estratégicas.
  • Processes (procesos): Descripciones estándar de los procesos de gestión y relaciones entre ellos.
  • Practices (prácticas): prácticas de gestión que conducen a resultados significativamente mejores
  • People (personas): definiciones estándar de las habilidades necesarias para ejecutar procesos de cadena de suministro.

 

SCOR asume una división jerárquica de los procesos en cuatro niveles:

 

  • Nivel 1 – Tipos de proceso (alcance ‘scope‘): define el alcance y contenido de una cadena de suministro.
  • Nivel 2 – Categorías de proceso (configuración, ‘configuration‘): define la estrategia de operaciones de esa cadena de suministro.
  • Nivel 3 – Elementos de proceso (pasos, ‘steps‘): define la configuración individualizada de los procesos incluyendo elementos como entradas y salidas, prácticas, habilidades, capacidades técnicas, etc.
  • Nivel 4 – Actividades (implementación, ‘implementation‘): describe las prácticas concretas de cada empresa que pueden ser propias de la empresa, sector o localización.

 

El alcance de SCOR llega únicamente a los tres niveles superiores que considera neutrales y deja fuera de su objetivo y bajo la responsabilidad y estrategia de las empresas y sectores, la definición del último nivel.

 

SCOR Categories Processes

 

Para SCOR, un proceso es “una actividad única realizada para conseguir unos resultados predefinidos” El modelo gira en torno a seis grandes áreas de procesos o, si se prefiere, tipos de proceso o procesos mayores (Nivel 1), a saber:

 

  • Plan: actividades relacionadas con la planificación de la operación de la cadena de suministro, incluyendo la toma de información, requisitos y recursos disponibles, la identificación de gaps en la demanda de recursos y determinación de acciones para corregir esos gaps.
  • Source: se ocupa de la emisión de órdenes o planificación de entregas y la recepción de bienes y servicios. Incluye, además de la emisión de órdenes o planificación de entregas, aspectos como la recepción, validación, almacenamiento de los bienes y la aceptación de la factura del proveedor.
  • Make: actividades de transformación de materiales o creación de servicios. Es una forma ampliada de hablar de lo que normalmente denominaríamos producción o fabricación. Incluye el ensamblaje, procesado químico, mantenimiento, reparación,  revisión, ajuste, puesta a nuevo (‘refurbish‘), etc
  • Deliver: Actividades asociadas con creación, mantenimiento y ejecución de órdenes para clientes. Incluye la recepción y validación de pedidos de clientes, la planificación de la entrega, el ‘picking-pack‘, el envío y la facturación a cliente.
  • Return: actividades asociadas con el flujo inverso o logística inversa, es decir, la retirada de bienes. Incluye la identificación de la necesidad de ese retorno, la planificación y el envío y recepción de esos bienes.
  • Enable: un proceso que no estaba en algunas versiones anteriores de SCOR y que incluye actividades de gestión de la cadena de suministro como la gestión de reglas de negocio, gestión de datos, infraestructuras, contratos, recursos, etc

 

En SCOR los procesos se identifican mediante una combinación de letras (Nivel 1) y números separados por puntos (Niveles 2 y 3). Para intentar visualizar un poco más como es SCOR, cómo es la estructura y cómo se usan los identificadores, veamos un ejemplo desarrollando de forma muy parcial la jerarquía hasta alcanzar el paso consistente en la recepción de los productos. Desplegando los niveles 1, 2 y 3, quedaría de la siguiente forma:

 

  • sS: Source
    • sS1: Source Stocked Product
    • sS2: Source Make-to-Order Product
      • sS2.1: Schedule Product Deliveries
      • sS2.2: Receive Product
      • sS2.3: Verify Product
      • sS2.4: Transfer Product
      • sS2.5: Authorize Supplier Payment
    • sS3: Source Engineer-to-Order Product

 

Es decir, el Nivel 1 es ‘sS – Source‘, en Nivel 2 ‘sS2 – Source Make-to-Order Product‘ y el Nivel 3 ‘sS2.2 – Receive Product

 

Llegados ya a un nivel concreto, en este caso el Nivel 3: sS2.2 Receive Product, la descripción en SCOR incluye:

 

  • Una breve descripción textual: en este caso nos dice simplemente que son las actividades consistentes en recibir productos para satisfacer unos requisitos.
  • La identificación de métricas. En este caso, por ejemplo, una m´étrica que se identifica es el porcentaje de órdenes/líneas de pedido recibidas con un empaquetamiento correcto.
  • Una identificaci´ón de p´racticas. En este caso, por ejemplo, se incluye una práctica para la inspección de bienes recibidos.
  • Una identificación de habilidades. En este caso, por ejemplo, se incluye el manejo de códigos de barras o etiquetas RFID.
  • Un workflow: en que se muestra el proceso en contexto con otros procesos y los intercambios. En este caso concreto, el workflow es el que se muestra en la figura:

 

SCOR Receive Product

 

En él se observa en el centro al proceso que estamos viendo, sS2.2 – Receive Product, cómo envía la verificación de la recepción al proceso sS2.3 – Verify Product y cómo tiene como entradas las siguientes:

 

  • Productos defectuosos desde sDR1.4 – Transfer Defective Product
  • Productos en exceso desde sDR3.3 – Receive Express Product
  • Productos MRO (‘Maintenance, Repair and Operations‘) desde sDR2.4 – Transfer MRO Product
  • Productos desde sD1.13, sD2.13 y sD3.13, es decir, el paso (Nivel 3)  Receive and Verify Product by Customer para cada una de estas tres categorías (Nivel 2) sD1 – Deliver Stocked Product, sD2 – Deliver Make-to-Order Product y sD3 – Deliver Engineer-to-Order Product.

 

Como se puede ver, SCOR es un modelo de referencia de procesos muy especializado en la cadena de suministro, algo parco en sus descripciones pero que identifica muy bien la estructura y jerarquía de procesos, cómo se relacionan y las m´étricas, prácticas y capacidades asociadas.

 

Artículos anteriores relacionados:

 

 

Imagen de portada: Pixabay

 

Modelos de referencia de procesos (III). ITIL para servicios TI

ITIL - IT Service Management

ITIL es quizá el modelo de referencia de procesos más ampliamente conocido. Y eso a pesar de que no procede del campo del BPM (Business Process Management) sino de la gestión de la función TI (Tecnologías de la Información). Y eso a pesar también de que su alcance es muy acotado (prestación de servicio de TI) y que no pretende ni siquiera ser realmente normativo sino, simplemente, expresar unas buenas  prácticas.

 

ITIL (Information Technology Infrastructure Library) es un conjunto compacto de procesos y buenas prácticas para la gestión de servicios de TI, aplicable tanto para proveedores de servicios a clientes externos como, por ejemplo, los que prestan servicios cloud de alojamiento, como para departamentos internos de sistemas dentro de empresas y que prestan a sus usuarios y clientes internos servicios de desarrollo, implantación y operación de aplicaciones, gestión del parque microinformático, etc.

 

ITIL nació en el seno de la administración británica, en concreto en la CCTA (Central Computer and Telecommunications Agency) integrada posteriormente en la  OGC (Office of Government Commerce), organismo que, a su vez, se integró más tarde en el ‘Cabinet Office‘.

 

Apareció en los años ochenta, aunque alcanzó amplia difusión en los noventa. ITIL ha ido evolucionando, siendo sus versiones principales la versión 2 (desarrollada y publicada entre 2000 y 2004), la versión 3 posteriormente rebautizada como ITIL 2007 y la actual ITIL 2011. El organismo que actualmente gestiona ITIL, AXELOS (fruto de la unión entre Capita y el Cabinet Office) ha anunciado una nueva versión para 2019 que se llamará ITIL 4.

 

ITIL v3

 

La documentación de ITIL se agrupa en lo que se denominan ‘libros’. En su versión actual existen cinco libros con las áreas de proceso principales de la gestión de TI. Tres de ellos se centran en lo que podríamos considerar el ciclo de vida de los servicios:

 

  • Service Design: orientado a la definición del servicio e incluyendo procesos relacionados con gestión de catálogo, proveedores, disponibilidad y acuerdos de nivel de servicio.
  • Service Transition: que se centra en el despliegue y puesta en marcha del servicio y para ello recoge los procesos que tienen que ver con pruebas, configuración, despliegue, gestión del cambio y gestión del conocimiento.
  • Service Operation: quizá el libro más extendido, que trata ya de la operación de un servicio en producción y para ello se concentra en la gestión de eventos, incidentes y problemas.

 

Los otros dos libros tratan de temáticas más transversales:

 

  • Service Strategy: estrategia del servicio que contempla por ejemplo los estudios de mercado y la identificación de los servicios más innovadores.
  • Continual Process Improvement: que habla, de la mejora continua e incluye un proceso para la medición de las prestaciones del servicio y realización de informes.

 

ITIL son, como hemos dicho, unas buenas prácticas, no una norma o un estándar. Sin embargo, muy inspirada en, y muy cercana a ITIL, aunque sin ser exactamente igual, existe la norma ISO 20000.

 

El cumplimiento de ISO 20000 es con frecuencia exigido por la administraciones públicas y grandes empresas en la contratación de servicios TI.  Además, existen herramientas informáticas de uso bastante extendido que implementan ya los procesos ITIL. Por eso es muy importante conocer tanto ITIL como la norma ISO 2000. Y es importante también el  considerar la certificación lo que implica, elementos administrativos aparte, el implantar realmente unos procesos que sigan las directrices de la norma e, indirectamente, ITIL.

 

Esto en cierto modo clarifica lo que una organización puede o debe hacer en cuanto a procesos de gestión de servicios TI pero, al tiempo, puede ser una cierta pérdida de libertad a la hora del diseño de los procesos y una dificultad para encajar los procesos de gestión de TI en un marco de gestión de procesos más amplio en que, quizá, la filosofía o modelo de referencia pueda ser otro.

 

Cualquier decisión no puede, en cualquier caso, ignorar la importancia e implicaciones de ITIL e ISO 20000.

 

Artículos anteriores relacionados:

 

 

Modelos de referencia de procesos (II). El modelo eTOM para telecomunicaciones

eTOM para telecomunicaciones

En el artículo anterior empezamos a hablar de modelos de referencia de procesos y vimos el PCF (Process Cassification Framework) de la APQC que se caracteriza por ser transversal, es decir, valer para todo tipo de sectores. Pero no siempre es así. Con frecuencia los modelos de referencia de procesos se centran en un sector u área funcional concreta. Y eso es lo que ocurre con eTOM, el modelo de referencia que ocupa el artículo de hoy.

 

eTOM (enhanced Telecom Operations Map) surgió hace ya bastante años en el seno de lo que entonces se denominaba Network Management Forum una entidad que agrupaba a operadores y fabricantes del mundo de las telecomunicaciones. En una época en que apenas había competencia, no fue en exceso difícil que las empresas colaborasen para conseguir un mapa de procesos común que inicialmente se centraba en los procesos más operativos, los que podríamos denominar primarios. De hecho, al principio su nombre fue, simplemente TOM (Telecom Operations Map) que, como el nombre expresa claramente, se centraba en los procesos más operativos (Fulfillment, Assurance y Billing, es decir, venta y provisión, mantenimiento y posventa y tarificación/facturación). Posteriormente, fue ampliándose cubriendo los procesos más estratégicos y de soporte para conseguir tener un mapa completo de procesos.

 

Además, también ha intentado ampliar su alcance sectorial incluyendo también sectores adyacentes como Media, aunque sigue manteniendo un inconfundible sabor a telecomunicaciones.

eTOM

eTOM, es un modelo de procesos de carácter jerárquico, llegando en su descomposición hasta 6 niveles aunque hoy en día no están todos perfectamente detasarrollados. En la figura se puede observar el mapa en su nivel 0. Un aspecto algo particular de eTOM es que subdivide los procesos en unas cuadrículas muy claras, siendo especialmente relevante la dimensión horizontal que marca los procesos dedicados, respectivamente, a: cliente/producto, servicio, recurso y proveedor, respectivamente. En vertical hay siete columnas que podríamos entender como grandes cadenas de proceso extremo a extremo.

 

Además, hay tres grandes áreas de proceso:

  • Operaciones (entendiendo por operación, no sólo la operación técnica sino también  el día a día comercial y de posventa)
  • Estrategia, infraestructura y producto
  • Gestión empresarial

Siendo ésta una subdivisión que recuerda a la ya hecha por Porter en su cadena de valor con los procesos primarios (que se corresponderían con la operación) frente a los estratégicos y los de soporte.

 

Cadena de valor

 

Otro aspecto muy relevante de eTOM es que, aunque surgió de forma aislada, el organismo que lo gestiona, que pas´ó luego a llamarse TeleManagement Forum  y más tarde, simplemente, tmForum, ha desarrollado dos elementos complementarios, pero perfectamente encajados con eTOM y entre si:

 

  • SID, Shared Information Data model: que es un modelo de información completo
  • TAM, Telecom Applications Map: que es un mapa de aplicaciones

 

Como decíamos, los tres elementos, el mapa de procesos eTOM, el mapa de Información SID y el mapa de aplicaciones TAM están perfectamente incardinados y conforman un Framework completo, de nombre Frameworx,  que los lectores de este blog ya reconocerán se convierte realmente en toda una arquitectura empresarial para un operador de telecomunicaciones.

 

De hecho, existen muchos productos software que siguen esta arquitectura y sin duda hay operadores de telecomunicaciones que utilizan la guía de eTOM y, en general, todo Frameworx, para estructurar sus procesos y sistemas.

 

Imagen de portada Pixnio

Otras imágenes: Wikimedia

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.