Mario Saffirio

Salvo para el caso de una empresa que recién se inicia, ya todas tienen sus procesos de negocios funcionando de alguna manera, por tanto la estrategia de hacer todo de nuevo como proponía la Re-ingeniería [1] no parece adecuada. Entonces surge la estrategia de la gradualidad, del poco a poco, del mejoramiento continuo o como quieran denominarla. Es decir el cambio debe realizarse alterando lo menos posible la operación diaria. O como decía un jefe mío: “Hay que cambiar la rueda, con el auto en movimiento”.

 

Sabemos que todo cambio despierta suspicacias, y dado que estoy pensando en empresas grandes, también aparece el tema del poder. Puesto que el cambio, como decíamos en otro época, “cambia la correlación de fuerzas”. De modo que quienes nos decimos expertos en BPM debemos intentar generar objetividad, entendiendo por tal criterios que sean aceptados por la organización, en particular sus ejecutivos, para calificar cuales procesos de negocios necesitan ser intervenidos –mejorados [2] o porque la empresa necesita incorporar BPM, es lo que Hammer denomina “transición hacia procesos”.

 

En este artículo les presentaré el Modelo de Madurez, en particular su aspecto práctico que es la Escala de Madurez , que es una herramienta simple de utilizar y que permite clasificar los Procesos de Negocios, sea para mejorarlos o porque se necesita alguna certificación (SoX, ISO, etc.)

 

Modelos de Madurez

El objetivo de este modelo es determinar cual es el estado de desarrollo de los Procesos de Negocios de una organización, por consiguiente la base es determinar un conjunto de reglas con las cuales se evaluará un determinado proceso. En otras palabras se trata de convenir una escala de medida y después aplicarla. A continuación veremos dos modelos: el Process and Enterprise Maturity Model (PEMM™) de Michael Hammer [3] y el de la Sofware Engineering Institute  llamado Capability Maturity Model [4]. En las referencias podrán encontrar la descripción completa de cada uno de los modelos.

 

Process and Enterprise Maturity Model (PEMM)

 

Este modelo considera dos dimensiones: los Procesos y la Organización

 

• Para los procesos considera como habilitadores de la madurez: a) El diseño (propósito, contexto, documentación); b) Usuarios (conocimientos, habilidades, comportamiento frente al cambio); c) Dueño (Individualizado, pro-activo, con autoridad); d) Infraestructura (sistemas de información y recursos humanos) y, e) Métricas (definidas y en uso).

 

• A nivel organizacional considera: a) Liderazgo (awareness, alineamiento, comportamiento, estilo); b) Cultura (Equipo de trabajo, foco en el cliente, responsabilidad, actitud frente al cambio); c) Conocimiento (personas, metodologías) y, d) Gobernabilidad (modelos de procesos, accountability, integración).

 

En la figura adjunta podrán ver una parte de la matriz de evaluación y para un mayor detalle de este modelo pueden ver (pagando) el artículo del Dr. Hammer  PEMM can be The Process Audit, publicado en Abril del  2007 en el Harvard Business Review.

 

 

 

Capability Maturity Model (CMM)

El CMMI® (Capability Maturity Model® Integration) es un modelo de Madurez que permite el mejoramiento del desasarrollo de productos y servicios. Consiste en un conjunto de la mejores prácticas que cubre el ciclo de vida de un producto – software- desde su concepción a la entrega y su operación / mantenimiento. Este modelo esta uso desde la década de los 90 y su desarrollo lo ha realizado el Software Engineering Institute [5]. Para el propósito de este artículo lo que interesa es como este modelo clasifica un sistema, la escala que emplea la vemos en la tabla siguiente:

 

 

Nivel	Características	Area Clave del Proceso
Optimizado (5)	Capacidad de Mejoramiento Continuo.	- Proceso de Gestión de Cambio. - Innovación Tecnológica. - Prevención de Fallas.
Administrado (4)	Planeación de la calidad del producto y seguimiento de las mediciones del proceso de producción del software	- Gestión de Calidad del Software. - Gestión cuantitativa del proceso de generación del software.
Definido (3)	Proceso de Ciclo de Vida definido e institucionalizado para proveer control de calidad	- Revisión Pares (Colegas). Coordinación inter-grupos Aplicación de la Ingeniería de Software Software para la gestión del desarrollo Programa de capacitación Definición de la organización del proceso Foco en la organización del proceso
Repetible (2)	Supeervisión de la gestión y seguimiento del proyecto Planificación formal	Gestión de la configuración del software Control de Calidad del software Gestión de los desarrollos subcontratados Supervisión y seguimiento de la ejecución del proyecto de software Planificación formal del proyecto de software Gestión de requerimientos
Inicial	Ad-hoc (impredecible, caótico)	–

 

Podemos apreciar que este modelo utiliza una sola dimensión: la Ingeniería de Software, cada uno de los niveles requiere que estén en uso ciertos elementos propios de ésta ingeniería, de ahí el nombre mide la capacidad de utilización de la Ingeniería de Software.

 

Un ejemplo de Escala de Madurez basada en el Capability Maturity Model es la que ocupa la COBIT,  este modelo ayuda a la gerencia de TI a buscar por medio de  benchmarking y herramientas de auto-evaluación respuesta a la necesidad de saber qué hacer de manera eficiente. Comenzando con los procesos y los objetivos de control de alto nivel de COBIT, el propietario del proceso se debe poder evaluar de forma progresiva, contra los objetivos de control. Esto responde a tres necesidades:

 

1.      Una medición relativa de dónde se encuentra la empresa

2.      Una manera de decidir hacia dónde ir de forma eficiente

3.      Una herramienta para medir el avance contra la meta

 

 El modelado de la madurez para la administración y el control de los procesos de TI se basa en un método de evaluación de la organización, de tal forma que se pueda evaluar a sí misma desde un nivel de no-existente (0) hasta un nivel de optimizado (5). Gráficamente se tiene:

 

 

 

El detalle de cada un de los niveles de la Escala COBIT de Madurez pueden verlo en mi artículo “La COBIT y la Organización del Área Informática”.

 

Generación de una Escala de Madurez

A partir de los Modelos PEMM y del CMM podemos generar un escala para medir como están implementados y como se usan los procesos de negocios en una organización. Del modelo PEMM usamos la dimensión que mide los procesos y del modelo CMM / COBIT ocupamos los seis niveles que define.

 

El siguiente paso es establecer cuales características de los procesos de negocios nos interesa evaluar, supongamos que nos interesa evaluar tres:

 

• Uso de un software homologado por la organización.
• Gobernabilidad, si el proceso esta formalizado y es auditado.
• Estandarización, si el proceso esta operando con igual modelo en las distintas filiales de la organización.

 

Ahora viene asignar las características a cada uno de los niveles o estado:

 

0 – No Existente, el proceso no utiliza funcionalidad de un sistema homologado.

1 – Inicial, el proceso está parcialmente implementado en un sistema homologado o usa desarrollo propios  habiendo funciones estándares o su uso es inadecuado o no corresponde a una Best Practice.

2 – Repetible, el proceso esta soportado, en gran medida, por la funcionalidad de un sistema homologado pero, no está estandarizado y no tiene gobernabilidad.

3 – Definido, el proceso esta soportado por la funcionalidad de un sistema homologado, no está estandarizado pero, tiene gobernabilidad.

4 – Administrado, el proceso está completamente soportado por la funcionalidad de un sistema homologado tanto en la operación (transacciones) como en la gestión (analytics), los procesos de negocios están estandarizados para las distintas filiales y se cuenta con una gobernabilidad que permite garantizar que los procesos operan de acuerdo a sus diseños y a las normativas (SoX, ISO, etc.)

5 – Optimizado, Los procesos de negocios se han refinado hasta un nivel de mejor práctica, se basan en los resultados de mejoras continuas y diseños. Se miden –benchmarking- respecto a como operaran en otras organizaciones similares.

 

A esta escala, ocupando la idea del PEMM, se le puede agregar un semáforo, donde:

 

• Rojo corresponde a 0 y 1. Los procesos en Rojo son los urgentes de mejorar.
• Amarillo corresponde a 2 y 3. Los procesos en Amarillo son deseables de mejorar tan pronto sea posible.
• Verde corresponde a 4  y 5. Estos procesos evolucionan de acuerdo al Mejoramiento Continuo.

 

De este ejemplo se puede concluir que la escala, teniendo claridad respecto a las característica que se desean medir, es fácil de crear. Ya que consiste en asignarle un conjunto de característica a cada estado. También es interesante observar el carácter integrativo de la escala, de aquí lo de Madurez, ya que cada nivel implica que ya se cumplen los requisitos del nivel anterior. Por otra parte el grado de acidez –rigurosidad- de la escala se puede manejar considerando más o menos características, así se tiene que con menos características la escala será más gradual o suave.

 

Aplicación de la Escala de Madurez

Para poder aplicar esta escala es indispensable que los Procesos de Negocios de la organización ya estén identificados y que exista acuerdo “que son todos los que están”. Aquí resulta práctico usar el Mapa de Negocios o generar una lista a partir de los modelos de Cadena de Valor [6].

 

Luego a cada proceso se le asigna el valor de la escala y el color del semáforo, a modo ejemplo

 

 

Esta tabla, de acuerdo con la propuesta original nos dará más objetividad y claridad en nuestras “negociaciones” con los ejecutivos. Puesto que primero nos ponemos de acuerdo en la identificación de los Procesos de Negocios, luego en la Escala y, después los niveles y semáforos nos ayudan a identificar cuales son los procesos necesarios intervenir. Y, por supuesto cada una de la intervenciones se puede transformar en un proyecto y éstos ingresados en un Portafolio se pueden planificar, evaluar económicamente y priorizar.

 

Referencias

[1] Reingeniería de Procesos, Wikipedia

[2] Optimización de Procesos, Ricardo Seguel, BPM Chile

[3] Process and Enterprise Maturity Model, Michael Hammer

[4] Capability Maturity Model, Resumen

[5] Capability Maturity Model, pág. 43,  Software Engineering Institute (Documento completo)

[6] The Value Chain, Dagmar Recklies