Está en la página 1de 6

Escala de Madurez de Procesos

www.unab.cl
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 no parece adecuada. Entonces surge la estrategia de la gradualidad, del poco a poco, del
mejoramiento continuo o como se quiera denominar. Es decir, el cambio debe realizarse alterando lo
menos posible la operación diaria.

Se sabe 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 otra é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 cuáles 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 , 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 cuál 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 los siguientes aspectos: 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).

2
Para mayores detalles se puede ver un ejemplo de la matriz de evaluación en el artículo del Dr. Hammer,
PEMM can be TheProcessAudit, publicado en Abril del 2007 en el Harvard Business Review.

Capability Maturity Model (CMM)

El CMMI® (Capability MaturityModel® Integration) es un modelo de Madurez que permite el mejoramiento


del desarrollo 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 está en uso desde la década de los 90 y su desarrollo lo ha realizado el SIE (Software Engineering
Institute) [5]. Para el propósito de este artículo lo que interesa es cómo este modelo clasifica un sistema. La
escala que emplea la vemos en la tabla siguiente:

Nivel Características Área Clave del Proceso


Optimizado (5) Capacidad de Mejoramiento - Proceso de Gestión de Cambio.
Continuo. - Innovación Tecnológica.
- Prevención de Fallas.
Administrado (4) Planeación de la calidad del - Gestión de Calidad del Software.
producto y seguimiento de las - Gestión cuantitativa del proceso de generación del
mediciones del proceso de software.
producción del software
Definido (3) Proceso de Ciclo de Vida definido e - Revisión Pares (Colegas).
institucionalizado para proveer Coordinación inter-grupos
control de calidad 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) Supervisión de la gestión y Gestión de la configuración del software
seguimiento del proyecto Control de Calidad del software
Planificación formal 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) –

3
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 esta ingeniería, de ahí que 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 utiliza 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 la posición en que 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:

Generación de una Escala de Madurez


A partir de los Modelos PEMM y del CMM podemos generar una escala para medir cómo están
implementados y de qué forma 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 cuáles 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 está formalizado y es auditado.
· Estandarización, si el proceso está operando con igual modelo en las distintas filiales de la organización.

4
Ahora corresponde 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 BestPractice.

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 está 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, y se basan en
los resultados de mejoras continuas y diseños. Se miden –benchmarking- respecto a cómo operarán 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ísticas 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í hablar de Madurez, puesto
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].

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

Proceso Subproceso Filial 1 Filial 2 Filial 3


Ventas Generación de Leads 0 1 1
Gestión del Pipeline 1 2 2
Registro de Venta 2 2 2
Preparación del Pedido 2 3 3
Despacho
Cobranza

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 cuáles
son los procesos necesarios intervenir. Y, por supuesto, cada una de las intervenciones se puede
transformar en un proyecto y estos, una vez ingresados en un Portafolio, se pueden planificar, evaluar
económicamente y priorizar.

Referencias
[1] Optimización de Procesos, Ricardo Seguel, BPM Chile
[2] Process and Enterprise Maturity Model, Michael Hammer
[3] Capability Maturity Model, Resumen
[4] Capability Maturity Model, Pág. 43, Software Engineering Institute
[5] TheValueChain, DagmarRecklies

Documento Generado a partir del aporte del Sr. Mario Saffirio.

También podría gustarte