PROCESOS DE NEGOCIO archivos - Reingeniería Digital

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

Publicada en 18 octubre, 201818 octubre, 2018 por Ignacio G.R. Gavilán

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.

Se 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.

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

Publicada en 11 octubre, 201811 octubre, 2018 por Ignacio G.R. Gavilán

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.

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:

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

Publicada en 4 octubre, 20184 octubre, 2018 por Ignacio G.R. Gavilán

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.

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

Publicada en 27 septiembre, 201826 septiembre, 2018 por Ignacio G.R. Gavilán

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, 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.

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)

Publicada en 20 septiembre, 201819 septiembre, 2018 por Ignacio G.R. Gavilán

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;

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

Develop visión and strategy
Develop and manage products and services
Market and sell productos and services
Deliver physical products
Deliver services
Manage customer service
Develop and manage human capital
Manage information technology (IT)
Manage Financial Resources
Acquire, construct and manage assets
Manage enterprise risk, compliance, remediation and resiliency
Manage external relationships
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?

Publicada en 13 septiembre, 201813 septiembre, 2018 por Ignacio G.R. Gavilán

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

Publicada en 6 septiembre, 20185 septiembre, 2018 por Ignacio G.R. Gavilán

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

Publicada en 9 agosto, 20189 agosto, 2018 por Ignacio G.R. Gavilán

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

Publicada en 2 agosto, 20181 agosto, 2018 por Ignacio G.R. Gavilán

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

Publicada en 26 julio, 201825 julio, 2018 por Ignacio G.R. Gavilá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