Modelo de Referencia 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.