FRAMEWORK DE APOYO EN EL ANÁLISIS E IMPLEMENTACIÓN...

Framework de apoyo en el análisis e

implementación de BPM en las

empresas

1

l

FRAMEWORK DE APOYO EN EL ANÁLISIS E IMPLEMENTACIÓN DE BPM EN

LAS EMPRESAS

DIEGO ARMANDO MUÑOZ SALAZAR

LORENA PATRICIA SANCHEZ OSORIO

UNIVERSIDAD DE SAN BUENAVENTURA

FACULTAD DE INGENIERÍA

PROGRAMA INGENIERÍA DE SISTEMAS

SANTIAGO DE CALI

2012



empresas

2

FRAMEWORK DE APOYO EN EL ANÁLISIS E IMPLEMENTACIÓN DE BPM EN

LAS EMPRESAS



Director:

Ingeniero Diego Armando Gómez Mosquera

UNIVERSIDAD DE SAN BUENAVENTURA

FACULTAD DE INGENIERÍA

PROGRAMA INGENIERÍA DE SISTEMAS

SANTIAGO DE CALI

2012



empresas

3

AGRADECIMIENTOS

Expresamos nuestros más profundos agradecimientos

a todas las personas que nos apoyaron

y pusieron su confianza en nosotros durante

la elaboración de esta tesis, en especial a

nuestro director de tesis, el Ingeniero

Diego Armando Gómez Mosquera, quien además

de ser un excelente guía y mentor durante

el transcurso de la carrera, fue un excelente

amigo brindándonos la oportunidad de recurrir a

sus conocimientos cuando más los necesitamos.

Al Ingeniero Luis Merchán por sus valiosas

sugerencias y acertados aportes durante el

desarrollo del proyecto.

LORENA PATRICIA SÁNCHEZ OSORIO




empresas

4

DEDICATORIA

A Dios por darme las fuerzas necesarias para continuar,

luchar e iluminar mi mente cuando todo se tornó oscuro.

A mi madre por su apoyo incondicional,

por confiar en mí y por su constante motivación durante toda la carrera,

en pocas palabras, por hacer de mí la persona que soy ahora,

gracias… Infinitas gracias por todo.

A mis amigos por su confianza y sus palabras

que me enseñaron que puedo llegar tan lejos como me lo proponga.




empresas

5

DEDICATORIA

Primero a Dios por estar conmigo

Por darme la fuerza necesaria,

E iluminar mi mente.

A mis padres y a mi hermana

por ser el apoyo incondicional, motivación y

fuerza a lo largo de mi carrera.

A mis abuelos y mis tíos por su apoyo y fuerza

Que me permite continuar

A mis amigos por su confianza, lealtad y apoyo

Por alegrar aquellos momentos difíciles




empresas

6

Contenido RESUMEN ....................................................................................................................................... 15

ABSTRACT ..................................................................................................................................... 15

INTRODUCCIÓN ............................................................................................................................ 16

1. PLANTEAMIENTO DEL PROBLEMA ............................................................................. 18

2. OBJETIVOS DEL PROYECTO ....................................................................................... 21

2.1 Objetivo general .............................................................................................................. 21

2.2 Objetivos específicos ..................................................................................................... 21

3. ANÁLISIS DE LOS DESARROLLOS Y TENDENCIAS DE LA GESTIÓN DE

PROCESOS DE NEGOCIO (BPM) EN LA INDUSTRIA .......................................................... 22

3.1 Conceptos básicos ......................................................................................................... 22

3.1.1 ¿Qué es un proceso? ..................................................................................................... 22

3.1.2 ¿Qué es una metodología? ........................................................................................... 23

3.1.3 ¿Qué es un método? ...................................................................................................... 23

3.1.4 Diferencia entre Metodología y método ...................................................................... 24

3.1.5 Mejora Continua .............................................................................................................. 24

3.2 Tendencias en mejoramiento de procesos................................................................. 25

3.2.1 Ciclo PDCA ....................................................................................................................... 29

3.2.2 Análisis de valor ............................................................................................................... 32

3.2.3 Simplificación de procesos ............................................................................................ 37

3.2.4 Six sigma .......................................................................................................................... 39

3.2.5 Business process reengineering (BPR) ....................................................................... 44

3.2.6 Business process management (BPM) ........................................................................ 45

4. IDENTIFICACIÓN DE LAS DIFERENCIAS ENTRE BPM Y ANTECESORES ........ 49

4.1 BPM vs TQM ................................................................................................................... 49

4.1.1 Similitudes y diferencias ................................................................................................. 49

4.2 BPM vs Six sigma ........................................................................................................... 50

4.3 BPM vs BPR .................................................................................................................... 53

5 COMUNIDADES ALREDEDOR DE BPM....................................................................... 55

5.1 Club-BPM ......................................................................................................................... 55



empresas

7

5.2 BPM-forum (paises bajos) ............................................................................................. 56

5.3 BPTrends ......................................................................................................................... 57

5.4 Association of business process management professionals (Asociación de

profesionales en BPM) .............................................................................................................. 58

5.5 Workflow management coalition (WFMC) .............................................................. 58

5.6 Object management group (OMG) .............................................................................. 59

5.7 BPM Chile ........................................................................................................................ 60

5.8 BPM .................................................................................................................................. 61

5.9 BPM –Spain ..................................................................................................................... 61

5.10 BPM Insitute .................................................................................................................... 61

6. ESTUDIO COMPARATIVO DE METODOLOGÍAS Y FRAMEWORKS

ENCONTRADOS ............................................................................................................................ 63

6.1 Framework 7FE project ................................................................................................. 63

6.1.1 Fase de estrategia organizacional ................................................................................ 65

6.1.2 Fase de arquitectura del proceso ................................................................................. 66

6.1.3 Fase de plataforma de lanzamiento ............................................................................. 68

6.1.4 Fase de entendimiento ................................................................................................... 70

6.1.5 Fase de innovar ............................................................................................................... 73

6.1.6 Fase de personas ............................................................................................................ 76

6.1.7 Fase de desarrollo ........................................................................................................... 78

6.1.8 Fase de implementación ................................................................................................ 80

6.1.9 Fase de obtener valor ..................................................................................................... 83

6.1.10 Fase de rendimiento sostenible .................................................................................. 85

6.1.11 Gestión de proyectos .................................................................................................... 87

6.1.12 Gestión de cambio de personas ................................................................................. 87

6.1.13 Liderazgo ........................................................................................................................ 87

6.2 IBM BPM framework -prescriptive guide to solution implementation. .................... 88

6.2.1 Fase de descubrimiento ............................................................................................ 88

6.2.2 Fase de Story Boarding ............................................................................................. 89

6.2.3 Fase de experiencia ................................................................................................... 90



empresas

8

6.2.4 Fase de gestión .......................................................................................................... 91

6.3 BPMN-Framework .......................................................................................................... 93

6.3.1 Nivel 1- Procesos Descriptivos ................................................................................. 94

6.3.2 Nivel 2-Procesos Operacionales .............................................................................. 94

6.3.3 Nivel 3a – Modelo Técnico ........................................................................................ 95

6.3.4 Nivel 3b- Especificación para desarrollo ................................................................. 95

6.3.5 Nivel 4b – Implementación ........................................................................................ 95

7 FRAMEWORK BPM-ENTERPRISE ................................................................................ 96

7.1 Fase de Cimientos.......................................................................................................... 98

7.1.1 Entradas de esta fase: ............................................................................................... 98

7.1.2 Salidas de esta fase: .................................................................................................. 99

7.1.3 Pasos ............................................................................................................................ 99

7.2 Fase de Entender ......................................................................................................... 122

7.2.1 Razones a favor: ....................................................................................................... 123

7.2.2 Razones en contra: .................................................................................................. 123

7.2.3 Entradas de esta fase: ............................................................................................ 124

7.2.4 Salidas de esta fase: ................................................................................................ 124

7.2.5 Pasos .......................................................................................................................... 125

7.3 Fase de Innovar ............................................................................................................ 145

7.3.1 Entradas de esta fase .............................................................................................. 145

7.3.2 Salidas de esta fase ................................................................................................. 146

7.3.3 Pasos .......................................................................................................................... 146

7.4 Fase de Desarrollo ....................................................................................................... 184



7.4.3 Pasos .......................................................................................................................... 185

7.5 Fase de Implementación ............................................................................................. 197


7.5.2 Salidas de esta fase ................................................................................................. 198

7.5.3 Pasos: ......................................................................................................................... 198



empresas

9

7.6 Fase de Rendimiento Sostenible ............................................................................... 203

7.6.1 Entradas de esta fase: ............................................................................................. 204


7.6.3 Pasos: ......................................................................................................................... 204

8. RECOMENDACIONES Y TRABAJOS FUTUROS ..................................................... 212

9. CONCLUSIONES ............................................................................................................. 213

10. GLOSARIO ........................................................................................................................ 214

11. BIBLIOGRAFÍA ................................................................................................................. 217



empresas

10

LISTA DE ABREVIATURAS

B2B. Business to Business

BAM. Business Activitiy Monitoring

BPD. Business Process Diagram

BPM. Business Process Management

BPMN. Business Process Modeling Notation

BPMS. Business Process Management Suite

BPR. Business Process Reingeneering

BRMS. Business Rules Management Suite

CoE. Center of Excellence

DMAIC Define-Measure-Analyze-Improve-Control

EAI. Enterprise Application Integration

ESB. Buses de Servicios Empresariales

ISO. Organización Internacional de Normalización

IT. Tecnologías de Información

KPI. Indicadores de rendimiento claves

OMG. Object Management Group

PDCA: Plan-Do-Check-Act

RAD. Rapid Application Development

ROI. Return on Investment

SDLC. Software Development Lifecycle

SOA. Service Oriented Architecture

TI. Tecnologías de Información

TQM. Gestión de Calidad Total

UML. Unified Modeling Language

XML. Extensible Markup Language



empresas

11

LISTA DE GRÁFICAS

Grafica 1: Elementos de un proceso [23] ................................................................................... 22

Grafica 2: Gestión de la Calidad Total [4] ................................................................................... 27

Grafica 3: Ciclo Deming [5]. .......................................................................................................... 29

Grafica 4: BPM: The third wave [11] ............................................................................................ 47

Grafica 5: 7FE Framework (BPM) Vs DMAIC (Six sigma)[11] ................................................ 52

Grafica 6: Framework 7FE [11] .................................................................................................... 64

Grafica 7: Pasos de la fase de estrategia organizacional [16] ................................................ 66

Grafica 8: Pasos Fase de Arquitectura del proceso [16] .......................................................... 67

Grafica 9: Pasos de la fase de plataforma de lanzamiento [16] ............................................. 69

Grafica 10: Pasos de la fase de entendimiento [16] ................................................................. 72

Grafica 11: Pasos fase de innovar [16] ....................................................................................... 74

Grafica 12: Pasos de la fase de personas [16] .......................................................................... 77

Grafica 13: Pasos de la fase de desarrollo [16] ......................................................................... 79

Grafica 14: Pasos de la fase de implementación [16] .............................................................. 81

Grafica 15: Pasos de la fase de obtener valor [16] ................................................................... 84

Grafica 16: Pasos de la fase de rendimiento Sostenible [16] .................................................. 86

Grafica 17: Pasos de la fase de descubrimiento [33] ............................................................... 88

Grafica 18: Pasos de la fase storyboarding [33] ........................................................................ 90

Grafica 19: Pasos de la fase de experiencia [33] ...................................................................... 91

Grafica 20: Pasos de la fase de gestión [33] ............................................................................. 92

Gráfica 21: Marco estructural para BPMN [20] .......................................................................... 93

Grafica 22: Framework propuesto ............................................................................................... 97

Grafica 23: Pasos de la fase Cimientos (Tomada y adaptada de Business Process

Management - Practical Guidelines Successful Implementations) ......................................... 98

Grafica 24: Estructura del equipo del proyecto [16] ................................................................ 102

Grafica 25: Vista de Procesos de la organización [16] ........................................................... 112

Grafica 26: Matriz de selección de procesos [16] ................................................................... 115

Grafica 27: Matriz de Valor de Procesos [16] .......................................................................... 116

Grafica 28: Plan de implementación [16] .................................................................................. 120

Grafica 29: Pasos de la fase Entender (Tomada y adaptada de Business Process

Management - Practical Guidelines Successful Implementations) ....................................... 124

Grafica 30: Marcador tipo loop [16] ........................................................................................... 129

Grafica 31: Bifurcación [16] Grafica 32: Unión [16] ......................................... 130

Grafica 33: Sincronizar [16] Grafica 34: Paralelizar [16] ................................................. 130

Grafica 35: Y/O [16] ..................................................................................................................... 130



empresas

12

Grafica 36: Modelo de Procesos AS-IS .................................................................................... 136

Grafica 37: Cadena Causal como resultado del análisis de Causa-Raíz [20] .................... 142

Grafica 38: Pasos de la fase innovar (Tomada y adaptada de Business Process

Management - Practical Guidelines Successful Implementations) ...................................... 145

Grafica 39: Optimizar el Orden [20] .......................................................................................... 162

Grafica 40: Acelerar [20] ............................................................................................................ 162

Grafica 41: Agregar [20] ............................................................................................................. 162

Grafica 42: Actividad Obsoleta [20] .......................................................................................... 163

Grafica 43: Externalizar [20] ...................................................................................................... 163

Grafica 44: Unir [20] .................................................................................................................... 164

Grafica 45: Paralelizar [20] ........................................................................................................ 164

Grafica 46: Vista del jefe de Área [20] ..................................................................................... 171

Grafica 47: Sistema BPM [16] ................................................................................................... 184

Gráfica 48: Pasos de la fase Desarrollar (Tomada y adaptada de Business Process

Management - Practical Guidelines Successful Implementations) ....................................... 185

Grafica 49: Enlazando requerimientos, realización del sistema y pruebas [16] ................ 188

Grafica 50: Enfoque tradicional SDLC [16] .............................................................................. 193

Grafica 51: Pasos de la fase de Implementación (Tomada y adaptada de Business

Process Management - Practical Guidelines Successful Implementations) ....................... 197

Grafica 52: Pasos de la fase Rendimiento Sostenible (Tomada y adaptada de Business

Process Management - Practical Guidelines Successful Implementations) ....................... 204

Grafica 53: Ciclo Deming [5] ....................................................................................................... 206

Grafica 54: Ciclo de pre-alimentación [16] ............................................................................... 207

Grafica 55: Ciclo de Retro-alimentación [16] ........................................................................... 208



empresas

13

LISTA DE TABLAS

Tabla 1. Evolución de BPM [2] ..................................................................................................... 25

Tabla 2. Objetivos y resultados del análisis de valor [7] .......................................................... 33

Tabla 3. Datos importantes para el análisis [7] .......................................................................... 35

Tabla 4. BPM Vs Six sigma [17].................................................................................................. 51

Tabla 5. BPM Vs BPR [32] ............................................................................................................ 53

Tabla 6. Matriz de Capacidad de Personas [16] ..................................................................... 144

Tabla 7: Cuadro comparativo con las características principales de los enfoques

propuestos. [16] ............................................................................................................................ 161

Tabla 8: Requerimientos adicionales para la implementación técnica [20] ....................... 173

Tabla 9: Ejemplo de Tabla de decisiones [20] ........................................................................ 175

Tabla 10: Tabla RACI [16].......................................................................................................... 178

Tabla 11: Componentes de una solución automatizada de BPM [16] ................................ 187

Tabla 12: Escenarios de implementación [16] ......................................................................... 199

Tabla 13. Formato para la especificación de un Plan de Pruebas [18] ............................... 242



empresas

14

LISTA DE ANEXOS

Pág.

Anexo 1. Bibliografía de las tendencias en mejoramiento de procesos .......................... 220

anexo 2. Comunidades más destacadas ....................................................................... 222

anexo 3. Tabla de roles involucrados ............................................................................. 223

anexo 4. Formulario 1 – pre fase .................................................................................. 226

anexo 5. Template del caso de negocios ....................................................................... 229

anexo 6. Registro de problemas y oportunidades .......................................................... 232

anexo 7. Lista de los stakeholders involucrados ............................................................ 233

anexo 8. Acta a stakeholders que valide su participación, compromiso y expectativas

documentadas y acordadas. .......................................................................................... 234

anexo 9. Lista de procesos de negocio identificados ..................................................... 235

anexo 10. Lista de procesos priorizados ........................................................................ 236

anexo 11. Equipo del proyecto establecido y sus respectivos roles ............................... 237

anexo 12. Informe final de la fase .................................................................................. 239

anexo 13. Acta de información y aceptación de los stakeholders externos .................... 241

anexo 14. Formato para la especificación de un plan de pruebas. ................................. 242

anexo 15. Estimación de tiempo en microsoft proyect .................................................. 250



empresas

15

RESUMEN

Partiendo de la necesidad de implementar satisfactoriamente proyectos de BPM

(por sus siglas en inglés Bussines Process Management) en las organizaciones,

se estableció como objetivo general de nuestro proyecto proponer un marco

metodológico que permita la realización de dichos proyectos, para lo cual fue

necesario analizar los desarrollos y tendencias de la gestión de procesos de

negocio vigentes en la industria y posteriormente se analizaron y evaluaron las

propuestas metodológicas referenciadas en la literatura, comunidad e industria, lo

cual dio paso a la creación de un framework que pueda ser adaptado a las

necesidades de las empresas Colombianas para el análisis e implementación de

proyectos BPM.

El framework propuesto, se validará posteriormente en un ambiente controlado

para hacer las respectivas mejoras, buscando proporcionar un valor agregado a

las empresas que decidan implementar esta propuesta metodológica.

Es importante resaltar que el lector de la tesis debe tener conocimientos básicos

de BPMN 2.0

ABSTRACT

Beginning with the need of implementing BPM projects successfully to the

organizations, was established as a general objective of our project to propose a

methodological framework that allows the realization of such projects, it was

necessary to analyze the Business Process Management developments and

tendencies used by the industry and analyzed and evaluated the methodological

proposals, which leads to the creation of a BPM development framework based on

the extraction of the found methodological proposals‟ outstanding characteristics.

To use the created framework, this joins up more efficiently the needs of

Colombian companies to the analysis and the implementation of the BPM project

The proposal framework will be validated in a controlled environment by the

generation of additional value to those companies that decide to implement this

proposal.

It is important to people who read this document to have basic knowledge on

BPMN 2.0



empresas

16

INTRODUCCIÓN

Desde el año 1980 se ha desarrollado mundialmente una tendencia empresarial

para el mejoramiento de procesos, el cual inicio con la gestión de la calidad total

(TQM por sus siglas en inglés Total Quality Management), luego en los 90‟s la

Reingeniería de procesos y desde el año 2000 se inicia una nueva era dedicada a

la gestión de procesos de negocio BPM.

BPM es un conjunto de métodos, herramientas y tecnologías utilizados para

diseñar, representar, analizar y controlar los procesos de negocio operacionales,

es un enfoque centrado en los procesos para mejorar el rendimiento que combina

tecnologías de la información con metodologías de proceso y gobierno [14]

Hasta el 2008 donde se realizó un estudio que indaga acerca de los métodos o

metodologías existentes, para la implementación de Sistemas de Administración

de Procesos (BPMS, por sus siglas en inglés Business Process Management

Systems), y una de las conclusiones después de un largo proceso fue que existe

la necesidad de una metodología que supla las características propias de los

BPMS ya que las metodologías usadas en IT no hacen frente a los siguientes

puntos críticos: modelos de estimación: tiempo pactado y costos; falta de

plantillas; gestión del cambio; métrica del proyecto y adicionalmente se concluyó

que existe la necesidad de una metodología propia para aplicar BPM ya que

actualmente se obtienen préstamos de diferentes enfoques para apoyar el diseño

de procesos de negocio y la gestión de asignación de responsabilidades [19]

Es por esto que se decidió realizar una investigación donde finalmente se

desarrollará un framework de apoyo en el análisis e implementación de BPM en

las empresas.

Durante el desarrollo de este trabajo investigativo se hará un recorrido por las

metodologías antecesoras de BPM, pues de estas es que se obtienen las mejores

prácticas, se realizará una comparación de BPM contra cada una de las

metodologías demostrando porque BPM finalmente es la mejor opción.

Se realizará un análisis de las metodologías de apoyo para la implementación de

BPM en las empresas mundiales que han sido previamente documentadas; a

partir del análisis realizado, se identifican y analizan las mejores prácticas de cada

una de las metodologías, para proponer una nueva tecnología que reúna lo que



empresas

17

consideramos las “mejores prácticas”. Esta propuesta presenta un enfoque

administrativo y un enfoque técnico, que sea ágil, diseñado para implementarse en

pequeñas y medianas empresas.

La información en el documento se presenta de la siguiente manera:

En el capítulo 1 se expone el planteamiento del problema, en el capítulo 2 los

objetivos del proyecto, en el capítulo 3 una introducción al tema a tratar, los

conceptos base de la investigación, el estudio de las tendencias en mejoramiento

de procesos y se aclara que es realmente BPM, en el capítulo 4 se podrá

identificar las diferencias entre BPM y sus antecesores, en el capítulo 5 se expone

un resumen de las comunidades alrededor de BPM, en el capítulo 6 se realiza un

breve resumen de las metodologías y framework encontrados , en el capítulo 7 se

expone el framework desarrollado y finalmente en el capítulo 8 las

recomendaciones para trabajos futuros.



empresas

18

1. PLANTEAMIENTO DEL PROBLEMA

Anteriormente las industrias veían la tecnología como un gasto a realizar y a las

personas que pertenecen al departamento de sistemas como un problema para la

compañía.

A partir del año 1980[2] y basándose en estudios de metodologías como TQM,

análisis de valor, el ciclo PDCA, y reingeniería de procesos; las empresas

descubren que toda su actividad debe estar centrada en los procesos y que es de

estos de quien depende su rendimiento y efectividad.

Las metodologías anteriormente mencionadas han evolucionado con el pasar del

tiempo hasta llegar a BPM que es un conjunto de métodos, herramientas y

tecnologías utilizados para diseñar, representar, analizar y controlar procesos de

negocio.

En Colombia se han realizado varios estudios para determinar el grado de

conocimiento de las empresas con respecto a BPM y su implementación; en el

año 2008 un estudio investigativo concluyo: “Según el sondeo realizado por

BPTrends: State of Business Process Management – 2008(EEUU); el artículo

escrito por Jeremy Payne, Director de Marketing Europa: BPM y la metodología

de la ―bola de cristal‖; Y el diagnóstico realizado en algunas empresas

nacionales y multinacionales de Cali y Bogotá(CIAT, Coomeva Sector Salud,

Ecopetrol, Fundacion WWB Colombia, Geniar, Lucasians, Cadbury Adams

Colombia, Assenda Carvajal, Comfandi, Enterprise Data System - Grupo Bimbo,

UPS Supply Chain Solutions (Colombia), KeyVolution3, Synapsis, Acueducto de

Bogotá y Quebecor World), se concluye que: empresas de todos los tamaños, en

todas las zonas geográficas, están explorando opciones e invirtiendo en BPM. Se

mueven más rápidamente en la adopción del modelado de procesos y rediseño,

y más lentamente cuando se enfrentan con las nuevas tecnologías como BPMS

para automatizar, simular, ejecutar y monitorear sus procesos. Un grupo aún

mayor de empresas, en todo el mundo, asisten a conferencias en busca de

obtención de formación con el fin de comprender mejor sus opciones en un

mercado versátil pues las empresas no conocen alguna metodología para la

implementación de BPM, solo siguen los métodos que indican cada herramienta

en particular” [19]

Otro estudio realizado en el año 2010 dedico su esfuerzo a la percepción de BPM

en las empresas de Medellín, donde se concluye lo siguiente: “De los resultados



empresas

19

preliminares se estima que del total de empresas que ejercen actividades

económicas en la ciudad, el 89% son microempresas; el 9,7% se clasifican como

PYMES (pequeñas y medianas empresas) y el 1,3% grandes compañías. La

densidad empresarial, se mide de acuerdo con el número de empresas por

habitantes en un territorio. Esta medida, es de 30 empresas por cada 1.000

habitantes” [21].

Es decir, si “la población en Medellín y el área metropolitana es de

aproximadamente 3,312.165 habitantes” entonces el número total de empresas

que ejercen actividades económicas en la misma área es de 99.365, de estas

88.435 son microempresas, 9.638 pertenecen a las PYMES y 1.292 son grandes

compañías. Del análisis de los datos se puede concluir que el 94% de las

empresas encuestadas manifiestan que sí tienen conocimiento sobre el enfoque

de Gestión por Procesos de Negocio, mientras que el 6% manifiesta que no. Por

otro lado el 100% de las empresas encuestadas consideran importante el tema de

la Gestión de Procesos de Negocio, pero solo el 85% de las empresas

encuestadas tienen actualmente en su empresa los procesos de negocio

estandarizados y documentados, mientras que el 15% no. Las principales causas

por las que no desarrollan este trabajo son las siguientes: cambios rápidos en los

procesos, falta de personal calificado para la documentación de procesos, falta de

capacitación, es un proyecto que aún no se ha realizado, falta de presupuesto,

falta de organización y procesos desactualizados [21].

El 56% de las empresas encuestadas han escuchado hablar de alguna

metodología para la Gestión de Procesos de Negocio, entre las cuales mencionan

las siguientes: Unidades Estratégicas de Negocios (UEN), BPM de Microsoft,

Estandarización y Documentación de Procesos, Diagramas y flujo-gramas de

procesos, Sistema de Gestión de Calidad ISO 9000 para procesos, ISO 9001,

Netweaver (BPM), Filenet y Oracle BPM; mientras que el 44% no han escuchado

hablar de ninguna metodología para la gestión de procesos de negocio [21].

Finalmente sólo el 35% de las empresas sondeadas conocen y emplean BPM

para definir, modelar, automatizar y medir sus procesos de negocio, mediante el

uso de un sistema BPM de tipo comercial que les permita manejar

transversalmente sus procesos de negocio.” [21].

Teniendo en cuenta el estudio realizado a las principales ciudades de Colombia se

puede concluir que actualmente en Colombia las empresas de software

desconocen las ventajas y el valor agregado que les pueden ofrecer estas



empresas

20

tecnologías innovadoras al negocio, al no tener claro los conceptos y las ventajas

que BPM traería a la compañía, estas se embarcan en los proyectos de

mejoramiento de procesos basándose en experiencias anteriores(como por

ejemplo BPR) las cuales en su gran mayoría terminan fracasando debido a que su

implementación no se basa en ninguna metodología, es decir, se hace de manera

intuitiva

Es allí donde este trabajo pretende entregar un framework para el entendimiento

y apropiación de las tecnologías de gestión de procesos de negocios, brindando

una metodología para tener mayor aprovechamiento de los procesos de negocio

buscando garantizar su adaptabilidad a los entornos constantemente cambiantes y

generando valor para ser cada vez más competitivos.



empresas

21

2. OBJETIVOS DEL PROYECTO

2.1 Objetivo general

Proponer un marco metodológico que permita adelantar proyectos de

implementación de BPM en las empresas.

2.2 Objetivos específicos

Analizar los desarrollos y tendencias de la gestión de procesos de negocio

(BPM) en la industria.

Analizar y evaluar las propuestas metodológicas referenciadas en la literatura,

comunidades (académicas y científicas) e industria.

Proponer un framework para el desarrollo de proyectos BPM.

Formular un Roadmap de mejoramiento para el framework.



empresas

22

3. ANÁLISIS DE LOS DESARROLLOS Y TENDENCIAS DE LA GESTIÓN

DE PROCESOS DE NEGOCIO (BPM) EN LA INDUSTRIA

3.1 Conceptos básicos

3.1.1 ¿Qué es un proceso?

Un proceso es un conjunto de actividades o eventos (coordinados u organizados)

que se realizan o suceden (alternativa o simultáneamente) con un fin determinado.

Este término tiene significados diferentes según la rama de la ciencia o la técnica

en que se utilice. [22]

Un proceso básicamente tiene cuatro elementos (ver Grafica 1) [23]

Grafica 1: Elementos de un proceso [23]

Entradas: [23]

Son características definidas de antemano que permite aceptarlas o rechazarlas.

Salidas: [23]

Producto/Servicio destinado al cliente interno/externo.

Es habitual que la salida de un proceso sea la entrada del siguiente, si la

entrada del siguiente proceso no cumple con la calidad esperada es seguro

http://arpcalidad.com/wp-content/uploads/2010/05/image.png






empresas

23

que la salida tampoco, provocando una cadena que desemboca en el

cliente final.

Recursos o factores del proceso: [23]

Personas: ¿Quién lo hace? Tanto en el concepto físico como en el de

competencias, habilidades necesarias, formación requerida, etc.

Materiales: ¿Con qué lo hace? En término de materias primas o semi

elaboradas. No se debe pensar únicamente en materiales físicos, ya que

por ejemplo en empresas de servicio la información también es una

materia prima.

Infraestructura: ¿Con qué herramientas? Instalaciones, maquinaria,

hardware, software.

Método: ¿Quién hace qué?, ¿cómo lo hace? y ¿cuándo lo hace?

Sistema de control: [23]

Formado por los indicadores, sus objetivos y los cuadros de mando

resultantes para la toma de decisiones.

Es fundamental para evaluar la marcha del proceso, corregir deficiencias y

mejorar continuamente.

3.1.2 ¿Qué es una metodología?

La metodología es parte del proceso de investigación que sigue un conjunto de

saberes y disciplinas que son necesarios para preparar el estudio de una

materia y que posibilita la sistematización de los métodos y de las técnicas

necesarias para llevarla a cabo [24].

En otras palabras, la metodología es una etapa específica que procede de una

posición teórica y epistemológica, para la selección de técnicas concretas de

investigación. La metodología, entonces, depende de los postulados que el

investigador crea que son válidos, ya que la acción metodológica será su

herramienta para analizar la realidad estudiada [24].

3.1.3 ¿Qué es un método?

Un método es una serie de pasos sucesivos, que conducen a una meta.

El objetivo del profesional es llegar a tomar las decisiones y una teoría que



empresas

24

permita generalizar y resolver de la misma forma problemas semejantes en el

futuro. Por ende es necesario que siga el método más apropiado a su problema, lo

que equivale a decir que debe seguir el camino que lo conduzca a su objetivo. El

método es un orden que se debe imponer a los diferentes procesos necesarios

para lograr un fin [25].

3.1.4 Diferencia entre Metodología y método

La metodología es el enlace entre el sujeto y el objeto de conocimiento. Sin ella

es prácticamente imposible logra el camino que conduce al conocimiento científico

[1].

El método es el camino que conduce al conocimiento es un procedimiento o

conjunto de procedimientos que sirven de instrumentos para lograr los objetivos de

la investigación [1].

3.1.5 Mejora Continua

La mejora continua es una herramienta de incremento de la productividad que

favorece un crecimiento estable y consistente en todos los segmentos de un

proceso. [26]

La mejora continua asegura la estabilización del proceso y la posibilidad de

mejora. Cuando hay crecimiento y desarrollo en una organización o comunidad, es

necesaria la identificación de todos los procesos y el análisis mensurable de cada

paso llevado a cabo. Algunas de las herramientas utilizadas incluyen las acciones

correctivas, preventivas y el análisis de la satisfacción en los miembros o clientes.

[26]



empresas

25

3.2 Tendencias en mejoramiento de procesos

En el siguiente capítulo se expone una minuciosa investigación acerca de las

metodologías y modelos que se enfocan en los procesos de las compañías. Se

podrá ver una evolución desde los años 70 hasta la actualidad, dicha investigación

muestra a BPM como el resultado de las mejores prácticas y experiencias

recopiladas en este proceso evolutivo, alineadas con las TI [2].

Tabla 1. Evolución de BPM [2]

En las tendencias en mejoramiento de procesos se pueden destacar dos, TQM

(total quality management) y Six sigma que actualmente son las metodologías más

estructuradas y más usadas para el mejoramiento de procesos.

Los orígenes de TQM se remontan a los años 50, cuando un grupo de expertos

encabezado por W. Edwards Deming introdujeron este concepto. El principio de

TQM se basó en el control de la calidad en los procesos productivos, a través del

uso de técnicas estadísticas y en la posterior toma de medidas de control para la

reducción de las desviaciones [4].



empresas

26

Actualmente TQM es la forma de realizar la gestión para un futuro, y es mucho

más amplia en la aplicación de la técnica que hacen el aseguramiento de la

calidad de un producto o servicio, esta es la manera en que se realiza la gestión

de las personas y los procesos de negocio asegurando una completa satisfacción

del cliente en cualquier escenario sea interno o externo. TQM combina de manera

efectiva: líderes, resultados y una organización haciendo las cosas correctas de

manera correcta y en el primer lugar [4].

Para asegurar la calidad no basta con que la dirección de la compañía tenga claro

que se deben ofrecer los productos y servicios de la mejor calidad, se necesita

que esta filosofía de mejoramiento de la calidad de los productos o servicios sea

implementada en todo el personal asociado a la compañía[4].

La gestión total de la calidad supone tres (3) aspectos: planificar la calidad,

controlar la calidad y mejorar la calidad [4].

La planificación de la calidad se realiza después del inicio de toda actividad,

este implica el desarrollo de productos o procesos que satisfacen las necesidades

de los clientes de la mejor manera, el control de la calidad se basa en las

posibles desviaciones que se producen en la realización de los procesos, estas

desviaciones se evalúan y se toman la medidas necesarias para la corrección. Y

por último está el mejoramiento de la calidad que es una actividad que trata de

corregir las deficiencias de las etapas anteriores, elevando así los índices de

calidad en las futuras planificaciones [4].

Estos tres (3) aspectos están relacionados y constituyen la base de la gestión de

la calidad total, finalmente como retroalimentación entre las tres (3) fases se sitúa

el aprendizaje como veremos en la Grafica 2.

.



empresas

27

Grafica 2: Gestión de la Calidad Total [4]

El proceso de la implantación de la TQM se compone por diez (10) factores:

liderazgo, adopción de la filosofía, implicación de los clientes, implicación de

proveedores, organización abierta y flexible, formación/entrenamiento, delegación

de poder, benchmarking, mejora de procesos y mentalidad “cero defectos” [4].

Liderazgo / compromiso de la dirección: La implantación de TQM requiere de

un compromiso a largo plazo por parte de los directivos, la misión principal de ellos

es dirigir el cambio y ejercer como ejemplo para que las ideas se entiendan y se

extiendan rápidamente por toda la organización [4].

Adopción de la filosofía: Se debe integrar TQM con la misión y el proyecto de la

empresa, esta sería la parte teórica, y se debe instaurar mecanismos que hagan

de la TQM parte activa de la empresa, sistemas como auditoria y autoevaluación

de la calidad sería lo recomendado para este factor [4].

Implicación de los clientes: Se realiza un estudio acerca de los clientes, este

estudio busca determinar sus necesidades, conocer sus peticiones logrando así

un acercamiento con ellos, logrando que estos hagan parte desde las primeras

fases de desarrollo de los productos [4].

Implicación de proveedores: Se compromete a los proveedores en las tareas

internas, cooperando con la compañía, asegurando que lo que suministran a la

empresa están conformes a las especificaciones y requisitos que la calidad implica

[4].



empresas

28

Organización abierta y flexible: Esta tarea es de la alta dirección y se enfoca en

la creación de una cultura de equipo donde la comunicación entre los implicados

en el proceso, la reducción de jerarquía tradicional y burocracia son los pilares,

logrando finalmente una completa autonomía a la hora de tomar decisiones [4].

Formación/entrenamiento: Implica a todo el personal de la empresa y brinda a

los empleados la capacidad de reconocer y proporcionar fuentes de desarrollo y

formación [4].

Delegación de poder: A través de este factor los empleados tienen un contacto

directo en los procesos de diseño y planificación, esto implica a los empleados

mayor compromiso y seguimiento con el producto que el trabajador tiene a su

cargo [4].

Benchmarking: Este factor evalúa e investiga las prácticas realizadas por otras

empresas, buscando así la comprensión de las mejores prácticas competitivas [4].

Mentalidad “cero defectos”: Este factor implica el grado en que la empresa

puede y debe eliminar los defectos y las causas que los provocan, realizando un

énfasis en la mejora continua, estos esfuerzos deben hacer parte de la actitud de

la empresa, no solo un cargo que desempeña una sola persona [4].

Mejora de procesos: Este factor que le da valor agregado a la compañía, pues

está en búsqueda constante de mejoramiento de los procesos, logrando así una

empresa con unos buenos procesos, eficientes y que brinden productos o

servicios que satisfacen las necesidades del cliente. En mejora de procesos se

puede ver muchas metodologías, se analizaran algunas y se mencionaran otras,

cabe resaltar que nuestro tema principal no es el mejoramiento de la calidad, si se

desea ampliar el conocimiento acerca de estos temas se puede ver el anexo 1 [4].

Dentro de esta metodología de mejoramiento de procesos se puede ver el ciclo

PDCA (por sus siglas en ingles Plan, Do, Check, Act (Planificar, Hacer, Verificar,

Actuar), análisis de valor, y la simplificación de operaciones [27].



empresas

29

3.2.1 Ciclo PDCA

El ciclo PDCA, también conocido como "Círculo de Deming o circulo de Gabo"

(de Edwards Deming), es una estrategia de mejora continua de la calidad de los

procesos en cuatro pasos, basada en un concepto ideado por Walter A. Shewhart.

También se denomina: “espiral de mejora continua” [27].

A partir del año 1950, y en repetidas oportunidades durante las dos décadas

siguientes, Deming empleó el Ciclo PDCA como introducción a todas y cada una

de las capacitaciones que brindó a la alta dirección de las empresas japonesas.

De allí hasta la fecha, este ciclo (que fue desarrollado por Shewhart), ha recorrido

el mundo como símbolo indiscutido de la Mejora Continua. Las Normas NTP-ISO

9000:2001 basan en el Ciclo PDCA su esquema de la Mejora Continua del

Sistema de Gestión de la Calidad. En la Grafica 3 [5] se podrá apreciar el ciclo

Deming [5] .

Grafica 3: Ciclo Deming [5].



empresas

30

3.2.1.1 Paso 1. Planificar (PLAN) [28].

Primero se debe analizar y estudiar el proceso decidiendo qué cambios pueden

mejorarlo y en qué forma se llevarán a cabo. Para lograrlo es conveniente

trabajar en un subciclo de 5 pasos sucesivos que son:

3.2.1.1.1 Definir el/los objetivo/os. Se deben fijar y clarificar los límites del

proyecto: ¿Qué vamos a hacer? ¿Por qué lo vamos a hacer? ¿Qué queremos

lograr? ¿Hasta dónde queremos llegar?

3.2.1.1.2 Recopilar los datos. Se debe investigar: ¿Cuáles son los síntomas?

¿Quiénes están involucrados en el asunto? ¿Qué datos son necesarios?

¿Cómo los obtenemos? ¿Dónde los buscamos? ¿Qué vamos a medir y con

qué? ¿A quién vamos a consultar?

3.2.1.1.3 Elaborar el diagnóstico. Se deben ordenar y analizar los datos:

¿Qué pasa y por qué pasa? ¿Cuáles son los efectos y cuáles son las causas

que los provocan? ¿Dónde se originan y por qué?

3.2.1.1.4 Elaborar pronósticos. Se deben predecir resultados frente a

posibles acciones: ¿Sabemos qué efectos provocarán determinados cambios?

¿Debemos hacer pruebas previas? ¿Debemos consultar a especialistas? ¿Es

necesario definir las situaciones especiales? Frente a varias opciones se

adoptará la que se considere mejor.

3.2.1.1.5 Planificar los cambios. Se deben decidir, explicitar y planificar las

acciones y los cambios a instrumentar: ¿Qué se hará? ¿Dónde se hará?

¿Quiénes lo harán? ¿Cuándo lo harán? ¿Con qué lo harán? ¿Cuánto costará?

3.2.1.2 Paso 2. Hacer (DO) [28].

A continuación se debe efectuar el cambio y/o las pruebas proyectadas según la

decisión que se haya tomado y la planificación que se ha realizado. Esto es

preferible hacerlo primero en pequeña escala siempre que se pueda (para revisar

resultados y poder establecer ajustes en modelos, para luego llevarlos a las

situaciones reales de trabajo con una mayor confianza en el resultado final).



empresas

31

3.2.1.3 Paso 3. Verificar (CHECK) [28].

Una vez realizada la acción e instaurado el cambio, se debe verificar. Esto

significa observar y medir los efectos producidos por el cambio realizado al

proceso, sin dejar de comparar las metas proyectadas con los resultados

obtenidos chequeando si se ha logrado el objetivo previsto, para lo cual es

importante hacerse preguntas como: ¿Se han alcanzado los resultados deseados?

¿Qué se aprendió? ¿Qué queda aún por resolver?

3.2.1.4 Paso 4: Actuar (ACTION) [28].

Para terminar el ciclo se deben:

Incorporar las mejoras al proceso

Comunicar las mejoras a todos los integrantes de la empresa

Identificar nuevos proyectos/problemas

Lo anterior, con el fin de analizar: ¿Qué aprendimos? ¿Dónde más podemos

aplicarlo? ¿Cómo aplicarse a gran escala? ¿De qué manera puede ser

estandarizado? ¿Cómo mantendremos la mejora lograda? ¿Cómo lo extendemos

a otros casos o áreas?

Estos 4 pasos, aseguran para el proyecto:

1. La organización lógica del trabajo.

2. La correcta realización de las tareas necesarias y planificadas.

3. La comprobación de los logros obtenidos, y

4. La posibilidad de aprovechar y extender aprendizajes y experiencias adquiridas

a otros casos.



empresas

32

3.2.2 Análisis de valor

El análisis del valor (AV) es una técnica que trata de concebir un nuevo

producto, proceso, sistema o bien de volver a concebir un producto ya existente

de modo que, con el costo mínimo, asegure todas las funciones que el cliente

desee y esté dispuesto a pagar. En otras palabras, el Análisis del Valor trata de

extraer los costos inútiles o baldíos de un producto al mismo tiempo que intenta

mejorar su calidad, cuestionándose acerca del producto mismo en su concepción

[7].

El análisis de valor, es una metodología creada por Lawrence Miles para su

aplicación inicial en General Electric (GE). Esta metodología utilizada en un

principio por la GE fue rápidamente adoptada y adaptada a sus propias

necesidades por diversas empresas del Japón, y hoy vuelve a ser objeto de

interés por las empresas occidentales [29].

Las ventajas que proporciona la utilización de esta técnica son las siguientes [7]:

Permite realizar una reducción de los costes de un producto sin reducir la

calidad del mismo.

El análisis sistemático de las funciones del producto permite, en la mayoría

de los casos, no sólo la reducción de costes mencionada, sino además

mejorar el producto potenciando las funciones que más valora el cliente, así

como reducir las quejas.

El Análisis de valor es un instrumento de innovación ya que obliga a

encontrar respuestas técnicas u organizativas a problemas que de otro modo

nunca se hubieran planteado en la empresa.

Permite una mayor integración profesional y humana de los distintos

departamentos de la empresa, circunstancia siempre conveniente y que

trasciende de los propósitos de cada proyecto concreto en el que se aplica el

método.

El análisis de valor se enfoca principalmente en tres (3) conceptos: necesidades,

funciones y valor. [7]

Las necesidades de los consumidores son las que, en última instancia, llevan

a los individuos a adquirir un producto y, por lo tanto, constituyen la

referencia básica de concepción del producto.



empresas

33

Las funciones de un producto son las características que reúne y que

permiten al usuario ver satisfechas sus necesidades; en otras palabras,

definen por qué ese elemento ha sido realizado o comprado. Desde este punto

de vista, el consumidor no adquiere el producto por sí mismo, sino en virtud de

las funciones que le asegura

El valor en el contexto de este método, se define como la medida de las

funciones en relación a su coste o, expresado en términos matemáticos:

3.2.2.1 Objetivos y resultados del análisis de valor:

Tabla 2. Objetivos y resultados del análisis de valor [7]



empresas

34

3.2.2.2 Implantación del método de análisis de valor:

El método análisis de valor se divide en 6 fases [7]:

Fase 1. Orientación: definición del estudio y de sus objetivos;

Fase 2. Información: recogida de todos los datos relevantes para el análisis;

Fase 3. Preparación del análisis;

Fase 4. Análisis: estudio del producto en el grupo de trabajo;

Fase 5. Estudio en profundidad de las ideas elegidas;

Fase 6. Balance y conclusión, decisión y aplicación

Fase 1-Orientación: definición del estudio y de sus objetivos: La identificación

es el proceso por el cual se procede a localizar oportunidades de posibles

reducciones de costos, determinando cuál de ellas tiene el mayor potencial. La

gente tiende a acostumbrarse a su entorno, y por ello lograr detectar

oportunidades resulta difícil para la mente no preparada. Desarrollar la capacidad

de observación y percepción es el mejor antídoto para la complacencia,

manifestada generalmente mediante la frase “siempre se ha hecho así” [7]

La mejor forma de atacar la complacencia y, examinar y reexaminar los procesos,

actividades, productos, servicios y estructura organizacional, es formulando

sistemáticamente la pregunta ¿por qué? [7].

El reconocimiento de oportunidades para reducir costos requiere de los

conocimientos que sólo un especialista en administración de operaciones o un

ingeniero industrial poseen por su formación y experiencia. Los conocimientos a

los que hacemos referencia son todos aquellos relacionados con las formas

específicas de generar los bienes y servicios, identificando y analizando los

diversos tipos de costos y desperdicios que participan en los procesos [7].

Fase 2-Información: recogida de todos los datos relevantes para el análisis:

En esta segunda etapa se efectúa la recogida de cualquier tipo de datos que

pueda ser pertinente para el análisis definido en la fase anterior [7].

La duración de la fase de información depende del tipo y cantidad de los datos

disponibles y puede prolongarse durante semanas o meses [7].

Para el análisis se debe tener en cuenta un tipo de datos importante para el

análisis (ver Tabla 3. Datos importantes para el análisis [7]).



empresas

35

Tabla 3. Datos importantes para el análisis [7]

Fase 3-Preparación del análisis: Las operaciones a realizar en esta fase son las

siguientes [7] :

Clasificación y primera exploración de la información: Ésta se clasifica por

funciones y costes y se presenta a través de gráficos y cuadros que faciliten

la toma de decisiones posterior.

División del producto: Si se trata de un elemento complejo es conveniente

dividirlo en sus órganos o conjuntos funcionales, éstos en subconjuntos y a su

vez, estos en piezas unitarias. El nivel de desagregación de estas divisiones

dependerá del ámbito del análisis fijado en la fase 1.

De acuerdo con la división anterior, se delimitan de manera clara las funciones

de cada una de las subdivisiones establecidas en el apartado anterior.

Siempre que sea posible es conveniente calcular el coste de producción de

cada una de dichas subdivisiones, puesto que este factor se convertirá en uno

de los principales criterios de elección de alternativas.

Si en la fase 1 se han establecido objetivos de costes para el conjunto del

producto conviene, del mismo modo, fijar objetivos de costes para las

subdivisiones

Fase 4- Análisis: estudio del producto en el grupo de trabajo: se deberá

preparar las reuniones del equipo estableciendo las materias a tratar, el orden del

día y preparando la información necesaria para cada una de ellas. El equipo



empresas

36

someterá a examen cada función del objeto de análisis y tratará de encontrar

soluciones técnicas, organizativas, etc. y de valorar su coste. Este trabajo de

análisis suele apoyarse en técnicas que estimulan la creatividad del equipo,

destacando entre ellas la del brainstorming1 o de puesta en común [7].

De todas las ideas obtenidas y a la vista de su factibilidad técnica y de coste, el

equipo deberá efectuar una primera selección de las ideas que habrá que

someter a un análisis adicional [7].

Fase 5 - Estudio en profundidad de las ideas elegidas: El estudio en

profundidad de las ideas escogidas por el grupo de trabajo entra dentro del

marco de funcionamiento normal de la empresa y lo realizarán los

departamentos competentes: marketing, contabilidad, diseño, compras, etc. de

acuerdo con la naturaleza de cada proyecto [7].

No obstante, el responsable del análisis del valor deberá supervisar que dichos

estudios se realizan adecuadamente y en los plazos establecidos al efecto [7].

Fase 6- Balance y conclusión. Decisión y aplicación: Una vez que se han

recibido los resultados de los estudios encargados, corresponde al equipo realizar

una síntesis de todo el proceso y establecer las conclusiones [7].

En último término, corresponderá a la dirección tomar las decisiones sobre la

implantación de las alternativas elegidas. El grupo de trabajo, no obstante, deberá

aportar a los dirigentes la información necesaria para que dicha decisión sea

tomada con garantías de éxito [7].

1 Brainstorming: lluvia de ideas



empresas

37

3.2.3 Simplificación de procesos

La simplificación de proceso de trabajo reduce en lo más posible o elimina

completamente todas aquellas actividades que no le agregan valor al proceso de

trabajo y mejora todas aquellas actividades que sí le agregan valor. La

simplificación de procesos maneja dos factores que para la compañía son

sumamente importantes que son: tiempo y costo [12].

Este proceso de simplificación de procesos de trabajo agrega valor a cualquier

paso clave dentro del proceso de trabajo que contribuye directamente al logro de

una mayor satisfacción del usuario final o al mejoramiento de la eficiencia de este

proceso. Para reconocer este tipo de procesos se debe analizar el impacto que el

No realizarlo traería a la compañía, por lo general estos procesos impactan

fuertemente los resultados de la compañía. Para analizar los procesos que no

tienen valor agregado para la compañía, faltaría ver qué procesos de trabajo no

contribuyen a la satisfacción del cliente o a una mejora o simplemente que su

impacto en caso de no realizarse sea muy bajo o nulo [12].

Ya teniendo claro los procesos que agregan o no valor a la compañía, se debe

también tener claro que actividades conforman un proceso de trabajo, estas

actividades son aquellas que su labor es la transformación del bien o servicio, las

actividades que no cumplen con esta función como distribuir, inspeccionar, probar,

almacenar, entre otras son denominadas actividades auxiliares, la unión de estas

actividades cumple con un proceso que tiene un ciclo total, éste ciclo total es el

tiempo que toma completar el resultado esperado del proceso, iniciándose desde

la solicitud que el usuario realiza por un bien o servicio, hasta el recibimiento de

producto o satisfacción del servicio. Este es el tiempo que la simplificación de

procesos intentará minimizar, tratando así de realizar el trabajo menos fatigante,

reduciendo los costos relacionados con el proceso, aumentando la calidad del

producto y la eficiencia en el proceso, aumentando la productividad y logrando

finalmente la satisfacción del cliente o usuario [12].

La simplificación de los procesos de trabajo tienen unos elementos, estos son:

real, teórico y desperdicio [12].

El real es ¿cómo lo hacemos?, estos son todos los pasos que actualmente

realizamos en la ejecución de un proceso de trabajo, como deberíamos hacerlo es

el teórico que en realidad son todos los pasos que le agregan valor al resultado

esperado del proceso que ejecutamos y lo que hacemos de más es el



empresas

38

desperdicio, que son todos los pasos que no le agregan valor al resultado

esperado del proceso que se ejecuta [12].

Para implementar la metodología con la que se busca simplificar los procesos de

trabajo, se realizan 6 pasos, entendiendo que la manera actual de hacer las cosas

no es necesariamente la mejor, si hubo tiempo para hacer las cosas mal, la

compañía debería entender que debe haber un tiempo para hacerlas mejor, que el

presupuesto para mejorar el estado actual de las cosas es de vital importancia.

Teniendo esto claro se realizan los 6 pasos [12]:

Paso 1: Se realiza una lista de los pasos a realizar en un proceso de trabajo

con los tiempos asociados a la ejecución.

Paso 2: Se realiza un diagrama de flujo donde se muestre gráficamente los

pasos que agregan o no valor al proceso.

Paso 3: Se realiza un cálculo del factor de desperdicio para medir

cuantitativamente el éxito de la simplificación de proceso.

Paso 4: Se realiza un análisis de las actividades que no le agregan valor y se

les asigna una prioridad para ser eliminadas.

Paso 5: Se reduce el tiempo de las actividades que no le agregan valor, este

sería el estado ideal.

Paso 6: Se realiza una mejora en el tiempo de ejecución de las actividades que

sí agregan valor al proceso de trabajo.



empresas

39

3.2.4 Six sigma

3.2.4.1 Six sigma como filosofía de gestión

La historia de six sigma se inicia en 1986 en Motorola cuando el ingeniero Mikel

Harry comienza a estudiar la reducción en la variación de los procesos para

mejorarlos. Esta herramienta tenía una fuerte base estadística y pretendía

alcanzar unos niveles de calidad en los procesos y en los productos de la

organización próximos a los cero defectos. Constituye una metodología

sistemática para reducir errores, concentrándose en la mejora de los procesos, el

trabajo en equipo y con una gran implicación por parte de la Dirección [8].

En los años 90, Jack Welch, presidente de General Electric decidió utilizar six

sigma consiguiendo resultados económicos espectaculares. Desde entonces, six

sigma se ha convertido en una de las herramientas de mejora más utilizadas,

habiendo sido adoptada por compañías como Motorola, General Electric, Allied

Signal, Polaroid, Toshiba, Honey well, City Bank o American Express. Más

recientemente six sigma ha llegado a Europa donde numerosas empresas están

empezando a implantarla (en España, empresas como Telefónica, e-La Caixa o

Iberia) [8].

Six sigma hace referencia a un nivel de calidad capaz de producir con un mínimo

de 3,4 defectos por millón de oportunidades. Esta calidad se aproxima al ideal del

cero-defectos y puede ser aplicado no sólo a procesos industriales, sino a

servicios y, por supuesto, al proceso proyecto-construcción [8].

Esta filosofía se utiliza para eliminar los costes de no calidad (desperdicios,

reprocesos, etc.), reducir la variación de un aspecto o característica de un

producto, acortar los tiempos de respuesta a las peticiones de los clientes, mejorar

la productividad y acortar los tiempos de ciclo de cualquier tipo de proceso,

centrándose en aquellas características o atributos que son clave para los clientes

y, por tanto, mejorando notablemente su satisfacción. Para ello, la Dirección

identifica las cuestiones que más incidencia tienen en los resultados económicos y

asigna a los mejores profesionales, tras formarlos intensivamente, a trabajar en los

mismos [8].

En conclusión, six sigma se puede definir como una filosofía soportada por tres

grandes columnas: El enfoque en el cliente, para asegurar que todas las salidas



empresas

40

(del proceso) satisfagan los requerimientos y expectativas del cliente; basada en

datos, para poder identificar las entradas (al proceso), los procesos y áreas de

mejora; y finalmente, apoyada en una metodología robusta y sistemática, para

poder definir, medir, analizar, mejorar y controlar los procesos y así maximizar la

productividad del negocio, y al mismo tiempo satisfacer las expectativas del cliente

[9].

3.2.4.2 Six sigma como metodología

El proceso comienza con un “cambio radical... de actitud”. La Dirección debe ser

consciente de que la mejora continua ya no es suficiente para alcanzar los

objetivos estratégicos, financieros y operativos. La mejora radical es necesaria

para reducir con rapidez los desperdicios crónicos [8].

Los proyectos son seleccionados en función de los beneficios. La empresa six

sigma aporta una metodología de mejora basada en un esquema denominado

DMAIC (Define, Measure, Analyze, Improve, Control), el cual es análogo al

anterior modelo de TQM conocido como Ciclo Deming: PDCA [8].

3.2.4.3 Definición del proceso DMAIC

D = Definir

Definir es la primera etapa del modelo DMAIC. El propósito de la etapa Definir es

refinar el entendimiento del problema a solucionar por parte del equipo de trabajo

y definir las expectativas del cliente para el proceso [13].

Los elementos de esta etapa incluyen un enunciado específico del problema a

solucionar, enunciados descriptivos enumerando la localización y ocurrencia de

los eventos problemáticos, así como un enunciado inicial describiendo el alcance

del problema [13].

En esta etapa, el equipo de trabajo define lo que se necesita para un proyecto de

six sigma exitoso. Definir incluye identificar los clientes (internos y externos);

identificar sus necesidades y determinar el alcance del proyecto y los objetivos

[13].



empresas

41

Las preguntas a hacer en esta etapa incluyen [13]:

¿Quién es el cliente?

¿Qué es lo importante y qué es crítico para la calidad?

¿Cuál es el alcance?

¿Qué defectos estoy tratando de reducir?

¿En cuánto? ¿Cuál es la meta?

¿Cuál es costo actual de los defectos?

M = Medir

La etapa de medición establece técnicas para recolectar datos sobre el

desempeño actual y que tan bien se cumplen las expectativas del cliente. Al

terminar esta etapa, el equipo de trabajo tendrá un plan de recopilación de

información, un sistema válido de medición que asegure exactitud y consistencia

en la recolección de datos, frecuencia de los defectos y datos suficientes para el

análisis del problema [13].

Esta etapa conlleva a las siguientes preguntas [13]:

¿Cuál es el proceso?

¿Qué indicador afecta más la calidad?

¿Cuál variable del proceso parece afectar más a esos indicadores?

¿Es aceptable la habilidad para medir y detectar?

¿Cómo funciona el proceso actualmente?

¿Qué tan bueno sería mi proceso si todo corriera adecuadamente?

¿Cuál es el nivel máximo para lo que fue diseñado el proceso?

A = Analizar

La etapa de Análisis permite al equipo de trabajo establecer las oportunidades de

mejora al tener todos los datos. A través de esta etapa, el equipo determina por

qué, cuándo y cómo ocurren los defectos; selecciona las herramientas de análisis

gráfico adecuadas y las aplica a los datos recolectados y; plantea un conjunto de

mejoras potenciales para aplicarse en la siguiente etapa: Mejorar. Después de



empresas

42

analizar, el equipo puede entregar un mapa del proceso detallado, un enunciado

refinado del problema y estimados de la posibilidad de defectos [13].

Las preguntas a realizar en la etapa de Analizar incluyen [13]:

¿Qué variables del proceso afectan más la calidad y hasta qué punto?

¿Si cambio una variable del proceso realmente cambio los indicadores

resultantes?

¿Cuántas observaciones necesito para sacar conclusiones?

¿Qué nivel de confianza tengo con respecto a mis conclusiones?

I = Mejorar (del inglés Improve)

En la etapa de Mejorar, el equipo de trabajo desarrolla, implementa y valida

alternativas de mejora que rectifican el proceso. Esto consiste en hacer una lluvia

de ideas para generar alternativas de mejora, probar las soluciones propuestas

usando corridas piloto y validando la mejora. Con esto viene la creación de un

nuevo mapa del proceso para ilustrar el nuevo flujo del proceso, seguido de un

análisis de costo beneficio para asegurar que la mejora potencial es viable y

redituable. Por medio de la recopilación y análisis de los datos del nuevo proceso,

el equipo puede demostrar la validez de las mejoras. Esta etapa entrega

soluciones al problema y validación de las soluciones así como planes de

implementación y comunicación [13].

Las preguntas para la etapa de Implementar incluyen [13]:

Una vez que sé con seguridad que variables del proceso afectan mis

indicadores, ¿cómo implemento los cambios?

¿Cuántas pruebas necesito correr para encontrar y confirmar las mejoras del

procedimiento o ajuste para estas variables clave del proceso?

C = Control

La etapa de Control institucionaliza las mejoras del proceso y el producto y,

monitorea el desempeño actual a fin de obtener las ganancias logradas en la

etapa de Mejorar. Durante esta etapa el equipo de trabajo desarrolla una

estrategia de control basada en los resultados de las cuatro etapas previas, un



empresas

43

plan de control que incorpora los cambios en el proceso cronológicamente y un

enunciado de calidad de desempeño actualizado y un plan de entrenamiento para

documentar los cambios y mejoras [13]:

Las preguntas a realizar en la etapa de Control incluyen [13]:

Una vez reducidos los defectos, ¿cómo pueden los equipos de trabajo y yo

mantener los defectos controlados?

¿Qué se debe preparar para mantener el desempeño satisfactorio aun cuando

las cosas cambien (gente, tecnología y clientes)?

Las claves del DMAIC se encuentran en [8]:

Medir el problema. Siempre es necesario tener una clara noción de los

defectos que se están produciendo, tanto en cantidad como en coste.

Enfocarse al cliente. Sus necesidades y requerimientos son fundamentales, y

deben tenerse siempre en consideración.

Verificar la causa raíz. Es necesario llegar hasta la causa fundamental de los

problemas, y no quedarse en los efectos.

Romper los malos hábitos. Un cambio verdadero requiere soluciones creativas.

Gestionar los riesgos. La prueba y el perfeccionamiento de las soluciones es

una parte esencial de six sigma.

Medir los resultados. El seguimiento de cualquier solución significa verificar su

impacto real.

Sostener el cambio. La clave final es conseguir que el cambio perdure.

La metodología DMAIC hace mucho énfasis en el proceso de medición, análisis y

mejora y no está planteada como un proceso de mejora continua, pues los

proyectos six sigma deben tener una duración limitada en el tiempo. Los proyectos

six sigma surgen bajo el liderazgo de la Dirección, quien identifica las áreas a

mejorar, define la constitución de los equipos y garantiza el enfoque hacia el

cliente y sus necesidades y a los ahorros económicos. Sin embargo, antes de que

un equipo six sigma aborde el ciclo de la mejora, han de desarrollarse una serie de



empresas

44

actividades necesarias para el éxito del proyecto: (1) identificación y selección de

proyectos, (2) constitución del equipo, (3) definición del proyecto, (4) formación de

los miembros del equipo, (5) ejecución del proceso DMAIC y (6) extensión de la

solución [8].

3.2.5 Business process reengineering (BPR)

Para entender mucho mejor la metodología „Reingeniería de procesos de

Negocio‟, del inglés Business Process Reengineering (BPR), es importante aclarar

el siguiente término clave: „Reingeniería‟, el cual se define como:

El rediseño de un proceso en un negocio o un cambio drástico de un proceso. [30]

Para que una empresa adopte el concepto de reingeniería, tiene que ser capaz de

deshacerse de las reglas y políticas convencionales que aplicaba con anterioridad

y estar abierta a los cambios por medio de los cuales sus negocios puedan llegar

a ser más productivos. [30]

Una definición rápida de reingeniería es "comenzar de nuevo". [30]

Actualmente la definición más aceptada fue la dada por Hammer y Champy en

1993, donde definen reingeniería como:

“El replanteamiento fundamental y el rediseño radical de los procesos de negocio

para alcanzar mejoras dramáticas en medidas críticas y contemporáneas de

rendimiento, tales como costos, calidad, servicio y rapidez” [15]

En la definición anterior planteada por Hammer y Champy existen cuatro palabras

claves: Fundamental, radical, dramáticas y procesos. [15]

Estas palabras son claves debido a que: [30]

Una reingeniería buscará por qué se está realizando algo fundamental.

Los cambios en el diseño deberán ser radicales (desde la raíz y no

superficiales).

Las mejoras esperadas deben ser dramáticas (no de unos pocos porcentajes).

Los cambios se deben enfocar únicamente en los procesos.



empresas

45

Se puede decir que una reingeniería es un cambio dramático en el proceso y que

como efecto de esto se tendrá un rompimiento en la estructura y la cultura de

trabajo. [30]

Sin embargo, la reingeniería de procesos es radical hasta cierto punto, ya que

busca llegar a la raíz de las cosas, no se trata solamente de mejorar los procesos,

sino principalmente, busca reinventarlos, con el fin de crear ventajas competitivas

osadas, con base en los avances tecnológicos. [31]

Las etapas de la reingeniería pueden ser las siguientes: [31]

Identificación de los procesos estratégicos y operativos existentes o

necesarios, y creación de un mapa (un modelo) de dichos procesos.

Jerarquización del mapa de procesos para su rediseño, y determinación de los

procesos clave, aquellos que se abordarán primero o con mayor interés.

Desarrollo de la visión de los nuevos procesos mejorados.

Reingeniería (creación y rediseño) de procesos, realizada por consultores

externos, especialistas internos, o una mezcla de ambos.

Preparación y prueba de los nuevos procesos (procesos pilotos).

Procesos posteriores de mejora continua.

3.2.6 Business process management (BPM)

3.2.6.1 ¿Qué es BPM?

Después de muchos años tratando el tema de mejoramiento de procesos se llegó

al concepto de BPM nacido en la tercera ola de la era de la información, donde se

le dieron diversas definiciones al término BPM, entre las más destacadas están

[10]:

El BPM o gestión de procesos de negocio es un conjunto de técnicas,

actividades y tareas, bajo un Enfoque Metodológico o Metodología, con el fin

de gestionar los procesos de negocio [10].



empresas

46

Business Process Management (BPM) es un conjunto de métodos,

herramientas y tecnologías utilizados para diseñar, representar, analizar y

controlar procesos de negocio [10].

Según KHAN Rashid, BPM es la disciplina para modelar, automatizar,

gestionar y optimizar procesos de negocio para incrementar la rentabilidad [10].

Smith Howard por su parte, define BPM como una nueva aproximación para

abordar y gestionar procesos de innovación en las compañías que construye el

mejoramiento, a partir del estado actual de un proceso en un momento

determinado y que plantea una diferencia radical frente a la reingeniería; la

cual construye el mejoramiento desde la redefinición total del proceso. En esta

óptica BPM se convierte en una respuesta al caos operativo que presentan las

compañías en la actualidad [10].

“La consecución de los objetivos de la organización a través de la mejora, la

gestión y el control de los procesos esenciales del negocio” [16]

3.2.6.2 ¿Qué no es BPM?

BPM no es un workflow, es mucho más [10].

BPMS no es un aplicativo orientado a solucionar determinada casuística, es

una solución mucho más genérica que nos permite modelar y poner en

producción de una manera ágil y sencilla cualquier proceso de nuestra

organización [10].

BPM no es una herramienta de desarrollo de aplicaciones [10].

Una vez entendido el concepto de que es BPM y que NO ES BPM se debe

recalcar que el camino para llegar a BPM no ha sido fácil, ya que se ha sacado lo

mejor tanto de los éxitos como de los fracasos vividos por parte de los diversos

intentos de lograr un proceso basado en la eficiencia organizacional, dando como

resultado un concepto expresado de manera clara en la Grafica 4



empresas

47

Grafica 4: BPM: The third wave [11]

En la ilustración anterior se puede observar que BPM es el resultado final de las

experiencias obtenidas de cada metodología, en el momento de un pensamiento

enfocado a los procesos su antecesor fue la reingeniería de procesos, en la

automatización se toma como base el workflow o flujos de trabajo y en el

pensamiento enfocado a la calidad, sus principales antecesores son TQM (total

quality management), ISO, six sigma.

3.2.6.3 Importancia del BPM

BPM es de gran importancia ya que permite modelar la arquitectura empresarial

orientándola a procesos, automatizando cada uno de ellos de principio a fin y

estableciendo las metodologías necesarias para su monitorización y control.

Frente a una organización tradicional en la que los sistemas están centrados en

los datos, se evoluciona con el enfoque BPM hacia unos Sistemas centrados en

Procesos de Negocio que son modelados mediante workflows[10].

La implantación de BPM permite aprovechar las infraestructuras y sistemas

existentes, de forma totalmente integrada, minimizando el impacto económico de

los cambios. La agilización de procesos y reducción de costos mediante BPM se



empresas

48

obtienen desde el primer momento, permitiendo monitorizar el negocio y detectar

cualquier problema en la gestión empresarial, el ajuste a las métricas establecidas

y el cumplimiento de los parámetros de Calidad [10].

Cambios de estrategia empresarial en una organización con BPM pueden ser

ejecutados de forma inmediata sin implicar necesariamente nuevas inversiones en

tecnología y permitiendo aplicar la reingeniería de procesos con un impacto

mínimo en la Organización. BPM consigue que las Organizaciones, lejos de

quedar atrapadas en una rigidez limitada por su propia tecnología, puedan

renovarse, alcanzando el dinamismo necesario que los nuevos tiempos exigen

[10].



empresas

49

4. IDENTIFICACIÓN DE LAS DIFERENCIAS ENTRE BPM Y ANTECESORES

Los dos antecesores inmediatos y más significativos de BPM, fueron los que

surgieron a partir del trabajo de Schewhart y Deming sobre el control estadístico

de procesos que llevaría al desarrollo del movimiento moderno de control y gestión

de la calidad (Ciclo PDCA) que evolucionaría hacia el TQM (Primera Ola de la era

de información) en los años 80 y posteriormente al six sigma.

Y la reingeniería de procesos (BPR) (Segunda Ola), de los años 90 la cual se

centra en el diseño de procesos más que en la ejecución de los mismos (en lo que

se centra la calidad) y establecía que el rendimiento de un proceso venía

determinado por su diseño, si el rendimiento exigido a un proceso es mayor de lo

que el diseño del mismo permite debe ser sustituido por otro.

4.1 BPM vs TQM

4.1.1 Similitudes y diferencias

Analizando las definiciones de TQM y BPM, son increíbles las similitudes en el

ámbito de ambas áreas. Ambos tienen en su corazón la gestión de procesos de

negocio. TQM explícitamente busca asegurar la continua satisfacción del cliente

(junto con otros factores de negocio internos) a través de una mejor planificación,

mejora y control de los procesos de negocio. El Enfoque de BPM en los primeros

años fue centrado en los procesos dinámicos, por ejemplo, la agilidad y la

flexibilidad habilitadas por la tecnología. En la actualidad, el enfoque de BPM se

ha ampliado para centrarse en los objetivos de la organización a través de una

mejor gestión de los procesos de negocio. En nuestra definición de calidad total,

nos encontramos con diferencias significativas. Además de la gestión de procesos

básicos, los principios de calidad también se centran en los procesos y sistemas

de trabajo en otras áreas claves de liderazgo, gestión estratégica, los clientes y

mercados, la información y el conocimiento y la gestión de las personas con un

énfasis que corresponde a los resultados obtenidos por la empresa en estas

áreas. BPM sin embargo, sigue siendo en gran medida quien predomina en la

comunidad de las TI. TQM y técnicas afines residen en el dominio de calidad, y en

varias organizaciones, estas iniciativas son a menudo conducidas por procesos

independientes [6].



empresas

50

BPM recomienda el modelado de procesos como un enfoque para el proceso de

documentación con suficiente rigor en el modelado de procesos y análisis

mediante el uso de las herramientas y los métodos estructurados. Además, el uso

apropiado de la tecnología BPM ayuda en un rápido y acertado análisis de los

procesos lo cual es particularmente ventajoso en el análisis de procesos amplios y

complejos. Por otro lado, en el modelo de TQM, los procesos se asignan y

documentan mediante métodos simples, como los diagramas de flujo con cuatro

(4) –cinco (5) símbolos, que están menos estructurados. El Análisis de procesos

se suele hacer de forma manual, aunque hay varias herramientas utilizadas para

dicho análisis de datos, tales como six sigma. Los Mapas de procesos en este

modo son más fáciles de entender y más útiles para un público más amplio,

especialmente para los usuarios de negocios no técnicos [6].

La mejora de procesos en TQM depende de todos o algunos de estos elementos:

la mejora basada en el análisis de los datos (que van desde altamente cualitativo

hasta cuantitativo como lo es el enfoque en six sigma), los enfoques de causa-

raíz, BPR, y con la ayuda y el apoyo de la tecnología apropiada. El paradigma

BPM adopta el rediseño de procesos y lo mejora desde un ángulo global utilizando

métodos adecuados, herramientas y tecnología [6].

En el lenguaje de TQM, el control del proceso implica el uso de herramientas

estadísticas, planificación y construcción de controles adecuados en los procesos

(manuales o habilitados por la tecnología). En BPM, el seguimiento y control de

procesos recibe mucho mayor énfasis, ya que la tecnología BPM cuenta con una

gran capacidad para controlar y monitorear los procesos [6].

4.2 BPM vs Six sigma

Para un correcto entendimiento de las diferencias y similitudes entre six sigma y

BPM se debe enfocar en dos aspectos diferentes, como lo son:

Una comparación general

Una comparación de la mejora de procesos planteada por cada metodología.



empresas

51

4.2.1 Comparación general

En la siguiente tabla se muestra un cuadro comparativo entre BPM y Six Sigma

Tabla 4. BPM Vs Six sigma [17]

metodologías

evaluación

Six sigma– Centrado en el Análisis

BPM – Centrado en la automatización y

optimización

Enfoque Estrategia analítica para la generación de valor económico a través de la mejora de procesos

Entorno de automatización y optimización para la generación de valor económico a través de la mejora de procesos

Datos Aprovecha el análisis estadístico de los indicadores clave para identificar oportunidades de mejora

Accede a los datos de los sistemas empresariales para permitir el análisis estadístico

Diseño de mejoramiento del

proceso

Mejoras en los procesos adquiridas a través del enfoque en el análisis causa-raíz.

Cambios en el sistema logrados mediante la colaboración con las IT

Proporciona un entorno de diseño visual usado para definir gráficamente el flujo del proceso y las interacciones personas / sistema

Ejecución del mejoramiento del

proceso

Documento recomendando cambios y técnicas de medición

Proceso mejorado automatizado e integrado con las actuales inversiones en IT

Medición Las medidas de control graficas continúan las tendencias de los indicadores claves

Las medidas de los marcadores continuaron las tendencias de los indicadores y el valor de impacto para el negocio.



empresas

52

4.2.2 Una comparación de la mejora de procesos

Como se mencionó anteriormente, six sigma se apoya en una rigurosa

metodología (DMAIC) que utiliza herramientas y métodos estadísticos, para

DEFINIR los problemas y situaciones a mejorar, MEDIR para obtener la

información y los datos, ANALIZAR la información recolectada, INCORPORAR y

emprender mejoras al o a los procesos y finalmente, CONTROLAR o rediseñar los

procesos o productos existentes, con la finalidad de alcanzar etapas óptimas, lo

que a su vez genera un ciclo de mejora continua [17].

En la gráfica 5, se puede observar una comparación entre lo que propone la

metodología DMAIC de six sigma y la 7FE Framework de BPM.

Grafica 5: 7FE Framework (BPM) Vs DMAIC (Six sigma)[11]



empresas

53

4.3 BPM vs BPR

En la siguiente tabla se mostrara un análisis comparativo entre las metodologías

BPM y BPR.

Tabla 5. BPM Vs BPR [32]

Se pudo observar que BPM es una metodología de implementación incremental,

por lo cual se disminuye el riesgo de fracaso en las compañías porque permite

generar un propio nivel de aprendizaje en el grupo encargado del desarrollo e

Aspecto

Evaluación

BPR – Borrón y cuenta nueva (Obsolencia y

desecho)

BPM – Mejora a través de la automatización y

optimización.

Nivel de Cambio Radical, cambio en un paso

Evolutivo y continuo

Tiempo Requerido para la

implementación

Mucho tiempo ( 6 – 24 meses)

Poco tiempo y fácil de hacerse cargo ( 3 – 4 meses)

Punto de partida Tablero de dibujo Procesos actuales y niveles de automatización

Implementación Gran esfuerzo necesario para el cambio disruptivo

(ruptura brusca)

Incremental

Extensión Un proceso principal a la vez

Flexible – simultáneamente trata uno o muchos /

procesos principales o pequeños

Metodología Rediseño de los procesos de negocio.

Procesos y modelos de decisión

Tecnología que lo habilita

Principalmente las IT Principalmente la tecnología de proceso

Participación Expertos en negocios y en procesos

Expertos en procesos y todas las personas

relacionadas

Riesgo Alto Bajo

Resultado Drástico Mejora incremental

Dinero Grandes cifras de capital Inversión en capacitación

Orientación A la tecnología A las personas y procesos

Tecnología EAI/workflow BPMS/BRE

Metodología de implementación

Cascada/SDLC Agile/RAD



empresas

54

implementación de este tipo de proyectos en la empresa, esto también implica

observar los resultados de manera más pausada, permitiendo a los gerentes y

administradores de los procesos de negocio corregir y mejorar la manera en que

se implementa, logrando finalmente una satisfacción al usuario final del proceso.

Otra ventaja de BPM sobre las empresas, es el soporte tecnológico que se brinda,

los sistemas y motores de procesos que soportan BPM permiten al usuario final

crear procesos de negocio simulados, ofreciendo métricas y tiempos muy

cercanos a la realidad del desempeño que tendría una implementación del

proceso, permitiendo que el usuario este seguro de los cambios que desea

realizar en la compañía, argumentando su decisión [32].

Se puede concluir que BPM finalmente es la reunión de las mejores prácticas que

la experiencia pudo extraer de cada metodología que se enfoca en los procesos

de negocio, unificando trabajo y esfuerzo con el personal de TI, que finalmente

generara un soporte para el eficiente y eficaz desempeño de los procesos de

negocio de la compañía generando así valor agregado para aquellas compañías

que decidan implementar un proyecto BPM en sus empresas.



empresas

55

5 COMUNIDADES ALREDEDOR DE BPM

En el siguiente capítulo se presentaran los resultados de una investigación de las

comunidades mundiales que enfoquen su investigación y desarrollos en BPM.

Si se requiere mayor información para ampliar la investigación acerca de BPM,

sus nuevos enfoques, implementaciones exitosas y avances en sus herramientas

tecnológicas, cabe resaltar que la información presentada a continuación ha sido

tomada de los sitios web respectivos de cada comunidad.

5.1 Club-BPM

http://www.club-bpm.com

El Club-BPM nace con el objetivo de promocionar,

difundir y dinamizar el BPM (Business Process

Management - Gestión de Procesos de Negocio-) y los

BPMS (Business Process Management Systems) a todo

el tejido empresarial y a la Administración Pública, en

España y Latinoamérica, a través de múltiples actividades de formación y

„evangelización‟ tecnológica.

El Club–BPM, centro de referencia y de formación oficial del BPM en España y en

Latinoamérica, organiza seminarios, conferencias y eventos para difundir e

intensificar el conocimiento del Business Process Management y las tecnologías

BPM. En el terreno de la formación, la cual es clave para directivos y

profesionales, organiza e imparte un conjunto de cursos presenciales y online

adaptados a la situación actual de mercado, que se irán ampliando y

especializando de acuerdo a la evolución y madurez del mismo.

Misión:

Promover, difundir y enseñar BPM y los BPMS, dinamizando así el mercado de

estas tecnologías, estándares y enfoques metodológicos en el tejido empresarial y

Administraciones Públicas en España y Latinoamérica. Además de su carácter de

club, de centro de encuentros, actúa como centro de enseñanza oficial, de

investigación y desarrollo y de apoyo a empresas y organismos para que éstas

puedan formarse en BPM, reciban información analizada del mercado y dispongan

http://www.club-bpm.com/



empresas

56

de servicios que le ayuden a abordar proyectos BPM junto con nuestros miembros

ejecutivos. Mediante su Observatorio analiza el mercado BPM siendo el principal

proveedor de inteligencia de mercado de referencia clave en el mercado Español y

los países de Latinoamérica.

Objetivos:

Los principales objetivos son:

Difundir y promover la implantación y evolución del BPM.

Velar por la imagen y prestigio del BPM, difundiendo con total claridad los

fundamentos del mismo, así como los resultados de su implantación y

desarrollo en el mercado nacional e internacional.

Impulsar la colaboración entre miembros y promover iniciativas de implantación

de BPM.

Colaborar con los poderes públicos en el desarrollo, implantación y

reconocimiento del BPM.

Coordinar actividades, actos, investigaciones y actividades relacionadas con el

BPM, para su implantación, adopción y desarrollo.

Promover y participar en estudios e investigaciones de BPM, y asesoramientos

de asociados y terceros.

Formar a todos aquellos directores, responsables y profesionales que desean o

requieran iniciarse y especializarse en BPM y sus tecnologías, a través de

formación presencial, formación a distancia y formación universitaria

Analizar el mercado BPM para ser un observatorio de referencia.

5.2 BPM-forum (paises bajos)

http://www.bpm-forum.org/pageflow/default.asp?pageid=37&nt=2

El BPM-Foro países bajos es la plataforma

neutral e interdisciplinaria para

profesionales BPM en los países bajos. Su

objetivo es la facilitación de una comunidad

BPM donde las creencias y los

desacuerdos pueden ser alojados y ampliamente aceptados a través del




empresas

57

intercambio de experiencias, conocimientos y las "mejores prácticas" en gestión

de procesos de negocio.

Objetivos:

El BPM-FORUM (NEDERLAND): tiene como objetivo estimular la aplicación del

pensamiento BPM así:

Comparte el conocimiento de experiencias sobre la aplicación de BPM

Profesionales BPM, junto a una red de calidad

Sirve de enlace con otras organizaciones que pueden contribuir a este objetivo

y, cuando proceda, en cooperación con estas organizaciones a tomar

iniciativas que contribuyan a lograr el objetivo

Realiza diversas actividades. Es la plataforma central para el intercambio de

experiencias prácticas. Este intercambio se basa principalmente en reuniones

cara a cara: los profesionales de BPM y otras partes interesadas se reúnen en

las diversas formas de reuniones.

Miembros:

Los miembros del foro son profesionales activos como vendedores, consultores,

analistas, científicos, y el usuario final en el vasto dominio de gestión de procesos

de negocio. El bi-mensual de práctica orientada a las reuniones contribuyen a una

mejor comprensión de BPM, ofreciendo presentaciones de casos de usuario, la

armonización de estos casos con el conocimiento de BPM y la creación de redes

para Profesionales BPM

5.3 BPTrends

http://www.bptrends.com/index.cfm

La misión es proporcionar una principal

fuente de noticias e información sobre todos

los aspectos del cambio en los procesos de

negocio centrado en las tendencias, orientaciones y buenas prácticas. Hoy las

tendencias de procesos de negocio son:

Educar y soportar el mercado: esto incluye proveedores de software y

hardware, compañías de consultoría, usuarios, organizaciones de

estandarización y otros proveedores de servicio.




empresas

58

Comunicar y cambiar información: acerca de lo que hacen los usuarios, cuáles

tecnologías están desarrollando y entregando los proveedores y cuáles

metodologías están trabajando y que tendencias y estándares están

emergiendo.

Unión y cooperación

Estandarización y suporte de las mejores prácticas: acerca de todos los

segmentos del mercado en Business Process.

5.4 Association of business process management professionals

(Asociación de profesionales en BPM)

Http://www.abpmp.org

Es una asociación internacional de

profesionales en BPM sin ánimo de

lucro, independiente a los proveedores;

es una organización dedicada a los

avances en conceptos y prácticas de BPM

Misión:

Participar en actividades que muestren avances en las practicas BPM

Promover y evolucionar un conocimiento en común en esta categoría

Fomentar el desarrollo y avance de las habilidades y competencias de los

profesionales que trabajen en estas disciplinas.

La validación de los títulos profesionales y certificaciones de los profesionales

en BPM

5.5 Workflow management coalition (WFMC)

http://www.wfmc.org/

Fue fundado en 1993, esta

organización es una

organización global de

desarrolladores, consultores, analistas, investigadores universitarios y grupos que

participan en workflow y BPM. WFMC crea y contribuye a los estándares

relacionados con procesos, educa el mercado en temas relacionados y es la

única organización que se concentra solo en el proceso. El WFMC creó WF-XML

y XPDL, lenguajes de procesos lideres hace algún tiempo.

http://www.abpmp.org/




empresas

59

La WfMC tiene más de 300 organizaciones afiliadas en todo el mundo, que

representan a todas las facetas del flujo de trabajo, de proveedores a los usuarios,

y de los académicos a los asesores. Un valor fundamental de la WfMC es:

"interoperabilidad". Uno de los factores en una experiencia de usuario

positiva para los consumidores de tecnologías de flujo de trabajo es saber

cuándo dos o más productos son susceptibles de trabajar unos con otros.

Declaración de Misión.

Aumentar el valor de los clientes con las empresas de inversión de

tecnología de proceso.

Disminuir el riesgo del uso de BPM y de flujo de trabajo productos a través

de normas de interoperabilidad.

Ampliar el mercado de BPM a través de aumentar la conciencia del valor

comercial de gestión de procesos

5.6 Object management group (OMG)

http://www.omg.org

La misión de la OMG es el desarrollo con miembros

mundiales, realizando una integración de

estándares empresariales que proveen valor al

mundo real. La OMG está también dedicada a promover tecnologías de negocios

y a la optimización y la innovación a través de una iniciativa de negocio ecológica

(BEI) y el programa de comunidades asociados a esta práctica.

OMG ha sido una organización internacional sin ánimo de lucro, consolidada en

la industria computacional desde 1989, la realización de estándares de

integración empresarial para una amplia gama de tecnologías incluyendo: tiempo

real, sistemas especializados y embebidos, análisis y diseño, modernización de

arquitectura dirigida en industrias tales como: integración y modelización de

negocios, C4I, finanzas, gobierno, salud, cumplimiento legal, ciencias de la

investigación, tecnología manufacturera, robótica, software basado en

comunicaciones y espacio.

http://www.omg.org/



empresas

60

5.7 BPM Chile

http://www.bpmchile.org/

Misión:

Difundir la disciplina de Business Process

Management en Chile, fomentar la

discusión y ser un punto de encuentro para establecer vínculos entre la industria y

la academia para la transferencia del conocimiento.

Visión:

La colaboración entre académicos, gerentes, consultores, ingenieros y estudiantes

generará la sinergia necesaria para la transferencia eficiente y efectiva del

conocimiento en pro del desarrollo de chile.

Objetivos:

Mediano plazo:

Convertirnos en el principal centro BPM del país. Extender nuestros lazos con

organizaciones de BPM y áreas afines de Chile y Latinoamérica o hispano-

parlantes.

Largo plazo

Ser los pioneros y líderes en Chile en la difusión de la disciplina y lograr el

desarrollo e investigación en la academia con una estrecha relación con la

industria. Convocar, contribuir y estimular la principal comunidad de expertos BPM

de Chile y Latinoamérica




empresas

61

5.8 BPM

http://www.bpm.com/

Por 5 años, bpm.com ha sido uno de los

primeros destinos para artículos, noticias,

investigaciones y papers de BPM y

workflow. BPM es un proceso central

enfocado al manejo de las operaciones de negocio, evolucionando en las

anteriores tecnologías y prácticas que incluyen la reingeniería de procesos de

negocio, la administración del flujo de trabajo y la gestión de la documentación.

Actualmente con la llegada de motores sofisticados de procesos y en control de la

infraestructura, BPM viable para las empresas mundiales y uno de las más

emocionantes oportunidades de negocio actuales. Todo el ciclo de vida de un

proceso de negocio puede ser ahora manejado a través de BPM, creando uno de

los más rápidos crecimientos en el mercado de los servicios y la tecnología, es

por esto que consideran que Bpm.com será reconocido como una reconocida

fuente de ventajas competitivas, por cerca todas las medianas y grandes

empresas, también creen que como la organización implementara BPM

determinara una escala y naturaleza de potenciales ventajas.

5.9 BPM –Spain

http://www.bpm-spain.com/tipologia.php?id=15

5.10 BPM Insitute

http://www.bpminstitute.org/

http://www.bpm.com/





empresas

62

Finalmente, al realizar la investigación de todas las comunidades de BPM nos

pudimos dar cuenta que existen muchos tipos de comunidades, algunas muy

generales, algunas muy específicas, pero notablemente se puede observar que es

un tema extenso y que está creciendo exponencialmente.

Una de las comunidades más fuertes en Colombia, en Latinoamérica y en general

en países de habla hispana es Club-BPM esta comunidad está encargada de

capacitar analistas de procesos en BPM, y tiene algunos convenios con las

empresas de suites BPM para la capacitación de los mismos, la mayoría de su

contenido está en español lo que facilita la comunicación entre participantes de la

comunidad, es importante resaltar que el acceso al contenido publicado en esta

comunidad es gratis.

Otra de las comunidades más importantes a nivel mundial es BPM Institute, este

es el referente de muchas grupos especializados en procesos de negocio y de

analistas de procesos, aquí se encuentra información importante de las suites

BPM libres y licenciadas y de las mejores prácticas o nuevas prácticas para la

implementación de BPM en diferentes tipos de empresas.



empresas

63

6. ESTUDIO COMPARATIVO DE METODOLOGÍAS Y FRAMEWORKS

ENCONTRADOS

Durante la investigación de los frameworks más usados para implementar un

BPM en las empresas, se encontró que existen dos (2) diferentes tipos de

enfoque; el primero basado principalmente en la parte administrativa del proyecto

y el segundo en la parte técnica del proceso como tal.

Con el fin de desarrollar un framework ágil, fácil de implementar, eficiente y

concreto se decidió hacer un análisis minucioso de tres (3) frameworks, dos (2) de

ellos con enfoque administrativo y el restante con enfoque técnico, esto con la idea

de extraer las características más sobresalientes de cada uno, asociarlas y

validarlas en un ambiente controlado.

Los frameworks con el enfoque administrativo son:

Business Process Management - Practical Guidelines Successful

Implementations, que recibe el nombre de 7FE Project Framework [16],

IBM Business Process Management Prescriptive Guide to Solution

Implementation [33]

El framework con enfoque técnico (BPMN Framework) es el que propone el libro

de BPMN 2.0 - Manual de referencia y guía práctica [20].

Dichas metodologías serán ampliamente explicadas a continuación:

6.1 Framework 7FE project

La información presentada a continuación fue extraída y traducida del libro

Business Process Management –Practical Guidelines Successful Implementations

de John Jeston and Johan Nelis

Al framework se le dio el nombre de “7FE Project Framework” donde las 4 „F‟ se

refieren a la agrupación de las diez (10) fases y las 3 „E‟ se refieren a los tres (3)

elementos esenciales.



empresas

64

La agrupación de las diez (10) fases distribuidas en las 4F es así:

Las fases de estrategia organizacional, arquitectura del proceso y plataforma de

lanzamiento hacen parte de la PRIMERA F: Foundations (Cimentos)

Las fases de entender e innovar hacen parte de la SEGUNDA F: Findings and

Solutions (Resultados y soluciones)

Las fases de personas, desarrollar e implementar hacen parte de la TERCERA F:

Fulfillment (Cumplimiento)

Las fases de obtener valor y rendimiento sostenible hacen parte de la CUARTA F:

Future (Futuro)

Grafica 6: Framework 7FE [11]

Los proyectos suelen comenzar con la fase de “Plataforma de Lanzamiento”

donde se selecciona una unidad de negocio para el mejoramiento del negocio, o

se determina que es necesario, el proyecto es enfocado, establecido e iniciado.

Cada fase del framework contiene una serie de pasos que proporcionan un

detallado, estructurado pero flexible planteamiento de la implementación de un

proyecto BPM. Los pasos del framework no solo muestran cómo las tareas de

cada fase son completadas, también proporciona un entendimiento de cómo se

interrelacionan las fases.



empresas

65

6.1.1 Fase de estrategia organizacional

El propósito de esta fase no es descubrir cómo desarrollar una estrategia

organizacional, pero si describir como la estrategia organizacional, la gestión de

procesos y los procesos individuales se relacionan e interactúan.

Es decir, alinear los proyectos BPM con la estrategia organizacional.

6.1.1.1 Salidas de esta fase

Los entregables de la fase de estrategia organizacional son entradas importantes

en la siguiente fase, arquitectura del proceso, e incluye lo siguiente:

1. Una versión documentada de la organización:

Visión

Misión

Metas

Objetivos

Estrategia de implementación

2. Un contexto o modelo de negocios, que incluye lo siguiente:

Clientes (tipo y volumen de clientes)

Servicios/Productos

Proveedores/Socios

Diferenciadores claves

Recursos

3. Diferenciadores claves de la organización.



empresas

66

6.1.1.2 Pasos

Grafica 7: Pasos de la fase de estrategia organizacional [16]

Paso 1: Analizar aspectos internos y externos de la organización.

Paso 2: Tomar decisiones estratégicas

Paso 3: Determinar impacto de procesos

Paso 4: Establecer medidas estratégicas

Paso 5: Completar el plan

Paso 6: Cierre de sesión y comunicación.

6.1.1.3 Salidas a otras fases:

Los resultados de esta fase son de gran importancia para las siguientes fases:

Arquitectura del proceso

Plataforma de lanzamiento

Innovar

6.1.2 Fase de arquitectura del proceso

En una buena arquitectura del proceso se debe asegurar que:

Los procesos a ser rediseñados o recién desarrollados, estén cumpliendo con

los objetivos de la organización y se ajusten a la estrategia organizacional.

Los procesos están alineados con la forma en la que se realiza el negocio, y

sean capaces de ofrecer los productos/servicios a los clientes.



empresas

67

Los procesos están alineados con la arquitectura IT y las aplicaciones.

La información relevante y decisiones en procesos debe estar agrupada, pues

esta información se encuentra dispersa en toda la organización, lo que puede

llevar a información duplicada.

6.1.2.1 Salidas de esta fase:

Una documentada y entendida arquitectura del proceso

Una arquitectura de inicio del proyecto

Una vista del proceso de la organización

Una lista de procesos fin-a-fin.

Información a tener en cuenta en esta fase:

El escenario BPM

La madurez de la organización en arquitectura

El alcance y el enfoque de la arquitectura.

6.1.2.2 Pasos:

Grafica 8: Pasos Fase de Arquitectura del proceso [16]

Paso 1: Obtener información estratégica y de negocios

Paso 2: Obtener guías de procesos y modelos

Paso 3: Obtener IT principios y modelos



empresas

68

Paso 4: Consolidar y validar

Paso 5: Comunicaciones

Paso 6: Aplicar arquitectura

Paso 7: Hacer mejoras


Esta fase presenta entregables que pueden ser de gran utilidad para las siguientes

fases:

Plataforma de Lanzamiento

Entender

Innovar

Obtener Valor y,

Retroalimenta la fase de Estrategia organizacional.

6.1.3 Fase de plataforma de lanzamiento

Puede que las organizaciones conozcan sus ineficiencias operacionales y

problemas de una unidad de negocio en particular, pero como y donde empezar

un proyecto BPM es una decisión difícil.

La plataforma de lanzamiento es donde los proyectos BPM son enfocados,

establecidos y lanzados con el fin de que sean un éxito; esto incluye: Enfoque del

proyecto, selección del equipo del proyecto, expectativas de los stakeholders,

establecidas y comprometidas, metas iniciales del proceso, visión y objetivos del

proyecto BPM seleccionado.


Definición de stakeholders involucrados o asociados con el proyecto.

Participación y compromiso de los stakeholders, documentación y expectativas

acordadas.

Matriz de selección de proceso.



empresas

69

Una lista de los procesos de negocio identificados y métricas iníciales.

Una lista de los objetivos del proceso acordados

Priorización de procesos para la “Fase de Entendimiento”.

Una estrategia de implementación inicial.

Gestión de Proyectos

Proyecto elegido documentado

Alcance del proyecto documentado

Borrador Inicial del plan de proyecto

Determinación y documentación de la estrategia de comunicaciones

inicial

Análisis de riesgo Inicial.

Desarrollo del caso de negocio Inicial

6.1.3.2 Pasos:

Grafica 9: Pasos de la fase de plataforma de lanzamiento [16]


Paso 2: Entrevistas iniciales a los stakeholders

Paso 3: Recorrido de proceso de alto nivel

Paso 4: Compromiso e identificación de stakeholders



empresas

70

Paso 5: Talleres ejecutivos #1 y #2

Paso 5.1: Definir alcance del proyecto

Paso 5.2: Identificar objetivos del proceso

Paso 5.3: Lista de verificación

Paso 5.4: Lista de procesos de Extremo a extremo

Paso 5.5: Identificación de procesos de negocio

Paso 5.6: Analizar los procesos de negocio

Paso 5.7: Aceptar salidas para la fase de ENTENDIMIENTO

Paso 6: Aceptar y entregar plan de negocios

Paso 7: Desarrollar plan de implementación.

Paso 8: Desarrollar/Terminar caso de negocio

Paso 9: Definir y establecer la arquitectura del equipo del proyecto.

Paso 10: Completar plan del proyecto inicial.


Entendimiento

Innovar

Implementar

Obtener Valor

Rendimiento Sostenible.

6.1.4 Fase de entendimiento

El propósito de la fase de entendimiento es hacer que los miembros del equipo

del proyecto y el negocio obtengan entendimiento suficiente de los procesos de

negocios actuales para que la fase de “Innovar” pueda comenzar. Esto incluirá la



empresas

71

colección de métricas apropiadas para ganar más entendimiento, estableciendo

priorización para innovación/rediseño, y línea de base del estado actual.

El punto crucial es que el equipo del proyecto y de negocios estén tratando de

comprender los procesos actuales- no es documentarlos con absoluto detalle. Una

vez que el proceso este claramente documentado y comprendido, DETÉNGASE:

Esto es suficiente detalle.


Modelos de procesos de los procesos actuales.

Métricas adecuadas y suficientes para establecer una base para mejorar en

el futuro medición, priorización y selección del proceso, en la fase de

innovación.

Medir y documentar los actuales niveles de rendimiento.

Documentar que trabaja bien y que podría trabajar mejor.

Identificación de cualquier “resultado rápido” que pueda ser implementado

en un periodo de 3-6 meses.

Un informe de la fase.

Algunas de las razones a favor y en contra del modelado de procesos en la

fase “Entender” figuran en esta lista.

6.1.4.2 Razones a favor:

Para obtener una comprensión común, y un lenguaje común del problema.

Para mostrar las deficiencias de la situación actual.

Para apoyar la aceptación de la “descongelación” para el proyecto.

Para permitir la evaluación de la integridad del proceso de innovación.

Modelos producidos se pueden utilizar como documentación del proceso si

hay poca necesidad de cambiarlo.

Las personas se acostumbran a pensamiento y modelado de procesos.

Para establecer una base para la relación de los procesos con la

organización, y el personal de TI.



empresas

72

6.1.4.3 Razones en contra:

La situación actual como haya sido modelada se vuelve obsoleta tan pronto

como los procesos de innovación sean diseñados e implementados.

Siempre existe el peligro de tener un diseño del proceso con “enfoque

limitado”, lo que pone restricciones en el pensamiento para la innovación de

procesos.

Toma tiempo, requiere un gran compromiso de recursos y dinero, en la

mayoría de los casos es un procedimiento complicado con una curva de

aprendizaje pronunciada en la primera instancia.

Existe el peligro de hacer demasiado y ahogarse en los detalles.

6.1.4.4 Pasos:

Grafica 10: Pasos de la fase de entendimiento [16]


Paso 2: Revalidar el enfoque

Paso 3: Entender el workshop

Paso 4: Completar métricas de análisis

Paso 5: Análisis de causa-Raíz

Paso 6: Completar matriz de capacidad

Paso 7: Identificar información disponible

Paso 8: Identificar propiedades de innovación



empresas

73

Paso 9: Identificar resultados rápidos

Paso 10: Entender reportes de la fase.


Innovar

Personas

Desarrollar

Implementar

Obtener valor.

6.1.5 Fase de innovar

El propósito de esta fase es hacer los procesos y el enfoque del proyecto tan

eficiente y efectivo como sea posible, para cumplir con las actuales y futuras

expectativas de los stakeholders.


Rediseño de modelos de proceso

Documentación que respalde los procesos rediseñados

Requerimientos de negocio de alto nivel de las opciones del nuevo proceso

Modelos de simulación y detalles de costeo basado en actividades.

Capacidad de información de planificación.

Confirmación de que las opciones de los nuevos procesos alternativos

cumplirán con las expectativas de los stakeholders.

Confirmación de que las opciones de los nuevos procesos alternativos son

consistentes con la estrategia organizacional y cumplirán los objetivos del

proceso designados.

Un reporte de análisis de la brecha del proceso.

Un plan de proyecto detallado para las fases: Personas y Desarrollo.

Detallado análisis costo-beneficio puede producido e introducido en el caso

de negocio.



empresas

74

Un caso de negocio actualizado con información más detallada y costos y

beneficios cuantificables, y valoración de impacto en la organización, estos

deben reflejar los beneficios tangibles en intangibles.

Un informe detallado acerca de las medidas adoptadas, las opciones

alternativas consideradas, análisis, conclusiones y recomendaciones.

Una presentación a la alta dirección apoyando el caso de negocio y la

dirección recomendada.

Un plan de comunicaciones inicial para informar a todos los stakeholders.

Un documento inicial de la estrategia de gestión de cambio de personas.

6.1.5.2 Pasos:

Grafica 11: Pasos fase de innovar [16]


Paso 2: Inicio de workshop ejecutivo



empresas

75

Paso 3: Establecer el proyecto

Paso 4: Grupos de enfoque de stakeholders externos

Paso 5: Innovar workshops iniciales

Paso 6: Completar la matriz de capacidad

Paso 7: Futuras proyecciones de métricas del proceso

Paso 8: Simulación

Paso 9: Crear estrategia de gestión de cambio de personas

Paso 10: Actualizar matriz de capacidad

Paso 11: Planificación de la capacidad

Paso 12: workshop de soluciones propuestas

Paso 13: Demostrar y validar la factibilidad de las soluciones propuestas.

Paso 14: Análisis de la brecha del proceso

Paso 15: Identificar los beneficios y actualizar el caso de negocio

Paso 16: Aprobaciones

Paso 17: Reporte y presentación

Paso 18: Requerimientos de negocio


Personas

Desarrollo

Implementación

Obtener Valor

Rendimiento Sostenible

6.1.5.4 Retroalimenta:

Entendimiento

Plataforma de lanzamiento



empresas

76

Estrategia organizacional

Arquitectura del proceso.

6.1.6 Fase de personas

La fase de personas es una fase muy crucial en cualquier proceso de

implementación BPM, y a menos que se maneje a fondo y con un alto nivel, el

resto del proyecto se pondrá en riesgo. Es importante entender claramente que

esa es la diferencia con la fase de implementación, que se enfoca en la puesta en

marcha de la solución. La fase de personas es usualmente conducida al mismo

tiempo de la fase de desarrollo del proyecto. La fase de desarrollo crea la solución

automatizada, y la fase de personas crea los roles y las personas medidoras de

soluciones.


¿Cómo saber que la fase está siendo efectiva? Por la forma en que las personas

reaccionan al cambio, cambio de roles, nuevos procesos y nuevos roles de la

gestión de rendimiento y objetivos de medición.

6.1.6.2 Actividades y reportes producidos en esta fase:

La disección y la fusión de los nuevos procesos y sus actividades en tareas

que lo componen.

Rediseño de descripciones de roles y objetivos que se han discutido y

acordado con la gente que los ejecutará.

Gestión de desempeño y medidas para los roles adecuados, que también se

han discutido y acordado con la gente que los ejecutará.

Un plan y un conjunto de tareas que permitan a la organización “transformarse”

de donde se encuentra actualmente a donde quiere estar. Esto incluye un

conocimiento profundo de las competencias principales actuales y futuras y las

capacidades de las personas, a nivel de rol. Esto se superpone al análisis de

las deficiencias del proceso producidas antes de habilitar el entrenamiento

apropiado del plan a desarrollar para los individuos y equipos de personas.

Un nuevo proceso basado en la estructura de la organización de las áreas de

negocio involucradas en el proyecto.



empresas

77

6.1.6.3 Pasos

Grafica 12: Pasos de la fase de personas [16]


Paso 2: Estrategia de Diseño

Paso 3: Definición de las actividades

Paso 4: Diseño de roles

Paso 5: Gestión de rendimiento y medición.

Paso 6: Capacidades centrales de análisis de las deficiencias

Paso 7: Diseño de estructura organizacional

Paso 8: Actualizar estrategia de gestión de cambio de personas

Paso 9: Actualizar políticas de recursos humanos

Paso 10: Desarrollar el entrenamiento


Desarrollar

Implementar

Obtener Valor

Rendimiento Sostenible



empresas

78

6.1.6.5 Retroalimenta:

Innovar

6.1.7 Fase de desarrollo

Después de la fase de innovación y el resto de fases, se encuentra la fase de

desarrollo que es donde la empresa selecciona como automatizará el proceso,

como integrará su sistema con los sistemas internos y cómo será la colaboración

con estos sistemas, permitiendo a la empresa la suficiente flexibilidad para

adaptarse a los cambios del negocio en un futuro y en tiempo real.


un alto nivel de conocimiento de la solución

requerimientos del negocio detallados

la documentación del software finalizada

diseño y especificación de software

desarrollo y configuración de software

especificación de hardware

disponibilidad de hardware

guiones de prueba de hardware y resultados

guiones de prueba de integración y resultados

6.1.7.2 ¿Cómo se realizará?

Hay básicamente 2 maneras de desarrollar una solución automatizada de BPM: la

tradicional que tiene ciclo de vida del desarrollo de software (SDLC) y el enfoque

(especificación, desarrollo, pruebas) y el enfoque iterativo de un desarrollo de

aplicaciones rápido (RAD), este enfoque depende solo de la empresa.



empresas

79

6.1.7.3 Pasos:

Grafica 13: Pasos de la fase de desarrollo [16]

Determinar

componentes

BPM

Decidir la

reutilización, comprar

hacer o tercerizar

Actualización

funcional y

especificaciones

tecnicas

Desarrollo de

software

Despliegue de

hardware

Pruebas

Comunicaciones


Paso 2: determinar los componentes BPM

Paso 3: decidir si re-usar, comprar, hacer o tercerizar

Paso 4: actualización funcional y especificaciones técnicas

Paso 5: desarrollo de software

Opción 1: enfoque tradicional para el desarrollo SDLC

Opción 2: desarrollo rápido de aplicaciones

Paso 6: despliegue de hardware

Paso 7: pruebas.


Fase de implementación

Personas

Obtener valor

Rendimiento sostenible



empresas

80

6.1.7.5 Riesgos de la fase de desarrollo:

desarrollar una solución sin conocer los requerimientos del negocio

algunas aplicaciones trabajan, sin embargo no todas trabajan

probar y encontrar muchos errores

6.1.8 Fase de implementación

La fase de implementación es la fase donde los procesos de diseño, desarrollo y

las mejoras serán realmente traídas a la realidad, es también la fase donde

muchas de las personas cambian actividades de administración conjuntas.


Cuando la implementación se finaliza de manera correcta, la organización puede

esperar:

Entrenamiento y motivación de los empleados

Mejoramiento o nuevos procesos que se han desarrollado satisfactoriamente

de acuerdo con lo identificado por los stakeholders, sus requerimientos y

necesidades


Los proyectos fallan porque la implementación es restringida a ser uno de los

pasos cerrados del proyecto y está centrado en una sola manera de comunicación

e información a los usuarios y otros stakeholders de los beneficios de la nueva

solución de la organización.

Se debe entender que la mayoría de las actividades son enfocadas en asegurar

que los usuarios pueden usar la nueva solución, por ejemplo con entrenamiento,

evitando que se use de manera incorrecta o como la gente quiera.

La mejor manera de asegurar una buena implementación es empezar

considerando los problemas de implementación al iniciar el proyecto. Solo cuando

sea la fase de implementación del framework se enfocara en la actualización de

información y presentación de las tareas.



empresas

81

6.1.8.3 Pasos

Grafica 14: Pasos de la fase de implementación [16]

Actualizar el

plan de

implementación

Preparar para la

prueba de

aceptación del

usuario

Personal de

entrenamiento

Pruebas

completas de

negocio y

pilotos.

Actualizar

entregables

Involve

management

Desarrollar roll-

out y back-out y

los planes de

contingencia

Desarrollar y

ejecutar

programas de

marketing

Grupo de

tutoresCambios roll-out

Monitoreo y Ajuste

Proveer retroalimentación a usuarios y stakeholders

Comunicaciones


Paso 2: Actualizar la estrategia de implementación

Paso 3: Preparar para pruebas de aceptación del usuario

Paso 4: Grupo de entrenamiento

Paso 5: Pruebas completas de negocio y pilotos

Paso 6: Actualizar entregables

Paso 7: Implicación de la administración

Paso 8: Desarrollar roll out, back-out y planes de contingencia



empresas

82

Paso 9: Desarrollar y ejecutar programas de marketing

Paso 10: Grupo tutor

Paso 11: Cambios roll-out

Paso 12: Monitorear y ajustar

Paso 13: Retroalimentación a usuarios y stakeholders

6.1.8.4 Obtener valor:

Solo en las fases de desarrollo y personas, los beneficios podrían ser definidos en

detalle para ganar aceptación de las partes de esta fase.


Dependiendo de cómo el proyecto será implementado será el impacto de los

beneficios y el valor del proyecto.

La implementación tendrá salida a la fase del desempeño sostenible

La revisión y finalización del enfoque de implementación podrían resultar

cambios necesarios en las fases de personas y de desarrollo



empresas

83

6.1.9 Fase de obtener valor

La mayoría de organizaciones creen que los proyectos se terminaran y tendrán

una vida útil y los usuarios serán felices, casi nunca sucede esto

Un proyecto esta completo una vez la razón de existencia haya sido archivada y

este haya sido manipulado sobre el negocio, y que este pueda sostener las

mejoras al proyecto.

Los beneficios del negocio deben ser planeados, interiorizados y trabajados para

que puedan verse, es por esto que la obtención del valor del negocio rara vez es

inmediato, tarda normalmente de 3 a 6 meses.

Este periodo de transición donde los costos operacionales aumentan desde un

corto periodo después de la implementación y luego los beneficios empiezan a ser

obtenidos y el costo operacional decrece.

El objetivo de esta fase es unir todos los pasos del framework y asegurar el

aprendizaje y entendimiento, para que finalmente el valor del proyecto se haya

obtenido.


Un beneficio al plan

Un beneficio a la matriz

Beneficios entregables a la matriz

Beneficios registrados


Su el valor del negocio es obtenido, este debería ser un proceso estructurado a

través del proyecto y de la organización, estos beneficios saldrán del análisis

costo-beneficio



empresas

84

6.1.9.3 Pasos

Grafica 15: Pasos de la fase de obtener valor [16]

Beneficios

Administrativos

del framework

Identificar

beneficios

potenciales y

planificarlos

Establecer

líneas base y

comparar

mediciones

Redefinir y

optimizar

beneficios

Definir detalles

de los beneficios

Beneficios

entregables y

rastreables

Valor

monitorizado y

maximizado

Fase de

proceso de

arquitectura

Fase de

lanzamiento

Fase de

entendimiento

Fase de

innovación

Fase de

desarrollo,

personas e

implementación

Fase de

obtener

valor

Rendimiento

sostenible

Comunicaciones

Paso 1: Beneficios de la administración del framework

Paso 2: Identificar beneficios potenciales y planificarlos (fase de lanzamiento)

Paso 3: Establecer una línea base y medidas comparativas

Paso 4: redefinir y optimizar beneficios

Paso 5: definir los beneficios en detalle

Paso 6: beneficio entregable y rastreable

Paso 7: monitorizar y maximizar el valor obtenido

Paso 8: comunicaciones

6.1.9.4 Factores críticos en el proceso:

El entendimiento de obtener valor necesita ser realizado y criticado por

parte del personal de la organización

Aceptación de los roles, responsabilidades y cuentas asociadas con la

obtención de valor

El grupo involucrado en la obtención de valor debería ser entrenado en la

identificación de los beneficios, análisis y revisiones.

Beneficios inesperados deben ser reconocidos y grabados



empresas

85


Retroalimentar y de ser posible sugerir cambios en la implementación,

completando y maximizando los beneficios futuros

Cambios en las personas, cambios en la administración podrían ser

sugeridos

De ser posible, realizar cambios que son necesarios en la forma en que han

sido diseñados y desarrollados los procesos para maximizar los beneficios.

Conocimiento, que será una contribución para el aseguramiento de la

sostenibilidad del proyecto.

6.1.10 Fase de rendimiento sostenible

Muestra la necesidad de mover un proyecto basado en el negocio a un proyecto

basado en un ambiente BPM.

La sostenibilidad es determinada por la organización para crear y entregar valor a

los stakeholders de manera continua, se trata de entender el valor de los clientes y

observar en un futuro como será influenciada la estrategia organizacional, como

se diseñará y se actuará.

Los procesos estarán sujetos a mejoras y rediseños continuos como reflejo de

esta acción, si esto no ocurre simplemente la organización habrá realizado este

proceso como una moda.

En otras palabras, el rendimiento sostenible se realiza con una administración

continua de los procesos, identificando y realizando los objetivos específicos.


Mecanismos para la administración de procesos de negocio para identificar

y obtener oportunidades para la mejora de los procesos

Controlar y mejorar procesos



empresas

86

6.1.10.2 Pasos

Grafica 16: Pasos de la fase de rendimiento Sostenible [16]

Evaluar los

resultados del

proyecto

Desarrollar

estrategias de

sostenibilidad

Medidas de

rendimiento y

administración

Introducir ciclos

de

retroalimentación

Sostenibilidad Reevaluar la

sostenibilidad

Gobernar

procesos

institucionales

Monitorizar la

sostenibilidad comunicaciones

Mantenimiento de

los modelos del

proceso

Paso 1: evaluar los resultados del proyecto

Paso 2: desarrollar estrategias de sostenibilidad

Paso 3: medidas de rendimiento y de administración

Paso 4: introducir ciclos de retroalimentación

Paso 5: sostenibilidad

Paso 6: reevaluar la sostenibilidad

Paso 7: gobernar los procesos institucionales

Paso 8: monitorizar la sostenibilidad

Paso 9: comunicaciones

Paso 10: mantenimiento de los modelos de proceso.

Las 10 fases especificadas no son suficientes para asegurar que un proyecto BPM

sea satisfactorio, un proyecto BPM requiere muchos más aspectos y facetas para

ser cubierto.



empresas

87

La agrupación de los 3 elementos esenciales distribuidos en las 3Ees así:

6.1.11 Gestión de proyectos

Una aplicación normal o el gerente de negocios del proyecto puede implementar

un proyecto BPM, sin embargo los riesgos serán sumamente altos y se

malgastarían muchos de los beneficios que podrían ser logrados con BPM, por lo

que se recomienda una experiencia significativa en la “GESTION DE

PROYECTOS” para implementar este satisfactoriamente.

Este „esencial‟ tiene como partes importantes:

Gates del proyecto

Gestión de stakeholders

Gestión de riesgos del proyecto

6.1.12 Gestión de cambio de personas

Dar con las ideas es la parte fácil, pero hacer las cosas es la parte difícil. El lugar

donde estas ideas se mueren, es en las “trincheras”, y ¿quiénes son los dueños

de esas trincheras? Respuesta: Las personas en la organización.

6.1.13 Liderazgo

Un punto reconocido por todos los expertos en el cambio de procesos de negocios

es que cualquier programa de cambio debe contar con el apoyo de la alta

dirección para tener éxito. El grado en que los líderes ejecutivos delegan

responsabilidades es crucial para la efectividad de los resultados de los proyectos

BPM.



empresas

88

6.2 IBM BPM framework -prescriptive guide to solution implementation.

La información presentada a continuación fue extraída y traducida del libro IBM

Business Process Management Prescriptive Guide to Solution Implementation

6.2.1 Fase de descubrimiento

Esta es la fase en la cual las metas del negocio, objetivos y estrategias son

revisadas y acordadas, partiendo de estas metas se pueden usar mapas de alto

nivel estratégico para visualizar las metas y empezar a revisar y entender mejor el

proceso.


Mapas estratégicos

Mapas de capacidades

Mapas de procesos de alto nivel importado de un modelador.

6.2.1.2 Pasos:

Grafica 17: Pasos de la fase de descubrimiento [33]

Estrategia en la

solución

Definir metas

de Negocio

Definir medidas

del negocio

Identificar cambios

del negocio

Crear mapas con

capacidades del

proceso

Crear mapas de

procesos de alto

nivel

Obtener la

aprobación

ejecutiva


Identificar los cambios del negocio:

Trabajar con los líderes del negocio para determinar qué cambios en el

negocio podrían necesitar ser dirigidos

Priorizar y evaluar los cambios y documentarlos.



empresas

89

Estrategia en la solución:

Crear estrategias relacionadas con los cambios del negocio para determinar

las relaciones que influyen en las metas y en las capacidades basadas en

prioridades.

Definir metas del negocio:

Basado en la identificación de la estrategia y los objetivos, se definen las

medidas del negocio que pueden tener seguimiento y ser monitorizadas

periódicamente para asegurar que la solución propuesta reúne los objetivos

específicos del negocio que fueron identificados anteriormente.

Crear mapas con las capacidades del negocio.

Priorizar capacidades basados en los cambios del negocio.

Crear procesos de alto nivel para una alta priorización de las capacidades

del negocio.

Obtain executive sign-offs and approvals.

6.2.2 Fase de Story Boarding

En esta fase es en la que se modelan y revisan las interacciones con los usuarios

y el acompañamiento de los procesos de negocio.

El objetivo está en capturar y redefinir el estado actual del proceso (AS-IS) y así

entender como las mejoras pueden ser incorporadas para llegar a un futuro estado

del proceso.


Modelar el estado actual del proceso

Modelar el estado futuro del proceso con la información del diseño del negocio

Reporte de impactos del negocio

Maqueta de los formularios.



empresas

90


En esta fase se validaran las entradas y salidas por tarea y se validaran las

interacciones de los humanos con el sistema.

6.2.2.3 Pasos

Grafica 18: Pasos de la fase storyboarding [33]

Capturar los

roles

Examinar

alternativas en

los escenarios

ROI

Capturar/Redefinir

el estado actual

del proceso

Definir/Redefinir

futuros estados del

proceso

Crear maquetas

de los

formularios

Obtener la

aprobación

ejecutiva

Crear reglas de

negocio

6.2.3 Fase de experiencia

Después de haber modelado el flujo básico del proceso y verificar que las

actividades en el flujo de trabajo son las esperadas, el proceso estará listo para

ser perfeccionado y así hacerse más fácil y entendible para las personas que

utilizaran la aplicación para realizar sus tareas asignadas.

Esta fase tiene el objetivo de capturar la intención de negocios a través de la

documentación y la creación de modelos básicos de las metas de negocio,

objetivos y estrategia organizacional.

Esta es la fase en la que el analista de negocios puede empezar a experimentar la

verdadera solución a través de la visualización y la práctica de pruebas en un

proceso iterativo. El objetivo de esta fase es la de refinar la solución. Esto se hace

trabajando con conjuntos de datos realistas, pero antes de que la solución sea

implementada en un entorno de producción a escala más grande.



empresas

91

Basándose en la experiencia de los resultados durante este proceso iterativo, se

puede estar seguro de que la solución final, cuando se implemente en un entorno

de mayor escala, será la solución más eficaz que satisfaga las necesidades de los

stakeholders.


Modelos de procesos

Métricas y Definiciones KPI‟s

Definiciones de roles

Maquetas de los formularios

Formularios terminados de usuarios de negocio (2 opciones)

o Todo empaquetado en WAR separados

o Importar de nuevo el modelo del proceso para reemplazar las

maquetas.

6.2.3.2 Pasos:

Grafica 19: Pasos de la fase de experiencia [33]

Definir construcciones

para la ejecución del

futuro estado del proceso

Elaboracion de medidas

de desempeño; KPI y

SLA de negocio

Añadir características

de funcionamiento

para el futuro estado

del proceso

Perfeccionar los

formularios

Validar iterativamente

la elaboración del

proceso en el entorno

TI

6.2.4 Fase de gestión

Esta fase se conoce como la fase de gestión. El enfoque de esta fase es la

administración del modelo de procesos de negocio y su optimización.

Cuando considere que el modelo del proceso ha cumplido con todos los requisitos

del ciclo de IPD (Interactive Process Design), procederá a desplegarse en pre-

producción y posteriormente en el ambiente de producción, ya que solo en este



empresas

92

ambiente se pueden observar y registrar las conductas, dichas conductas están

basadas en los resultados del análisis realizado con datos en tiempo real,

haciendo más sencilla las mejoras que permiten la optimización de los procesos

de negocio.

El objetivo de esta fase es permitir pro-activamente a los usuarios controlar y

gestionar en tiempo real el rendimiento del negocio a través de indicadores clave

de rendimiento (KPIs) y alertas en base a las condiciones cambiantes del negocio.


Configuración en el ambiente de negocios.

Configuración administrativa de usuarios.

Sugerencias para futuras mejoras.

6.2.4.2 Pasos:

Grafica 20: Pasos de la fase de gestión [33]

Gobernabilidad de

cambios

Asignar derechos de

acceso

Capacitar a los

usuarios de negocio

Optimizar la

asignación de

trabajos

Gestión de rendimiento

del negocio en tiempo

real

Tomar medidas

correctivas usando

datos en tiempo

real



empresas

93

6.3 BPMN-Framework

Este framework permite seleccionar el tipo de objetos que se utilizan o que los

autores recomiendan usar de acuerdo al nivel del framework.

Gráfica 21: Marco estructural para BPMN [20]

Entorno de Procesos

•contenido: alcance y funcionalidad

•Objetivo: Comprensión rápida

•Semántica: logico-abstracto

Nivel 1

Nivel descriptivo

•Contenido: Flujo operativo

•Objetivo: Coordinación en detalle

•Semántica: Fisico- concreto

Nivel 2

Nivel Operativo

•Contenido: Detalles Técnicos

•Objetivo: Implementación

•Semántica: Fisico- concreto

Nivel 3a Nivel 3b

Modelo Tecnico Especificación para desarrollo

Nivel 4b implementación

Entorno de

procesos

Negocio

(Bussines)

Técnico (TI)



empresas

94

El framework fue desarrollado desde la perspectiva de un proyecto y se refiere

siempre a un proceso o a un grupo de procesos que están relacionados entre sí.

El modelamiento de mapas de proceso NO HACE PARTE DE ESTE MAPA

METODOLÓGICO.

6.3.1 Nivel 1- Procesos Descriptivos

El objetivo principal en este nivel es describir el alcance que tienen los procesos

de principio a fin.

En este nivel se define el contexto de los procesos que se deben levantar,

modelar, documentar y eventualmente rediseñar. El objetivo de este nivel es

además validar el alcance y la funcionalidad principal de los procesos que deben

levantarse.

6.3.1.1 Objetivos:

Definición del alcance de los procesos

Asignación de las responsabilidades y recursos del proceso

Definición de los principales KPI‟s

Requerimientos generales que se esperan para mejorar el rendimiento de

los procesos.

6.3.1.2 Salidas del proceso:

Flujo normal del proceso, sin considerar los casos de excepción o errores.

Validar de forma rápida el alcance del proyecto con los responsables del

negocio.

Introducir al resto de los participantes en el proyecto.

6.3.2 Nivel 2-Procesos Operacionales

En este nivel se desarrolla toda la lógica de los procesos en su máximo detalle,

incluyendo los casos de excepción, fallas e interrupciones que pueden ocurrir a

nivel de negocio.

6.3.2.1 Salidas del proceso:

Modelo que abarque toda la lógica del negocio y sea transferible a la

implementación.



empresas

95

6.3.3 Nivel 3a – Modelo Técnico

El modelo técnico es la representación de un modelo operacional en un motor de

procesos, pero adaptando el proceso de negocio a un modelo ejecutable y

enriqueciéndolo con aspectos técnicos.

6.3.4 Nivel 3b- Especificación para desarrollo

Si no se utiliza un motor de procesos, la lógica de negocio tiene que ser

desarrollada en algún lenguaje de programación, en esos casos se debe elaborar

una especificación técnica. Los diagramas deben pasarse a una especificación

adecuada para el amiente de programación escogida.

6.3.5 Nivel 4b – Implementación

Esto ocurre solo si no se ha utilizado un motor de procesos, en este nivel se

implementa técnicamente el proceso en una plataforma tradicional.

Al concluir la investigación de las metodologías diseñadas para la implementación

exitosa de proyectos BPM de las compañías pudimos observar que cada

metodología tiene un enfoque diferente y no cubren todas las necesidades de una

compañía en cuanto a lineamientos administrativos o lo referente al departamento

de TI, ya que se considera BPM como “un enfoque centrado en los procesos para

mejorar el rendimiento que combina las tecnologías de la información con

metodologías de proceso y gobierno” [14]

Se puede observar que el Framework 7FE es un enfoque administrativo que busca

obtener toda la información direccionada por las personas encargadas del negocio

y deja a un lado la parte técnica.

Se puede observar también que el Framework BPMN-Camunda cubre todos los

requerimientos técnicos desde el punto de vista de la notación BPMN pero deja a

un lado los requerimientos administrativos y el descubrimiento de las necesidades

administrativas.

El framework de IBM BPM FRAMEWORK une los dos enfoques pero está dirigido

a las herramientas que ellos suministran, no ofrece la flexibilidad necesaria que

requiera una compañía, y no contempla la posibilidad de que la empresa no

adquiera productos IBM.



empresas

96

7 FRAMEWORK BPM-ENTERPRISE

El framework propuesto en esta investigación se basa en la extracción de las

características más sobresalientes de los frameworks estudiados de “7FE Project

Framework” y “BPMN-Framework”, esta decisión se tomó partiendo de la idea de

tener una metodología con enfoque administrativo y técnico a la vez, por esta

razón se verá como a medida que avanzan las fases del framework deja de ser

una prioridad la gestión administrativa y nos adentramos en el modelado de

procesos basados en el estándar BPMN, bien definidos, documentados y listos

para desarrollar.

Para tener una comprensión clara de cómo fue construido nuestro framework

basándose en cada una de las características sobresalientes de los frameworks

estudiados, se identificará a cada uno de estos asociándolo con un color, la

distribución se hará de la siguiente manera:

COLOR ROJO: Fragmentos extraídos del 7FE Project framework

COLOR AZUL: Fragmentos extraídos del BPMN framework.

Fases de la metodología propuesta

La metodología propuesta tiene una serie de fases que van desde reuniones con

los stakeholders claves para el negocio, priorización de los procesos de negocio a

automatizar, modelamiento de procesos basándose en el estándar BPMN,

desarrollo de la solución (tradicional o en un process engine), implementación y

capacitación al personal, hasta tener el proceso en constante monitoreo y así

saber, con el pasar del tiempo, cuando es pertinente hacerle una mejora al mismo.

El ciclo de vida de la metodología planteada, define: objetivos, fases, entradas,

pasos, roles y entregables necesarios para la correcta implementación. La

metodología está compuesta de seis fases, los cuales se listan a continuación:

• Fase 1: Cimientos.

• Fase 2: Entender.

• Fase 3: Innovar.

• Fase 4: Desarrollar.

• Fase 5: Implementar.

• Fase 6: Rendimiento sostenible.



empresas

97

En la siguiente grafica se presenta un resumen de las fases y los pasos del

framework propuesto en esta investigación.

Grafica 22: Framework propuesto



empresas

98

7.1 Fase de Cimientos

Las ineficiencias o inconformidades con el rendimiento de una unidad de negocio

pueden ser los principales incentivos para empezar un proyecto BPM, sin embargo

como y donde hacerlo no es una tarea fácil de hacer.

Por ese motivo, esta fase es la encargada de seleccionar una unidad de negocio

para su mejoramiento, determinar: el alcance del proyecto, como está establecido

y como se pone en marcha, todo esto con el fin de que el proyecto sea un éxito,

por eso incluye entre sus entregables: El alcance del proyecto, selección del

equipo del proyecto, expectativas de los stakeholders, establecidas y

comprometidas, metas iniciales del proceso y objetivos del proyecto BPM

seleccionado.

FASE DE CIMIENTOS

7.1.1 Entradas de esta fase: Para poder dar inicio a esta fase son necesarios una serie de documentos de entrada, tales como:

Anexo 4: Formulario 1 –Pre Fase Anexo 5: Template del caso de Negocios

PASOS:

Grafica 23: Pasos de la fase Cimientos (Tomada y adaptada de Business Process Management - Practical Guidelines Successful Implementations)



empresas

99

7.1.2 Salidas de esta fase:

Anexo 7: Lista de stakeholders involucrados o asociados con el proyecto. Anexo 8: Acta a stakeholders que valide su participación, compromiso y

expectativas documentadas y acordadas. Matriz de selección de procesos. (ver Paso 3.5) Anexo 9: Una lista de los procesos de negocio identificados. Lista de objetivos del proceso acordados Matriz de valor del proceso. (ver Paso 3.6) Anexo 10: Lista de procesos priorizados. Estrategia de implementación inicial. Documento de gestión del proyecto:

Anexo 11: Equipo del proyecto establecido y sus respectivos roles

Alcance del proyecto documentado

Anexo 6: Análisis de riesgos y problemas Anexo 5: Caso de negocio inicial.

7.1.3 Pasos

En la gráfica 23 se presentaron los pasos que pertenecen a esta fase, a

continuación se desarrollaran cada uno de estos.

7.1.3.1 Paso 1: Comunicaciones

Todas las personas de la organización deben estar informadas, no solo durante

esta fase si no durante todo el proyecto BPM de cualquier tipo de modificación

que se haga en el alcance, las metas o el trato con los stakeholders, sin embargo

esta comunicación no es suficiente, también se debe dejar muy claro como el

proyecto impactará en el personal y como se espera que sea la reacción de la

gestión del personal.

Es posible que el personal de la organización reaccione de manera inadecuada

debido a similares implementaciones anteriores, como por ejemplo: un proyecto

BPR, así que estará en sus manos mostrar porque un proyecto BPM es diferente.

Toda duda, pregunta u objeción debe ser manejada de manera proactiva, para

que las personas abran su mente sin sentirse atacadas.

7.1.3.2 Paso 2: Gestión de stakeholders e implicados en el proyecto.

En un proyecto BPM no solo es muy importante establecer quiénes son los

stakeholders claves y los implicados dentro del equipo del proyecto si no también

saber cuáles son sus roles dentro de este, para así asegurarse que la visión

general del negocio actual fue obtenida de las personas indicadas. Por

consiguiente, las siguientes actividades son de suprema importancia:



empresas

100

Entrevistar a los stakeholders claves.

Realizar una caminata por las áreas implicadas en el proceso.

Realizar una lluvia de ideas para descubrir los stakeholders del proyecto.

Definir y establecer la estructura del equipo del proyecto y los roles

Cada uno de estas actividades se examina con más detalle a continuación:

7.1.3.2.1 Paso2.1: Entrevistar a los stakeholders claves.

Se realiza para entender cuáles son los problemas operacionales desde la

perspectiva de los stakeholders de cada área y saber además cuáles son sus

necesidades más inmediatas, para esto son necesarias una serie de entrevistas

que tendrán como propósito obtener una visión general del negocio actual y del

entorno del proceso, pero sobre tiene como finalidad construir una buena relación

con los stakeholders, pues se necesitará de ellos durante el transcurso de todo el

proyecto.

7.1.3.2.2 Paso2.2: Realizar una caminata por las áreas implicadas en

el proceso

En caso tal que los stakeholders claves no estén muy familiarizados con los

procesos de la unidad de negocio, es altamente recomendable hablar con las

personas que ejecutan el proceso, pues hay grandes diferencias entre lo que se

cree que está sucediendo y lo que realmente sucede, por este motivo, la

“caminata” debe proporcionar una visión a los miembros iniciales del equipo del

proyecto de cómo funciona realmente el proceso, lo cual proporciona un excelente

bosquejo de cómo el negocio se lleva a cabo, las similitudes y las diferencias del

proceso (como se pensaba que funcionaba VS como realmente funciona).

También es necesario un recorrido por el departamento de tecnologías de

información (TI), el cual proporciona un resumen de alto nivel de como las

aplicaciones empresariales y la infraestructura interactúan y soportan los procesos

de negocio.

7.1.3.2.3 Paso2.3: Realizar una lluvia de ideas para descubrir los

stakeholders del proyecto

Consiste en realizar una lluvia de ideas para descubrir quiénes son los

stakeholders en el proyecto (tanto desde perspectivas internas, como externas).

En la perspectiva externa se incluyen los stakeholders fuera de la unidad de

negocio pero aún dentro de la organización que se verán afectados por el

proyecto, así como stakeholders externos a la organización - por ejemplo, clientes,

socios y proveedores.



empresas

101

Una vez elegidos, la decisión tomada debe ser informada a los mismos y

posteriormente documentada.

7.1.3.2.4 Paso2.4: Definir y establecer la estructura del equipo del

proyecto y los roles

Una vez todos los stakeholders e implicados claves hayan sido elegidos e

informados, el equipo del proyecto inicial y el negocio estará en condiciones de

crear la estructura del proyecto BPM y organizar el equipo del proyecto.

Un ejemplo de la estructura de un proyecto es mostrado a continuación, el cual

está diseñado para una implementación o un proyecto BPM a gran escala, y

tendrá que ser modificado para adaptarse a los requerimientos concretos de la

organización y del proyecto. Aunque no es normal que el equipo sea de gran

tamaño, el número y composición de los equipos de trabajo (flujos de trabajo)

dependerá del proyecto y de los componentes que participen en la automatización.

Se mostrará un equipo de trabajo de un componente de gestión de documentos,

sin embargo este podría referirse a un motor de procesos e implementaciones de

reglas de negocio. Esta es, sin embargo, una estructura que ha sido

particularmente eficaz, por lo que la modificación en exceso puede llevar a

comprometer la eficacia del proyecto.



empresas

102

Grafica 24: Estructura del equipo del proyecto [16]

7.1.3.2.4.1 Comité Directivo del Proyecto, Director del proyecto y

Gerente del proyecto

Los roles y responsabilidades del comité directivo del proyecto, director de

proyecto, gerente del proyecto y líderes de equipo son parecidas a las funciones

normales que estos roles tendrían en cualquier tipo de proyecto. Sin embargo,

cada uno de estos roles se detallará a continuación:

Los cargos clave de LIDERAZGO en la estructura del proyecto son:

1. La unidad de negocios debe tener su propio gerente de proyecto con la

responsabilidad general de todo el proyecto. Esto es, después de todo, un

proyecto de negocio, no un proyecto de TI. Esta posición es crucial para

asegurar que los requerimientos del negocio se cumplen y son de importancia

primordial. Tecnologías de información (TI), proveedores y todos los otros



empresas

103

componentes del proyecto deben informar al gerente del proyecto de negocios.

Lo ideal sería que este gerente de proyectos de negocios sea un

experimentado gerente de proyectos con experiencia en BPM. Si este no tiene

experiencia BPM es requerido un experimentado y capacitado consultor de

BPM.

2. Un consultor de BPM senior y con experiencia es muy recomendable, no sólo

para entrenar al gerente del proyecto de negocios, si se carece de

conocimientos de BPM, sino también para ayudar con:

Objetivamente la gestión de situaciones en las que compromete el proceso

o proyecto deben hacerse durante el transcurso del proyecto, ya que esto

será inevitable. Estas decisiones pueden tener repercusiones muy graves, y

un especialista experto en BPM puede gestionar este riesgo para evitar que

el proyecto BPM se convierta en un caro proyecto de mejora de procesos

de negocio que producirá beneficios limitados.

Asegurar que el proyecto BPM sigue centrado y auto-financiado, y continúa

ofreciendo un valor empresarial real.

La identificación de oportunidades de negocio adicionales que podrían ser

posibles gracias BPM.

Asegurar que la necesaria gestión de cambio de personas este bien

integrada con el plan del proyecto y por lo tanto gestionado como una parte

esencial del proyecto.

Agregar valor a la gestión de los stakeholders y proporcionar la experiencia

necesaria para garantizar que esta sigue siendo continuamente

comprometida y enfocada hacia una exitosa entrega de BPM.

7.1.3.2.4.2 Equipo de Decisión del proyecto

El equipo de decisión del proyecto debe resolver todas las preguntas que pueden

evitar la necesidad de que se remita al comité directivo del proyecto.

Este debe incluir a los líderes de usuarios de cada uno de los equipos de usuarios,

y estará presidido por el jefe oficial del proceso o el patrocinador del proceso

designado.

La estructura del proyecto para los pequeños proyectos de BPM pueden requerir

que algunos de los roles se fusionen, sin embargo, el liderazgo es muy importante

en cualquier proyecto y es particularmente importante en un proyecto BPM, por lo

que nunca se debe ver comprometida esta área del proyecto.



empresas

104

El Comité Directivo cumple la función normal esperada dentro de un proyecto. Por

lo general, incluye el patrocinador del proyecto, el responsable del proyecto,

propietario del negocio, CIO o directivo senior de TI (donde hay un gran

componente de TI dentro del proyecto), y una o dos personas que representen a

los aspectos organizativos para garantizar que la sinergia se pueda obtener a

través de la organización.

7.1.3.2.4.3 Comité de Arquitectura de procesos de Negocio

Establecer este comité es la mejor manera de involucrar la arquitectura del

proceso en la organización. Su principal responsabilidad es la de mantener un

resumen de todos los procesos de la organización y la arquitectura de los mismos,

manteniendo la relación entre los objetivos estratégicos de la organización y las

metas del proceso.

Cuando los objetivos estratégicos de la organización cambian, este comité analiza

el impacto de ese cambio y dirige y cambia los procesos de negocio para que

cumplan esos nuevos objetivos estratégicos.

7.1.3.2.4.4 Patrocinador del proyecto

El patrocinador del proyecto tiene el rol normal de un patrocinador en un proyecto

de negocios. Normalmente es un administrador de empresas líder.

Se le define como el campeón del proyecto, y será responsable y rendirá cuentas

de:

Definir y aprobar las metas, objetivos, restricciones y criterios de éxito del

proyecto.

Firmar el alcance del proyecto

Firmar el documento de definición del proyecto

Autorización u obtención de autorización de recursos y gastos del proyecto.

Aprobación o negación de cualquier solicitud de cambio que este fuera del

previo alcance del proyecto ya aceptado.

Aprobación del presupuesto del proyecto.

Firmar el proyecto como completado, una vez el alcance definido haya sido

logrado.

7.1.3.2.4.5 Director del proyecto

El director del proyecto es el responsable de todas las actividades asociadas con

el proyecto. El gerente del proyecto y/o los líderes de los equipos del proceso

informaran directamente al director del proyecto.



empresas

105

Este rol es responsable de:

La implementación de varios proyectos esté funcionando bien y reuniendo las

expectativas de los stakeholders.

Mantener una buena relación con los stakeholders

Infraestructura y arquitectura

Gestión de la calidad y la satisfactoria participación del personal.

Recursos humanos

Apoyar al gerente del proyecto y al personal.

Asegurar que los recursos y los medios adecuados, de todo tipo, están a

disposición del equipo del proyecto.

Mientras que es responsabilidad del gerente del proyecto garantizar el

funcionamiento día a día y la coordinación de las funciones anteriores, el director

del proyecto debe tener una "visión global" de la ejecución estratégica y la

alineación del proyecto.

7.1.3.2.4.6 Gerente del proyecto

Es el responsable de la ejecución y coordinación del proyecto, lo cual incluye lo

siguiente:

Gestión del día a día y ejecución de su parte del proyecto.

Desarrollar las políticas y planes que aseguren la concordancia de los

procesos y sistemas donde sea posible.

Asegurarse que los recursos humanos y problemas de entrenamiento son

dirigidos e implementados.

Administrar todas las actividades asociadas con el proyecto para ofrecer los

requerimientos de los stakeholders en el plazo planeado, presupuestos y

calidad.

Preparación y seguimiento de su parte del presupuesto.

Obtener el compromiso de todos los stakeholders

Establecer y usar mecanismos de control del proyecto para administrar los

plazos deseados y el presupuesto.

Comunicar continuamente a la organización y a TI.

Identificar y gestionar los riesgos potenciales existentes.

Monitorear los riesgos asociados con el proyecto y asesorar al director y al

patrocinador del proyecto.



empresas

106

7.1.3.2.4.7 Equipos del proceso

El equipo del proyecto se divide en varios equipos (a menudo denominados como

flujos de trabajo). El hecho de que un proyecto cuente con uno o varios equipos,

obviamente, dependerá de su tamaño y complejidad. Dependiendo del tamaño del

proyecto, cada equipo puede incluir lo siguiente:

el líder del equipo

líder de usuarios

representantes de usuarios del equipo

expertos en el proceso.

Cada uno de estos roles se describen con detalle a continuación:

7.1.3.2.4.8 Líder del equipo

El líder encabezará su equipo (flujo de trabajo) y asegurará que los Workshop se

organicen apropiadamente, el plan del proyecto se desarrolle (junto con el director

del proyecto), y que el calendario conforme a los presupuestos se cumpla y así

sucesivamente. Además, ese rol incluye lo siguiente:

La gestión de las tareas asignadas ya sea completándolas o delegándolas

a los miembros del equipo

Llevar a cabo revisiones periódicas del equipo

Completar los informes periódicos de estado del equipo para su inclusión

en los reportes generales del estado del proyecto

Participar en reuniones periódicas de revisión del proyecto

Ayudar a la resolución de los problemas del proyecto o del negocio

Asegurarse de que todos los problemas están en un log.

Gestionar el desarrollo del plan de pruebas de aceptación de usuarios

(UAT), los casos de prueba, y la ejecución de las pruebas.

Obtener el visto bueno de las UAT de su área.

7.1.3.2.4.9 Líder de usuarios

El líder de usuario es un recurso empresarial que es nombrado por la

administración de empresas y tiene la autoridad para tomar decisiones en nombre

de la empresa. Su rol contempla las siguientes responsabilidades:

Seleccionar los miembros del equipo de usuarios.

Aseguramiento de la calidad técnica y decisiones sobre el diseño del proceso

Regulación de los conflictos que puedan surgir

Representar al equipo de usuarios en el equipo de decisión del proyecto.



empresas

107

Participar en reuniones sobre el proyecto hechas por todos los líderes de

usuarios.

7.1.3.2.4.10 Representantes de usuarios del equipo

Estos son los expertos en la materia técnica o temas de la empresa, y son

seleccionados por el líder de usuarios. Sus responsabilidades son las siguientes:

Participar en Workshops y entrevistas

La creación de equipos de enfoque específicos para las actividades del

proyecto

Garantizar que las cuestiones de calidad, cumplimiento y garantía técnica se

aborden

Participar en todo el proceso de las UAT

Participar en la planeación y ejecución de la implementación.

7.1.3.2.4.11 Expertos en procesos

Este grupo viene desde el centro de la organización de Excelencia de Procesos de

Negocio (CBPE), y proporcionará los conocimientos para:

Diseño y rediseño de procesos

Herramientas de Diseño del proceso utilizadas en el proyecto

Costeo basado en actividades

Simulación del proceso

Capacidad de planificación

Interconexión del proceso.

Si la organización no cuenta con un Centro de Excelencia de Procesos de

Negocio o experiencia interna, entonces estos recursos pueden provenir de un

especialista externo de consultoría BPM.

Entre los expertos en procesos están el analista de procesos y el ingeniero de

procesos.

7.1.3.2.4.11.1 Analista de procesos

Las competencias que se esperan del analista de procesos son conocimientos de

BPM en general y en nuestro caso de BPMN en específico. El analista de

procesos apoya al Gerente del proyecto como asesor interno o externo en todas

las fases de la metodología. Él puede representar como experto al gerente del

proyecto ante consultores externos o formar parte del equipo de proyectos de

BPM. El analista de procesos puede ser miembro de un área de procesos de la

empresa o pertenecer como analista al departamento de informática de la



empresas

108

empresa. En muy pocas ocasiones será el responsable de la implementación de

los procesos, a pesar de poseer buenos conocimientos o una gran afinidad con las

TI. El analista de procesos debiera de tener una gran habilidad en materias de

desarrollo organizacional y técnicas de comunicación. Pero sobre todo es, como

su rol lo indica, analista. Se espera un gran dominio de la notación BPMN y como

coordinador entre personas de negocio y de TI es un rol clave en cualquier

proyecto de BPM. La calificación más importante de un analista de procesos no es

el comunicar sino el captar o escuchar a los participantes. Buenos analistas de

negocio sienten la necesidad de querer atender todo en detalle. Al mismo tiempo

poseen la empatía, como para poder ponerse en lugar del cliente y representar

sus inquietudes. No se les debe escapar ningún detalle, pero al mismo tiempo

deben poseer un buen sentido de abstracción y pueden reducir los modelos a su

esencia.

7.1.3.2.4.11.2 Ingeniero de Proceso

El ingeniero de procesos desarrolla e implementa un modelo TO-BE a partir de la

especificación y el diseño AS-IS validado por el o los analistas de procesos. El

diseño TO-BE debiera realizarse en el mismo entorno (Process Engine o BPMS)

en donde se implementaran los procesos. Un programador puede asumir el rol de

ingeniero de procesos, si la solución será un desarrollo propio por medio de

programación. El ingeniero de procesos también puede actuar como asesor en la

fase de modelamiento de la lógica operacional (Entender).

7.1.3.2.4.12 Equipo de desarrollo IT

Este grupo lo componen principalmente expertos en la interconexión de sistemas

(EAI). Ellos proporcionarán experiencia y trabajo con cada uno de los otros

equipos para asegurarse que las interfaces de proceso de los diversos sistemas

host se ejecutan exitosamente.

7.1.3.2.4.13 Equipo de gestión de documentos

Este grupo estará compuesto por expertos en gestión de documentos, y el

personal de negocios que entiende cómo el flujo de documentos se utiliza con los

procesos de su área de negocio. Este equipo va a trabajar y aportar su

experiencia a todos los equipos de otros procesos en el proyecto, para asegurar

que los documentos e imágenes se integran satisfactoriamente con cada proceso.

Nota: Una vez definida la estructura del equipo del proyecto, se les debe informar

a los participantes la decisión tomada.



empresas

109

7.1.3.3 Paso 3: Workshops ejecutivos

La agenda de estos Workshops debe cubrir los siguientes temas:

Definir alcance del proyecto

Identificar las metas del proceso

Lista de verificación

Identificación y clasificación de los stakeholders

Lista completa de los modelos de procesos (Si existe revisarla, si no hacerla)

Identificación de procesos de negocio (matriz de selección de procesos de

negocio)

Análisis inicial de los procesos de negocio, incluyendo métricas de alto nivel.

(matriz de valor del proceso)

Aceptación de las salidas de la fase de ENTENDER

Cada uno de estos se examina con más detalle a continuación:

7.1.3.3.1 Paso3.1: Definir alcance del proyecto

Cabe resaltar que cuando se define el alcance de un proyecto BPM se hace de

igual manera a como se haría en cualquier otro tipo de proyecto, sin embargo, una

cuestión primordial que hay que responder a la hora de definir el alcance del

proyecto es: ¿Nos sentimos seguros que, con el alcance previsto inicialmente,

podemos entregar los resultados esperados por los stakeholders? Otro de los

aspectos que se debe dejar muy claro en este momento del Workshop es: Que

NO está incluido en el alcance del proyecto.

Es esencial que el proceso (s) a examinar dentro del alcance sea entendido y

completado en su totalidad, así esto represente cruzar el departamento, la unidad

de negocios o incluso los límites de los stakeholders.

7.1.3.3.2 Paso3.2: Identificar las metas del proceso

Es necesario identificar las metas del proceso para que el proyecto pueda ser

planificado apropiadamente. Si las metas del proceso no están claras, la

organización no tendrá la información suficiente para definir y establecer el

proyecto de manera adecuada.

Las metas del proceso deben tener en cuenta las necesidades de los stakeholders

y un benchmarking frente a los competidores.

Hay varias entradas en la identificación de las metas del proceso, entre las que se

incluyen:



empresas

110

Definición de los indicadores de medición utilizados para evaluar el rendimiento

de los procesos actuales y planificados para ser utilizados en el futuro

Determinar el nivel de mejora que se espera – si es dirigido a una mejora del

80% es totalmente diferente a si se dirige a una mejora del 10%, y el enfoque

será muy diferente. ¿Tal vez el tiempo que tarda el proceso debe ser más

largo, con el fin de aumentar la calidad? Todo esto tiene que estar muy bien

documentado, entendido y acordado por todos los stakeholders del proyecto

Identificar las medidas de rendimiento del proceso, empezando con las

medidas del rendimiento esperado por los stakeholders y finalmente

retrocediendo para obtener las medidas de rendimiento de los procesos real.

Evaluando la gestión de rendimiento

La evaluación de medidas de: eficacia, eficiencia y adaptabilidad

Mantener el número de medidas de rendimiento bajo - sin duda no más de

cinco

Todas las metas del proyecto deben ser SMART (Specific, Measurable,

Achievable, Realistic and Time-related), es decir: específicos, medibles,

alcanzables, realistas y relacionadas con el tiempo.

7.1.3.3.3 Paso3.3: Lista de Verificación.

Este es un paso importante en la gestión de las expectativas de los stakeholders y

la validación del alcance del proyecto. Desde una perspectiva de proyecto y de

negocios, es importante entender lo que se debe lograr para que este proyecto

tenga éxito. Los criterios de la lista de verificación se determinan aquí aplicando la

'Prueba de vino tinto‟, la cual consisten en realizar la siguiente pregunta:

Han pasado seis semanas desde la finalización del proyecto y usted está

sentado en su casa delante de la chimenea con un vino tinto y reflexionando

sobre el proyecto. Usted decide que ha sido un éxito notable. ¿Por qué?

La respuesta a esa pregunta proporcionará la lista de verificación. Las razones

dadas durante el Workshop deben cubrir tanto los resultados del proyecto como

los resultados de negocio.



empresas

111

7.1.3.3.4 Paso 3.4: Lista Completa de procesos.

El modelo completo de procesos ofrece una visión general de los principales

procesos de la organización. Si este ya se ha creado, entonces se debe validar

para confirmar su importancia en la unidad de negocio examinada. Si no existe,

entonces, analice los siguientes conceptos claves obtenidos en el Anexo4:

formulario 1 – Pre fase.

Directrices de los procesos

Modelos de los procesos

En caso tal que en el formulario 1 tampoco haya sido diligenciada esa información,

a continuación se darán las pautas claves para obtenerla.

Directrices de los procesos

Estas son las directrices que deben ser formuladas para los procesos:

Propietario del proceso

Alcance de los procesos

Selección de un método de modelamiento

Selección de un modelador de procesos y herramientas de gestión

Método de gobernabilidad de los procesos

Externalización de procesos, cual es el lugar donde la organización tomará una

decisión de si debe o no externalizar procesos, si decide hacerlo, es importante

precisar lo siguiente:

Tipo de procesos a externalizar (razones principales)

Tipo de procesos que no se externalizaran (razones principales)

Criterios mínimos que se deben cumplir (por ejemplo, seguridad, SLAs)

Aspectos que deben tenerse en cuenta (por ejemplo, personas

involucradas)

Los modelos de proceso

La arquitectura de procesos también debe contener una representación gráfica de

alto nivel de representación de los procesos. Una buena manera de hacerlo es

mediante el esquema de organización del proceso y ver una lista completa de

procesos.

Vista de procesos de la Organización

La vista de procesos de la organización representa la vista de más alto nivel de la

organización desde una „perspectiva de procesos‟. La siguiente figura representa



empresas

112

una compañía de seguros. La representación o agrupación de los procesos por lo

general se muestra en tres niveles:

1. Procesos estratégicos- Este nivel representa los procesos estratégicos, que

deben garantizar que los procesos subyacentes se cumplan, y continúen

cumpliendo con los objetivos especificados

2. Procesos centrales- Este nivel representa el núcleo, o las principales

actividades de negocios de la organización.

3. Procesos de apoyo - Este nivel representa los procesos no esenciales, que

apoyan los procesos centrales de la organización.

Grafica 25: Vista de Procesos de la organización [16]

Una lista completa de procesos que se ejecutan dentro de “Retención”:

Renovar las Políticas

Abordar las quejas

Ganar de nuevo negocios perdidos

El diagrama de „Vista de procesos de la organización‟ tiene varios propósitos:

Debe ser usado para describir los procesos de la organización a todos los

funcionarios y los stakeholders.



empresas

113

Podría ser colocado en una posición destacada en toda la organización y tal

vez en el sitio de intranet de la organización (algunas organizaciones lo han

usado como su página principal de la intranet)

Ayudará a los altos ejecutivos y sus directivos y empleados a entender las

principales actividades y las prioridades para la organización desde una

perspectiva de proceso, y proporciona un enfoque de BPM dentro de la

organización.

Sin embargo, esto sólo funciona cuando la vista de alto nivel tiene información

relevante subyacente y es adoptada y utilizada en toda la organización.

El beneficio del desarrollo de una „vista de procesos de la organización‟ es que

tiene un modelo de alto nivel de la organización que puede ser utilizado para

vincular los procesos de nivel inferior. Esto permite a los administradores de la

organización definir las áreas de procesos críticos sobre los cuales tal vez desee

centrarse. También ayudará a asegurar que todos los ejecutivos clave, los

stakeholders y participantes en el proyecto de BPM tienen un lenguaje común y

entendido.

Lista Completa de procesos

Para cada uno de los grupos de procesos identificados en la „vista de procesos de

la organización‟, una lista de procesos debe ser creada. En las fases de Entender

e Innovar, cada uno de los procesos de la lista se puede describir con mayor

detalle (modelos de procesos y modelos detallados del proceso).

Durante el desarrollo de estos modelos de procesos, es muy útil la captura de

diversas métricas con respecto a la unidad de negocio de la organización y los

procesos - Por ejemplo, capturar el número de personal involucrado en cada

proceso o grupo de procesos, el porcentaje de esfuerzo empresarial que participan

en el proceso, el valor de las ventas y el volumen de operaciones aplicables. Esto

ayudará a dirigir el equipo del proceso en la selección de procesos o áreas de la

organización para iniciar las siguientes fases del Framework.

Para un proyecto individual, la realización de un modelo completo de procesos

proporcionará ayuda con la realización del siguiente paso - "Identificar los

procesos de negocios”, que son sub-procesos del modelo completo de procesos.

La mejor manera de obtener esta información es a través del Workshop ejecutivo.



empresas

114

7.1.3.3.5 Paso3.5: Identificar los procesos de negocios

Antes de iniciar un proyecto BPM, es necesario identificar todos los procesos

individuales de negocio relevantes dentro de la unidad de negocio que se

examina. Es importante asegurarse de que los procesos han sido identificados

previamente en la lista de los procesos de negocio completa. Aunque hay muchos

métodos para lograr esto, hemos esbozado aquí sólo uno; la matriz de selección

de procesos, ya que es la que se usa de forma regular y con gran efectividad.

La matriz de selección de Procesos (PSM) es una forma de mostrar, por lo general

en una sola página, todos los procesos de negocio dentro de la unidad de negocio.

Por otra parte, la PSM es una manera ideal de comprender y mostrar el nivel de

complejidad del proceso, el número de procesos y las métricas de proceso de alto

nivel dentro de la empresa.

El eje vertical (procesos principales) proviene de la lista de procesos completa,

desarrollado como parte del Paso 3.4. El eje horizontal (escenarios) representa la

dimensión que proporciona un análisis más detallado de los procesos enumerados

en el eje vertical. Esto variará de una situación a otra, puede ser representado por

los productos de la organización, métodos de pago, métodos de distribución,

dispersión geográfica, las unidades de negocio y así sucesivamente. La cuestión

más importante es asegurarse que la celda en la intersección del eje horizontal y

el eje vertical representa un proceso de negocio individual.

Si una etapa del proceso es única, el objeto del proceso debe ser especificado

bajo ese escenario (como en el Proceso 1, el producto 1 y un proceso principal A

de la Grafica 26. Si no hay ninguna etapa del proceso bajo un escenario, entonces

no debe ser objeto de proceso especificado (por ejemplo, El producto 1 no tiene

un proceso asociado al proceso principal C). En el caso de que la etapa del

proceso sea la misma para varios escenarios, el objeto de proceso debería

extenderse a través de estos escenarios (como en el proceso 5, donde el Producto

1 y el Producto 2 comparten el mismo proceso relacionado al proceso principal B).

Este suele ser el caso cuando:

Los escenarios no tienen ningún impacto en la singularidad de la etapa del

proceso.

Los procesos se llevan a cabo por las mismas unidades de negocio / roles

Los procesos son apoyados por las mismas las aplicaciones de TI.



empresas

115

Una vez más, la mejor manera de obtener esta información es a través de un

Workshop ejecutivo con los gerentes del proceso adecuado y la asistencia de los

líderes de equipo.

Grafica 26: Matriz de selección de procesos [16]

7.1.3.3.6 Paso3.6: Analizar los Procesos de Negocio.

La selección de los procesos a incluir en el alcance de un proyecto suena muy

fácil, sin embargo es fundamental y en ocasiones difícil de corregir la primera vez

(en caso que se haga mal). La mayoría de organizaciones seleccionan los

procesos de forma intuitiva, basándose en los problemas de un proceso. Si bien

esto es a menudo un punto de partida razonable, agregar un análisis objetivo del

proceso de selección es mucho más importante.

Durante la realización de la matriz de selección del proceso (PSM), es importante

recopilar métricas de las partes apropiadas de la cadena de valor y los procesos.

Las métricas adecuadas para cada proceso, / mercado, / producto son las

siguientes:

El número de personas involucradas en la ejecución de un proceso

El número y valor de las transacciones

Las cifras de calidad (por ejemplo, la satisfacción del cliente, re trabajo, las

quejas entre otros) que equivalen a procesos de áreas problemáticas



empresas

116

Los indicadores en el tiempo de procesamiento, el tiempo de proceso y tiempo

de espera, que puede ser equivalente a los cuellos de botella del proceso.

Estos servirán de orientación para cuando inicie el análisis más detallado. Por

ejemplo, si los procesos 3 y 5 en la Grafica 26, toman el 70 por ciento de los

recursos de proceso, cualquier mejora en estos procesos puede hacer una

diferencia sustancial en los costos de la unidad de negocio. Por otro lado, si el

Proceso dos (2) sólo ocupa un 4% de los recursos, entonces las mejoras en los

procesos no harán una gran contribución a los beneficios económicos de la unidad

de negocio.

Las métricas recogidas deben ser registradas en el PSM, que se convierte en una

poderosa "imagen" para la gestión y el proyecto.

El PSM, sin embargo, no es el único procedimiento involucrado en el proceso de

priorización, pues factores como la calidad y el reproceso también son insumos

clave. Otra matriz que agregara una dimensión interesante a el análisis de los

procesos de negocio es: the Keen Process Worth Matrix (Keen, 1997:. 26), que

se muestra en la Grafica 27

Grafica 27: Matriz de Valor de Procesos [16]

Esta es una manera útil de determinar en qué procesos de negocio invertir, sin

embargo, no siempre es una matriz fácil de completar - los procesos pueden ser

difíciles de clasificar. Las definiciones utilizados por Keen, son las siguientes:

Activos - «cualquier proceso que devuelva más dinero a la empresa de lo que

cuesta, es un activo" (Keen, 1997:.25). Sin embargo, debe asegurarse de que la

determinación de costos se calcula correctamente - sin duda no utilizan la

definición de la contabilidad tradicional.

Pasivo - lo contrario de un activo.



empresas

117

Identidad- Define la organización por sí misma, sus clientes y stakeholders.

Establece la diferencia entre la organización y sus competidores. Por ejemplo,

McDonald tiene una reputación basada en un servicio rápido y consistente, de

manera similar, la reputación de Seguros AAMI es por el agradable servicio

personalizado. Estas son las percepciones de marketing que estos procesos

deben cumplir. Son procesos que definen la identidad de las dos organizaciones.

Estos procesos de identidad son un subconjunto de los procesos "fundamentales"

mencionados anteriormente en la vista de los procesos de la organización.

Prioridad - Estos procesos apoyan firmemente la eficacia de los procesos de

identidad. Los clientes no suelen ver esto, pero si fallan entonces el impacto es

inmediato y visible para los stakeholders. En el ejemplo de McDonald, estos

procesos serian incluidos en los que son parte de la cadena de suministro para

entregar la materia prima de los productos vendidos.

De fondo, Estos procesos apoyan las actividades diarias de las operaciones

dentro de la organización, e incluyen aquellos como administración, recursos

humanos y gestión de documentos. A veces son muy visibles y por lo tanto tienen

la atención de la administración. Sin embargo, es un error invertir en estos

procesos antes que en los procesos de identidad y prioridad. La mayoría de las

organizaciones destinan estos procesos para los proyectos de BPM, ya que

pueden ser victorias fáciles.

Encomendados -Se trata de procesos impuestos a la organización por factores

externos, como la legislación y el cumplimiento. La organización no tiene más

remedio que llevarlos a cabo. Por lo general, se trata de procesos pasivos, y rara

vez añaden valor directo a la organización.

Si bien la matriz de valor de procesos inicial puede ser creada en un proyecto de

BPM, no debería ser un ejercicio de una sola vez. La matriz debe ser añadida a la

arquitectura de procesos y refinada durante los proyectos y actividades futuras de

negocios. Los procesos pueden pasar de una categoría a otra con el tiempo. Esto

es causado generalmente por el entorno empresarial, las decisiones de gestión, el

comportamiento del personal y la organización, y también podría ser causado por

negligencia no intencional de un proceso.

Tras recopilar la información en el PSM, La matriz de valor de procesos, las

métricas asociadas y las metas del proceso, se toma la decisión de eliminar,

seleccionar y priorizar el orden en que los procesos se abordaran en la fase de

Entender.



empresas

118

Al completar este análisis, la organización debe centrarse en la generación de

valor - la creación de beneficios en el rediseño de un proceso no necesariamente

crea valor: "El beneficio es un concepto de gestión, el valor es un concepto

económico" (Keen, 1997:75).

Hay ejemplos de organizaciones que obtuvieron beneficios sustanciales del

rediseño de sus procesos y, sin embargo se redujo su ganancia. Las mejoras en

los procesos no se traducen necesariamente en beneficios para las empresas. Por

ejemplo, un proceso puede ser rediseñado para ser más eficiente, y sin embargo

es de poco beneficio para el cliente o no agrega ningún valor / ganancia para la

empresa.

Los procesos que deben ser seleccionados para un proyecto de rediseño de BPM

son los que agregan valor a la organización.

7.1.3.3.7 Paso3.7: Aceptar salidas de la fase de Entender

Una vez más, se trata de la gestión de expectativas de los stakeholders. Es mucho

mejor informar (y por lo tanto establecer las expectativas) de los resultados a los

stakeholders apropiados antes de que la fase comience, en lugar de completar la

fase y no entregar lo que ellos esperaban. Si el equipo del proyecto no establece

las expectativas, los stakeholders harán las suyas propias-y las dos casi nunca

coinciden.

Los resultados para la fase de Entender incluirán lo siguiente:

Una lista completa de los modelos de procesos

Una lista completa de sub-procesos

Los modelos de los procesos actuales a un nivel de detalle suficiente para que

la fase de Innovar se complete

Métricas adecuadas y suficientes para establecer una base para mediciones

comparativas con el proceso futuro

Una lista de problemas del proceso principal, según lo determinado por la

empresa

Identificación de las prioridades de innovación

Un informe sobre la fase.

7.1.3.4 Paso 4: Aceptar y entregar el plan de negocios

Antes de hacer cualquier otro paso es importante acordar y planificar el traspaso a

la empresa. La mayoría de los proyectos fallan la prueba definitiva: que la



empresas

119

empresa sea capaz y esté dispuesta a hacerse cargo del proyecto como parte del

negocio como de costumbre.

Este paso también sirve como un buen campo de pruebas para ver cómo la

gestión de los stakeholders debe ser completada durante esta fase. La gestión de

Stakeholders es siempre un tema difícil, pero siempre es mejor recibir información

al principio del proyecto y no después. Esta información permitirá los ajustes que

deban hacerse al alcance.

Cuando se crea y se acuerda una entrega del plan de negocios, los siguientes

temas deben ser abordados:

Costos del proyecto

El apoyo requerido de expertos en la materia durante el proyecto, la entrega y

los costes operativos.

Riesgos y problemas

Los gastos corrientes y los beneficios

Tiempo de entregas

Escenarios de implementación de reserva o planes de contingencia

Plan de comunicación y de implementación

La gobernabilidad y la progresividad.

Muchas veces se ven las siguientes situaciones:

Las empresas no ven la entrega como algo importante, ni que debe abordarse

en esta etapa del proyecto.

La entrega inicial acordada se modifica sin el control de cambios adecuado.

7.1.3.5 Paso 5: Desarrollar plan de implementación

La importancia de la implementación no puede ser sobre-enfatizada. Una pregunta

común es, ¿qué beneficios recibe el proyecto por el gasto de más tiempo y dinero

en la aplicación? La respuesta es simple, y en ocasiones la prueba inicial es difícil

de calcular. Una buena implementación se asegurará de que la solución propuesta

es óptima para la organización y que la organización utiliza esta solución de la

mejor manera y lo hace en el menor tiempo posible. Si la implementación no se ha

completado sin problemas, entonces uno o más de las siguientes situaciones

pueden surgir:

La solución elegida no es la óptima para la organización - esto puede ser

debido a la recolección incorrecta, incompleta o inconsistente de los requisitos,

sin embargo, se debe principalmente a la insuficiente participación de los

actores y usuarios del proceso



empresas

120

La organización no utiliza la solución de la mejor manera porque los usuarios

no están debidamente informados, capacitados y motivados

La solución no puede aplicarse de inmediato porque necesita algunas

modificaciones, lo que lleva a un plazo más largo para la consecución de los

beneficios-los cuales no serán tan grandes como deberían haber sido.

Debido a que la preparación de la implementación se inicia en la fase de

Cimientos del proyecto habrá una mayor inversión inicial, sin embargo, una vez

implementada, la solución tendrá un buen comienzo, dando resultados más

rápidos y mejores, ver Grafica 28

Grafica 28: Plan de implementación [16]



empresas

121

7.1.3.6 Paso 6: Desarrollar/terminar caso de negocio

La organización deberá utilizar la plantilla estándar del caso de negocio. Además

del contenido normal de BPM del caso de negocio, el modelo de negocio también

debe incluir lo siguiente:

Un análisis EVA (Agregar valor económico)

Preparación de propuestas internas

Documentación de los gastos operativos que no son cuantificables, los

beneficios, EVA‟s y el examen de riesgos de cada uno

Presentar pros y contras de las diversas opciones

Usar escenarios y criterios de evaluación del desempeño.

El equipo nunca debe defender recomendaciones, y sólo ellos hacen y explican

las opciones de una manera neutral y objetiva.



empresas

122

7.2 Fase de Entender

El propósito de la fase de Entender, es hacer que los miembros del equipo del

proyecto y el negocio obtengan entendimiento suficiente de los procesos de

negocios actuales para que la fase de “Innovar” pueda comenzar. Esto incluirá la

colección de métricas apropiadas para ganar más entendimiento, estableciendo

priorización para innovación/rediseño, y línea base del estado actual.

El punto crucial es que el equipo del proyecto y de negocios estén tratando de

comprender los procesos actuales- no es documentarlos con absoluto detalle. Una

vez que el proceso este claramente documentado y comprendido, DETÉNGASE:

Esto es suficiente detalle.

Hay varias situaciones a tener en cuenta durante esta fase:

"Entender" lo que realmente ocurre, y asegurar que lo que está documentado

refleja la situación actual "(AS-IS) tal cual" y no una situación "como si" ("TO-

BE").

Garantizar que los procesos están siendo entendidos (modelados) y se hayan

finalizado en una verdadera base "completa".

Asegurar que el personal se sienta cómodo dentro de los Workshops y no se

sientan como si estuvieran siendo evaluados, a menos que este sea el caso,

los participantes pueden decirte lo que piensan y lo que tú oyes no transmita

sus conocimientos, o pueden proporcionarte información incorrecta.

Asegurar que los plazos se establecen en relación con la cantidad de tiempo

que pasó en la comprensión o el modelado de un proceso particular, y entregar

este periodo de tiempo - en otras palabras, establecer algunos hitos y

actividades de la "caja de tiempo". Si usted no fija metas, corre el riesgo de

sobrecostos de tiempo del Workshop y perder tiempo valioso en temas de

negocios si el experto en la materia entra en demasiados detalles.

Utilizar el principio de pareto (regla 80/20) para decidir cuándo se está tocando

el punto de no retorno. Siempre pregunte, "¿Tenemos suficiente información

ahora y podemos parar?"

Algunas de las razones a favor y en contra del modelado de procesos en la fase

“Entender” figuran en esta lista.



empresas

123

7.2.1 Razones a favor:

Razones en contra: Para obtener una comprensión común, y un lenguaje

común del problema.

Para mostrar las deficiencias de la situación actual.

Para apoyar la aceptación de la “descongelación” para el proyecto.

Para permitir la evaluación de la integridad del proceso de innovación.

Modelos producidos se pueden utilizar como documentación del proceso si

hay poca necesidad de cambiarlo.

Las personas se acostumbran a pensamiento y modelado de procesos.

Para establecer una base para la relación de los procesos con la

organización, y el personal de TI.

7.2.2 Razones en contra:

La situación actual como haya sido modelada se vuelve obsoleta tan pronto

como los procesos de innovación sean diseñados e implementados.

Siempre existe el peligro de tener un diseño del proceso con “enfoque

limitado”, lo que pone restricciones en el pensamiento para la innovación de

procesos.

Toma tiempo, requiere un gran compromiso de recursos y dinero, en la

mayoría de los casos es un procedimiento complicado con una curva de

aprendizaje pronunciada en la primera instancia.

Existe el peligro de hacer demasiado y ahogarse en los detalles.



empresas

124

FASE DE ENTENDER

7.2.3 Entradas de esta fase: Lista de stakeholders asociados con el proyecto. Acta de información y aceptación de los stakeholders Matriz de selección de procesos de negocio Metas del proceso Matriz de valor del proceso Lista de procesos priorizados Documento de gestión del proyecto Caso de negocio Inicial

PASOS :

Grafica 29: Pasos de la fase Entender (Tomada y adaptada de Business Process

Management - Practical Guidelines Successful Implementations)

7.2.4 Salidas de esta fase: Modelos de procesos AS-IS. Análisis de métricas y de niveles actuales de rendimiento. (ver Paso 4) Matriz de Capacidad de personas. (ver Paso 5) Documentar que trabaja bien y que podría trabajar mejor. Anexo 12: Un informe final de la fase.



empresas

125

7.2.5 Pasos




En esta fase, las principales actividades de comunicación relacionadas con el

suministro de información a los stakeholders y las personas dentro de la

organización sobre el proyecto, son los objetivos, y cómo y cuándo la gente va a

participar en la fase de Entender. Por ejemplo, es durante esta fase que el

proyecto comienza a tener mayor visibilidad dentro de la organización, porque el

personal está empezando a ser específicamente involucrado en los workshops del

proyecto y formulan preguntas sobre sus actividades actuales en el proceso y las

métricas asociadas. Esto puede generar preocupaciones con respecto al futuro rol

de algunos dentro de la organización, y si su trabajo va a continuar. Si estas

inquietudes no se resuelven pronto y satisfactoriamente, será difícil obtener el

apoyo de la organización y su gente.

El equipo del proyecto debe crear un ambiente en el que la gente se sienta a gusto

en proporcionar la información necesaria para el proyecto y los workshops. Las

personas deben estar cómodas al compartir sus verdaderos problemas sin temor a

ningún tipo de culpa.

7.2.5.2 Paso 2: Revalidar el alcance

Es esencial revalidar el alcance de un proyecto BPM de forma continua y ahora es

un momento ideal - antes del comienzo de los workshops de la fase de entender.

Puede ser útil ir a las organizaciones de distintos stakeholders (proveedores,

clientes y canales de distribución) y ver el modelo de sus procesos para entender

la forma en que encajan con el nuestro, y cómo los procesos pueden mejorar sus

procesos de negocio. Los beneficios de esta actividad son las siguientes:

Ayudar a la organización a obtener una comprensión más clara de los

procesos, lo que le permite ser más eficaz en la innovación del proceso.

Proporcionándole la capacidad de sugerir al stakeholder (s) que su proceso (s)

debe ser rediseñado, y así trabajar con ellos para entender cómo esto se

podría lograr e integrarlo completamente con su proceso (s).

Permitiendo a la organización minimizar la duplicación y desconexión, y reducir

y mejorar las relaciones entre los procesos organizacionales y los de sus

stakeholders.



empresas

126

7.2.5.3 Paso 3: Workshop de modelo descriptivo del proceso.

Es importante que el patrocinador del proyecto y las empresas tengan una clara

comprensión de porqué esta fase es necesaria. Rara vez hemos encontrado

alguna resistencia a la fase de Entender, pero nos ha pasado que los ejecutivos

piensan que "¡sólo le tomará un par de horas modelar todos los procesos!".

Si encuentra resistencia en los participantes y la necesidad de explicar por qué la

existencia de la fase de Entender es necesaria, aquí se brindan algunas razones:

Para asegurar un entendimiento común de los hechos del proceso(s) actual, no

lo que la gerencia cree que sucede.

Para analizar si la mejoría es posible, o incluso necesaria. Algunos procesos

pueden necesitar mejoras (pequeños cambios), mientras que otros pueden

necesitar ser rediseñados utilizando básicamente el mismo enfoque, pero sólo

hacerse más eficientemente, mientras que otros pueden necesitar innovación

con un enfoque totalmente nuevo (tal vez de diferentes industrias, o tomar los

pasos en el valor de la cadena), y sin embargo otros no necesitaran ningún

cambio en absoluto.

Para ayudar en la comprensión de la interacción de procesos y el impacto

sobre otros procesos dentro de la organización - por ejemplo, de un

departamento a otro.

Para comprender y documentar las interfaces con sistemas legados y

aplicaciones existentes, lo cual será esencial para la fase de Innovar sobre

todo si se trata de la automatización de procesos.

Antes de que comiencen los workshops es importante tener una clara

comprensión de por qué se está llevando a cabo el modelado de procesos y

garantizar que al finalizar los modelos sean relevantes para el propósito deseado.

No buscar la perfección, esforzarse por tener modelos que sean lo suficientemente

completos, relevantes, y "con un propósito". Siempre tenga en cuenta el principio

de pareto (la regla del 80/20), ya que "lo perfecto es enemigo de lo bueno", y por

ese motivo recomendamos que siempre que inicie un Workshop de levantamiento,

se asimile la siguiente oración:

<<“¡Todos los modelos de procesos son incompletos – pero algunos tienen

sentido!”>>

Este principio se refiere a que nunca deberíamos intentar capturar o modelar todo

el detalle desde un principio; pues sencillamente no resulta.



empresas

127

Al iniciar el workshop de levantamiento, se debe comunicar claramente que el

objetivo de la primera reunión es levantar una vista muy generalizada y resumida

del proceso. Para esta primera iteración se declaran los siguientes objetivos:

Se quiere definir el proceso de principio a fin.

Se quiere captar el proceso en no más de ocho pasos.

Solo se quiere representar el flujo normal.

Solo se quieren identificar los roles regulares que intervienen en el proceso.

No se quieren levantar ineficiencias, problemas o propuestas de mejora.

Si usted aclara al principio del workshop estos puntos, estará en condiciones de

levantar un proceso de negocio en forma resumida en no más de 45 minutos, sin

embargo hay que ser perseverante cuando alguno de los participantes se desvíe y

caiga en el detalle.

Este Workshop también tiene una importancia psicológica pues los integrantes

saldrán de la reunión con una sensación de haber logrado algo y de que se puede

observar un proceso de negocio desde una perspectiva aérea. Entonces usted

quedará con una base, un proceso en el que ha definido su alcance de principio a

fin pasando por las principales etapas.

Nota: “A partir de este momento se especificará como el modelado de procesos se

basará en el estándar de BPMN por lo que se empezará a usar simbología propia

de dicho estándar, así que como mencionamos anteriormente es totalmente

necesario que para entender y aplicar apropiadamente nuestro framework el

usuario tenga conocimientos previos de BPMN.”

7.2.5.3.1 Paso3.1: Realizar Modelos de procesos AS-IS

Antes de hacer un modelo de procesos AS-IS es necesario hacer un modelo

mucho más general, es decir, un modelo de procesos descriptivo; el cual describe

la lógica de negocio lo más compacta posible. El objetivo principal de este modelo

es describir el alcance que tienen los procesos de principio a fin.

Este nivel sirve como introducción y definición de alcance a todos los

participantes, pero principalmente a los responsables de áreas o procesos en

general como el administrador del proceso o propietario del proceso.

Los principales objetivos relacionados con un modelo de procesos

descriptivo son:

Definir el alcance de los procesos (Limites definidos en términos desde/hasta)



empresas

128

Asignar las responsabilidades y recursos del proceso

Definir los principales KPI‟s, por ejemplo tiempos de ciclo máximo por proceso

Requerimientos generales que se esperan para mejorar el rendimiento de los

procesos.

Con el objetivo de cumplir los requerimientos anteriormente mencionados, el

modelo debería entenderse fácilmente y poder interpretarse por personas que no

tienen muchos conocimientos de BPMN. El slogan que se utilizará como principio

para diseñar este modelo será:

“¡Don‟tmake me think!” (No me hagas pensar)

Este refrán puede parecer exagerado, pero no lo es. En este modelo del proceso

debe reconocerse claramente cuál es el valor que se genera para el cliente.

Ningún proceso puede captarse completamente en una vista resumida, pero si se

puede abstraer lo más importante y resumirlo en un diseño gráfico de no más de

una hoja tamaño carta; ese será el desafío del nivel descriptivo.

Si se pretende desarrollar modelos de procesos fáciles de entender, no se puede

utilizar toda la simbología BPMN ya que no se puede pretender que los

participantes del proyecto la entiendan de forma intuitiva. El precio a pagar al

restringir la simbología es perder expresividad, es decir el modelo es menos

preciso, por lo que si avanza en el documento encontrará una proposición de los

objetos, que a nuestro juicio se prestan para modelar el nivel descriptivo.

El segundo compromiso que se admitirá en modelos de nivel descriptivo, es el de

desistir en completitud en cuanto a la representación de la lógica o de la

semántica de los procesos.

Nota: “En el nivel descriptivo rige el siguiente principio: En lo posible mantener las

reglas sintácticas y si es necesario tolerar inconsistencias semánticas”

Para el correcto desarrollo de la fase Entender se deben tener en cuenta algunas

reglas en cuanto a BPMN que se presentaran a continuación, estas serán de gran

ayuda para el desarrollo de las actividades de esta fase.

Restricción de la Simbología

La norma BPMN cuenta con más de 50 símbolos. En el nivel descriptivo no

necesitamos tantos símbolos y no se puede esperar que todos los usuarios



empresas

129

conozcan la taxonomía de estándar BPMN, razón por la cual solo se utilizara un

subconjunto de todos estos elementos.

Pool y Lanes en el nivel descriptivo

Algunos de los implicados en los procesos pueden hacer preguntas que lleven al

detalle y por consiguiente al uso de más simbología BPMN, por esta razón se

decidió <<por lo general>> no usar más de un pool en el modelo descriptivo. En

algunas ocasiones se hace una excepción, por ejemplo cuando un cliente externo

interactúa con el proceso de la empresa, sin embargo lo que a la organización le

interesa en estos momentos es conocer cómo funciona la lógica de su proceso

interno, es decir, sin tener en cuenta al cliente.

Actividades y subprocesos en el nivel descriptivo

La siguiente pregunta que nos debemos hacer es con respecto al nivel descriptivo

es sobre el uso de actividades y subprocesos. Se podría reducir este nivel solo a

la representación de subprocesos, pero la realidad muestra que esto no siempre

es posible, por lo que las limitaciones serán básicamente la exclusión de tipos de

Tareas (manual, usuario, servicio, enviar y recibir, script o regla de negocio) o de

utilizar Marcadores, donde solo habrá una excepción, la del tipo “loop” pues es

una marca relativamente intuitiva y que se entiende sin mayor explicación.

Grafica 30: Marcador tipo loop [16]

Los subprocesos representan una lógica abstraída en procesos complejos y se

prestan muy bien para representar un conjunto de actividades que representan

una finalidad delimitada. Otra cuestión que puede surgir es si es necesario

modelar la lógica de los subprocesos que se encuentren cerrados. Por lo general

también desistimos de ello pues no es el objetivo del nivel descriptivo conocer la

lógica de negocio.

Gateways en el nivel descriptivo

Cuando existen “tomas de decisión” en el transcurso del proyecto se podrían

modelar fácilmente utilizando gateways, pero se desistirá de esta casuística en el

nivel descriptivo. Lo que se quiere representar en este nivel es el <<Happy

Path>> o dicho en español el caso deseado o el caso normal. En la mayoría de los



empresas

130

casos no es necesario mostrar en este nivel, las variaciones que puedan existir.

Aunque dependiendo del proceso de negocio puede que se haga necesario

representar en este nivel flujos alternativos, por ejemplo cuando un cliente puede

escoger varios productos o si el inicio del proceso se da por diferentes eventos de

entrada.

En estos casos recomendamos utilizar en este nivel los siguientes objetos de

Gateways:

Grafica 31: Bifurcación [16] Grafica 32: Unión [16]

Grafica 33: Sincronizar [16] Grafica 34: Paralelizar [16]

Grafica 35: Y/O [16]



empresas

131

Eventos en el nivel descriptivo

Con el objetivo de marcar el principio y el fin de un proceso se recomiendan utilizar

en el nivel descriptivo eventos de inicio y de término y aunque se podría desistir de

usarlos se perdería semántica pues no sería claro que suceso inicia el proceso y

que tiene que ocurrir para que termine de forma normal. Justamente una de las

características que queremos representar en el 1er nivel, es el principio <<end-to-

end>> y sin eventos es difícil de mostrar.

También son permitidos eventos intermedios y eventos de mensajes y de tiempo,

porque su simbología es bastante auto explicativa.

Datos y artefactos en el nivel descriptivo

Otra de la simbología permitida en este nivel del proceso son los artefactos, como

por ejemplo las entradas y entregables de cada actividad y el tipo de comunicación

entre los participantes del proceso.

Análisis del Nivel descriptivo

Luego de haber levantado y documentado el proceso en el nivel descriptivo

podemos continuar con el análisis de dos maneras:

Comenzar con un levantamiento en detalle de la situación actual del

proceso (AS-IS)y pasar al segundo nivel de descomposición, y/o

Entrar en una etapa de análisis de mejora a partir de la documentación

levantada.

La primera opción cuyo resultado es un modelo del proceso actual detallado (AS-

IS) necesita de una nueva caminata o workshops con los conocedores del proceso

a los cuales se les pedirá que no se cohíban del detalle, pues es exactamente eso

lo que queremos reflejar en este nuevo modelo (contrario a lo que se hizo en el

levantamiento del proceso a nivel descriptivo).

Para la creación del modelo del proceso actual (AS-IS), se tomará como base el

libro BPMN 2.0 y su framework donde se recomienda incluir los casos de

excepción, para que este modelo sirva al usuario del negocio como guía o manual

de procedimiento en su trabajo diario.

El proceso de negocio es por lo general un complejo intercambio de actividades

entre personas y sistemas, el analista de procesos tiene que comprender como se



empresas

132

realiza el trabajo en su máximo detalle y como interactúa el flujo de trabajo con los

sistemas y los usuarios de negocio.

Para la compresión y ayuda de los usuarios en el proceso de creación del

modelo, los analistas deben tener una visión general sobre el proceso y una

particular para el usuario, pues el solo desea ver su área de responsabilidad. Este

modelo de procesos tiene que ser lo suficientemente preciso pero no debe llevar

un grado de complejidad tan alto que se torne inentendible; es por esto que A

CADA ROL SE LE ASIGNA UNA VISTA PROPIA DEL MODELO COMPLETO,

esto reduce la complejidad de los roles de negocio, debido a que cada uno tiene

su propia responsabilidad sobre solo una parte del proceso entero, si a cada tipo

de usuario se le presenta o modela su propio proceso, es decir sólo visto desde su

perspectiva, se va a identificar con él y va a aceptarlo. El usuario sabe lo que tiene

que hacer, cuando es su turno o si tiene que esperar a un evento proveniente de

otro lugar, así se evita que el usuario tenga que hacer un filtro y reconocer sus

propias tareas. Finalmente la integración de todas estas vistas es lo que hace tan

complejos estos diagramas, en cambio los roles de analistas y del ingeniero son

técnicos y ellos si requieren ver el “todo” para implementar un proyecto BPM que

es transversal.

¿Cómo se lograra diseñar un modelo de proceso con estas vistas diferenciadas?

El rol principal que debe juntar este rompecabezas es el analista de procesos. Él

tiene que entender a cabalidad BPMN y tiene que ser capaz de modelar el

proceso desde la perspectiva de cada uno de los participantes. Él tiene que

levantar y administrar el modelo del proceso básico (que fue creado

anteriormente) y llevarlo hasta el diseño técnico (AS-IS).

Esto puede suceder aplicando los siguientes pasos:

Separación de los lanes en pools

Modelamiento del proceso desde la perspectiva de cada uno de los

participantes. Esto debe hacerse con el dueño del proceso y los usuarios de

negocio.

Cabe aclarar, que para administrar e ir integrando los niveles, vistas y objetos

técnicos es necesario contar con el apoyo de una buena herramienta, sobre todo

que ofrezca la funcionalidad de filtrar, ocultar y desplegar, pools, artefactos etc.

Antes de iniciar este proceso se debe constatar que la organización del proceso

en sí, no está mal, pero que hay pérdidas de valor al no contar ningún tipo de



empresas

133

apoyo de TI que permite un mejor control y transparencia en la gestión del

proceso. La misión será entonces ahora de modelar este proceso en detalle con

su lógica operacional. Levantar los modelos de procesos básicos no requieren de

mucho esfuerzo, una dos o a lo más tres sesiones cortas. No se puede hablar de

un esfuerzo doble para crear los modelos AS-IS por que se ha definido y validado

el alcance. Se debe considerar que el modelo básico descriptivo al modelo AS-IS

prácticamente no cambia.

Al realizar este modelo se debe representar la coordinación de todos los pasos

como fueron analizados anteriormente. Lo que se busca es que exista claridad y

no se pierda el seguimiento del proceso, esto evitaría ineficiencias y largos

tiempos de ciclo. Otro argumento para separar los procesos de cada unidad es

para no enredar el flujo y poder delimitar claramente las responsabilidades de

cada una de estas unidades organizacionales.

También se deben separar los lanes del modelo descriptivo en pools separados

por cada uno de los participantes, considerando algunas actividades necesarias

para la coordinación entre ellos; Se debe analizar las actividades provisorias que

se nombraron como <<por aclarar>> y de modelar en detalle cada una de las

vistas organizacionales, es decir aún se tiene bastante por analizar y modelar. Es

importante incluir los casos excepcionales que se pueden presentar.

La información requerida para modelar los procesos en detalle es suministrada en

la mayoría de casos por los usuarios de negocio, es decir de las personas que

están en el día a día de las operaciones, cada usuario describe su rol en el área a

modelar.

El modelo de procesos AS-IS es el entorno principal del analista de negocio en el

cual él analiza y documenta la lógica operacional en detalle sirve de apoyo para

elaborar una especificación para una implementación futura.

La audiencia a quienes están dirigidos estos modelos son los usuarios de negocio,

cuyo flujo de trabajo está representado en estos modelos. Los participantes son

los usuarios clave para el analista de negocio razón por la cual estos deben al

menos comprender e interpretar estos modelos. Una vez validados estos modelos

pueden elaborarse manuales de procedimientos para ellos. Nuevamente surge la

pregunta: ¿serán aceptados estos modelos por los usuarios de negocio? Según la

experiencia de los autores del libro BPMN sobre la aceptación de usuarios,

consideran los siguientes aspectos:



empresas

134

Los participantes ven sólo su propio pool y no se enfrentan a la complejidad del

proceso de negocio completo. Para que ese requerimiento se cumpla entonces

se tienen que aplicar los principios de modelamiento en BPMN y también se

necesita de una herramienta poderosa que permita abstraer la complejidad y

aislar las vistas de cada pool.

Los participantes tuvieron que ser capacitados en las estructuras

fundamentales de BPMN y cuentan con una guía que les permita consultar

aspectos metodológicos en caso de lo requieran.

Para realizar el AS-IS se debe tener en cuenta que no solo se modelan los flujos

que se deben automatizar, también se debe modelar en el proceso, las actividades

que no entraran en un sistema, se debe aclarar que los modelos de proceso casi

nunca son implementados de manera completa, la lógica operacional, de alguna u

otra forma casi siempre quedan algunas actividades o flujos que siguen bajo el

control de los seres humanos.

Modelamiento explícito de errores:

BPMN entrega dos alternativas para el modelamiento de errores en el proceso: si

una actividad suministra información que no está bien, entonces se modela con un

gateway tipo XOR-Split a la salida de la actividad. Si la actividad misma no pudo

ejecutarse, entonces se necesita un evento de tipo error. Se preguntará ¿Por qué

BPMN hace esta diferenciación?, y los errores no se modelan todas con un

Gateway tipo XOR-Split?, en un principio puede hacerlo, pero se recomienda

realizar la diferenciación por los siguientes motivos:

Cuando se levantan y documentan los procesos con los usuarios de negocio,

generalmente están pensando en lo que sucede en operaciones, en el día a

día, pero no en todo lo que puede suceder, sobre todo si pensamos en que hay

que implementar una solución técnica. Entonces se modelan las típicas faltas

que son propias del negocio con XOR-gateways. En el momento de pasar al

nivel técnico, hay que repasar todas las eventualidades para evitar que el

sistema se caiga o produzca inconsistencias. Generalmente se trata de

sucesos técnicos o eventos impredecibles. Este tipo de errores se modelan con

eventos del tipo error, se diferencian claramente de los operativos. De esta

forma se puede revisar nuevamente los modelos con los usuarios de negocio e

identificar inmediatamente los puntos por aclarar. En muchas ocasiones se

rediseña el modelo, en el sentido de que se pueden anteponer actividades de

revisiones que evitan que se produzca un error técnico y no se pueda ejecutar



empresas

135

una actividad. Finalmente quedan solo errores realmente técnicos que evitan la

caída del sistema.

Los eventos tipo error si suceden aseguran la marcha del sistema, a través de

un tratamiento excepcional. BPMN ofrece por esta razón asegurar el sistema

en diferentes niveles, a nivel de proceso, de subproceso y a nivel de actividad.

El XOR-gateways fueron concebidos para diferenciar casos, pero no solo para

diferenciar casos normales de anormales, sino también para separar los casos

positivos. Sintácticamente ni visualmente se pueden identificar en el modelo los

XOR positivos o negativos. Los eventos del tipo eventos de error son

unívocos, se identifican y reconocen inmediatamente y el sistema también los

puede diferenciar de un XOR-gateway

Subprocesos

Los subprocesos cumplen fundamentalmente con tres (3) funcionalidades:

1. Encapsular lógica compleja en un mismo plano de un modelo de procesos

2. Modularizar lógica que puede ser reutilizable en otros procesos

3. Definir un dominio en un proceso que pueda reaccionar como un todo ante

un evento.

No solo se utilizan los subprocesos para identificar un área que contiene lógica

independiente, si no para encapsular lógica en un mismo plano y de esta forma

reducir la complejidad y poder diseñar modelos en forma más compacta, razón por

la cual se encuentra en un diagrama de cualquier nivel subprocesos de varios

tipos. En BPMN se pueden combinar todas las posibilidades, desde la

representación de mapas de procesos en el nivel descriptivo, diferentes grados de

abstracción en el AS-IS hasta la realización del TO-BE. De esta forma se logra

pasar de un nivel a otro de forma más comprensible.

Teniendo en cuenta todas las consideraciones anteriores, se presenta un

diagrama donde se sintetizará en un modelo de procesos, las actividades de los

usuarios del proceso, las responsabilidades que ellos asumen y la comunicación

entre áreas involucradas. Finalmente este proceso será una salida importante para

continuar el mejoramiento de procesos, pues este modelo será la base para

implementar las respectivas técnicas de mejora, técnicas que se verán en la fase

siguiente.

A continuación, se mostrará un ejemplo de un modelo de proceso AS-IS (Elección

de un empleado nuevo)



empresas

136

Grafica 36: Modelo de Procesos AS-IS



empresas

137

La segunda opción lleva a cabo el análisis de mejora basándose en completar el análisis de métricas, analizado a con más detalle en el siguiente paso.

7.2.5.4 Paso 4: Completar análisis de métricas

El propósito de reunir las métricas de procesos de negocio es doble:

1. Para facilitar la comprensión del proceso y su impacto en la organización, y

para proporcionar la priorización para una mayor investigación.

2. Para proporcionar una base para efectos comparativos con la fase de innovar

del proyecto. Esto puede ayudar en gran medida en la terminación del caso de

negocio y determinación de las mejoras previsibles en niveles de productividad,

costo y servicio.

¿Por qué completar un análisis de métricas? Algunas de las razones incluyen la

necesidad de:

Ayudar en la comprensión de los procesos de una organización.

Producir una visión analítica de la organización

Ayudar a los miembros del equipo del proyecto en la creación de correctivas,

no sólo de soluciones oportunistas.

Ayudar en la priorización de los procesos para una mayor investigación durante

la fase de innovar

Proporcionar una base para efectos de comparación con cualquier cambio

futuro, teniendo en cuenta el pronóstico de futuros beneficios potenciales de

cualquier entorno de proceso recientemente diseñados, y para medir el

impacto de los cambios reales.

Entrar en el foco de los esfuerzos de rediseño, es decir, indicar las áreas que

tienen el potencial de proporcionar mayor impacto.

Un análisis comparativo de datos de proceso (tiempos de trabajo, los

volúmenes y costos) entre las diferentes organizaciones

Antes de que comiencen los talleres de “Entender”, una serie de parámetros

iníciales serán recogidos y analizados. Esta tarea incluye lo siguiente:

Recopilar amplia información de costos, por ejemplo – el presupuesto, los

organigramas y los listados de personal

La reconciliación de los organigramas y los listados de personal de recursos

humanos.



empresas

138

Reestructuración del presupuesto, si el presupuesto es para un área más

grande de la organización que está siendo analizada. En este caso, el

presupuesto debe ser disecado y asignado a un área específica dentro del

ámbito del proyecto.

Durante los talleres, las mediciones como sea posible se deben recoger. Como

mínimo, los siguientes deben ser incluidos:

Información transaccional - volumen, que rol completa cada tarea y el

tiempo del proceso

Los datos transaccionales para conciliar en contra de la dotación de

recursos dentro de cada área del proceso para la razonabilidad de los

tiempos de procesamiento y los volúmenes, y para identificar los procesos

adicionales

Costo de mano de obra directa por proceso, el cual se calcula en función

del tiempo de trabajo, procesar las transacciones y las tasas de

recuperación de la mano de obra

Los costes de TI y otros gastos generales asignados al proceso, en función

del tiempo de trabajo diario.

Matriz de selección del nivel de proceso

Ventas y los niveles de personal a nivel de unidad de negocio

La disección de la organización (ventas $ y volumen) a través de los

diversos segmentos de la unidad de negocio y / o alcance del proyecto

A nivel de procesos y sub procesos, la división porcentual de los volúmenes

El costo para el negocio de realizar transacciones de este volumen (por

ejemplo, los presupuestos anuales)

Nivel del proceso

Determinación de qué parte del proceso (s) medir.

Colección de los tiempos estimados de procesamiento por proceso o

subproceso, si los costos se pueden contribuir a un proceso determinado, esto

es ideal, costeo basado en actividades, si se aplican dentro de una

organización, puede proporcionar una gran cantidad de información.

Determinación de las medidas de rendimiento de los procesos, por ejemplo,

SLA, indicadores clave de rendimiento (KPI), o KPI‟s de los sub-proceso(s)

Los detalles de cómo la precisión del proceso se mide actualmente - ¿Hay

algún error de seguimiento?



empresas

139

La medición de donde ocurren los cuellos de botella

Entre los ejemplos de los tipos de métricas que pueden reunirse, vale la pena

incluir los siguientes:

Número de transacciones por medio de pago o de una región (mensual para

los últimos ocho a doce meses, para indicar las tendencias mensual o de

temporada alta)

Los tiempos de proceso para el proceso principal (es), en actividades

realizadas en fechas particulares

Número y tipos de errores

Informes pendientes, el estado y los volúmenes (cantidad y números) - las

tendencias de los últimos doce meses

Volúmenes y valores de los diversos tipos de transacciones

Los costos de mano de obra para puestos clave, incluyendo mano de obra en

los costos

Horas extras / informal / hora del contrato trabajado - la historia de los últimos

doce meses

Costo por hora, incluyendo mano de obra en los costos de horas extras

Registro de denuncias - números y tendencias de los últimos doce meses,

además de un análisis de ejemplo

El porcentaje del volumen de transacciones, el tiempo y el impacto del trabajo

de reproceso

Valor de las transacciones “dadas de baja” mensuales, por los últimos doce

meses

Porcentaje de tiempo dedicado al alcance de los procesos.

Nivel de Gestión

Encuestas de satisfacción del cliente, lo que podría proporcionar información

interesante

Para medidas de calidad o eficacia, usar:

Eficiencia - ¿cuántos recursos se utilizan haciendo lo que hay que

hacer?

Adaptabilidad -¿cuán fácil es para la organización cambiar?

Denominadores comunes, como lo son el tiempo, el costo, la

satisfacción del cliente

Tasa de retención de clientes, por división y / o canal de distribución

(mensual por los últimos doce meses, incluyendo las tendencias

mensuales).



empresas

140

Estudios de la tendencia de productividad

Informe de la posición del número de trabajadores, emparejado con el

organigrama para descubrir cualquier discrepancia

Copia de los informes de gestión de las métricas de rendimiento para los

últimos doce meses

ISO y / o informes de auditoría, tanto interna como externa

Nivel de prestación actual de pérdidas y ganancias

Rotación de personal para los últimos doce meses

Personal antiguo.

¿Cómo son estas métricas recogidas?

Las métricas pueden ser recogidas:

Durante los workshops

Mediante entrevistas a directivos y el personal para validar la información

obtenida durante los workshops

Por diversas encuestas y cuestionarios

A partir de los informes de gestión.

Es difícil obtener los tiempos de proceso en los workshops de modelado de

procesos, se puede completar el modelado de procesos y luego realizar otro taller

o dos para ir a través de los modelos y recoger los datos de tiempo,

alternativamente, otras personas dentro de la organización pueden disponer de la

información. Los datos pueden ser extrapolados para asegurar que tienen sentido.

Recuerde que el propósito principal de recopilar las métricas durante la fase de

ENTENDER es permitir el establecimiento de una base de referencia con efectos

comparativos con la fase de INNOVAR.

Análisis Causa-Raíz

Este análisis es esencial para determinar la causa real de un asunto o proceso

que no es realizado. Si no se logra entender completamente la causa del porqué

de los problemas no está en condiciones de comenzar la fase de un proceso de

Innovar. Es como si un médico trata el síntoma y no la determina o no entiende la

causa real de la enfermedad.

¿Cuál es la mejor manera de realizar análisis de causa raíz? Esto puede variar de

una organización a otra. En algunas organizaciones los workshops de Entender

eliminan el análisis la causa raíz, mientras que en otras organizaciones, el equipo

del proyecto tendrá que entrar en el negocio y analizar la causa raíz por sí



empresas

141

mismos. El último caso requiere de observación, investigación, análisis, y hablar a

las personas que ejecutan los procesos en el día a día. No se olvide de hablar con

la gente de fuera del equipo de procesamiento principal, porque la causa puede

ser anterior o posterior de la parte del proceso que actualmente se está

analizando. Este es un ejemplo de por qué es esencial examinar los procesos en

una base de principio a fin del proceso de lo contrario no se puede estar seguro de

que ha cubierto todos los aspectos del proceso. Si bien es esencial para hablar

con la gerencia, no es habitual que se conozca la causa raíz.

Esta técnica consiste en enumerar los principales problemas nombrados en las

sesiones de levantamiento o investigados por el mismo equipo del proyecto.

Algunas sugerencias de preguntas a tener en cuenta al efectuar el análisis de

causa raíz son las siguientes:

¿Es esto causado por otro proceso (es)?

¿Es la información recibida correcta?

Si no, ¿qué se puede hacer para rectificar la situación?

¿El personal de la ejecución de este proceso tiene las habilidades para

completarlo?

¿Podrían los formularios utilizar un mejor diseño?

¿La organización tiene la capacidad suficiente para completar este proceso al

nivel deseado?

¿El personal está inactivo?

¿Los pasos en el proceso agregan valor a los requerimientos de los

stakeholders y metas del proceso?

¿Están siendo completados en la secuencia apropiada los pasos del proceso?

Para clarificar la idea, partiremos de la premisa de que los supuestos problemas

de nuestro proceso son:

Ciclo de proceso muy largo

Proceso burocrático

Proceso poco transparente (Poco claro)

Llega el momento de entrar en el análisis, de investigar las causas de los

problemas y lógicamente también profundizar en el sentido de ir más allá e

investigar las causas de las causas. Algunas de las causas estarán relacionadas

directamente a los subprocesos del modelo mientras que otras estarán

relacionadas con el proceso en general.



empresas

142

El resultado del análisis causa-raíz debe identificar los problemas que deben ser

abordados en el marco de un proyecto de rediseño, se puede expresar de una

mejor manera representándolo en una cadena causal como la siguiente:

Grafica 37: Cadena Causal como resultado del análisis de Causa-Raíz [20]

Formulario de

excel es enredado

Información del

cargo incompleta/

incorrecta/poco

clara

Preguntas de

interpretación

Muchas

interacciones de

corrección

Proceso es muy

engorroso

Tiempo del

proceso muy largo

Poco claro: areas

poco disponibles a

preguntas

Poco claro: altos

de tiempos de

espera de tareas

Poco claro:

respuestas tardías

de áreas a

selección de

candidatos

Poco claro.

Retraso gestión

de postulaciones

de RRHH?

Situación actual

difícil de levantar

Actividades del

proceso

distribuidos entre

participantes

Poca

disponibilidad de

los participantes

Proceso es

intransparente

Demasiadas

actividades

manuales

Traspaso de

carpetas vía

correo interno

Primera revisión

recarga al

ejecutivo

Licitación de cargo

tradicional

requerida(manual)

Revisión de

completitud

Revisión de

factores claves

Administración

manual del sitio

web

Administración

manual de bolsas

de trabajo

7.2.5.4.1 Paso4.1: Tomar decisiones de innovación

Una vez los pasos de modelado, recopilación de métricas y análisis causa-raíz de

la fase hayan culminado satisfactoriamente, se deben identificar las prioridades de

innovación. Durante los pasos mencionados anteriormente, debería ser obvio que

áreas del negocio, y que proceso (s), proporcionan una oportunidad de mejora. La

priorización debe basarse en el análisis realizado en los talleres, las métricas, los

puntos de vista de los stakeholders, y las decisiones tomadas para cada proceso.

Estos podrían incluir los siguientes:

Dejando el proceso (s) tal como es - es lo suficientemente bueno



empresas

143

Mejorar - que significa que el proceso (s) necesita "retoques" o solo pequeños

cambios fusionándolo con otro proceso (s)

Rediseñando - a partir de una hoja de papel en blanco

Innovación total - el pensamiento fuera de “la caja” y hacer cambios radicales

Tercerización

Internalización

Eliminando el proceso.

En la identificación de oportunidades de rediseño, es esencial asegurar que estos

se ajusten y contribuyan a los objetivos del proceso, los objetivos estratégicos de

la organización y las expectativas de los stakeholders, establecidos durante el

formulario 1. Dedique algún tiempo a la vinculación o la asignación de nuevo a

estas metas, objetivos y expectativas.

7.2.5.5 Paso 5: Completar matriz de capacidad de las personas

La matriz de capacidad de las personas proporcionará información útil tanto sobre

el actual como del entorno futuro. Es, sin embargo, el futuro lo más importante. Si

el futuro es sustancialmente diferente de la situación actual, entonces no puede

ser apropiado completar la matriz para el entorno actual a menos que sea para la

comprensión de las deficiencias entre las habilidades de la organización y la forma

en que tendrá que cambiar en el futuro. En algunos casos, el análisis de las

competencias actuales puede proporcionar información útil sobre causas de

aberraciones de un proceso en particular.

Este análisis de las deficiencias es importante, y debe estar bien documentado y

entendido en un nivel alto en esta etapa. Es durante la fase de innovar y la de

personas que serán analizados en detalle y mucho más relacionados con las

personas, los planes de acción específicos y los posibles cambios en la estructura

de la organización. La siguiente figura proporciona un ejemplo de cómo esta

matriz podría completarse. El eje horizontal representa las competencias básicas o

competencias requeridas por cada uno de los procesos para completar las tareas

o actividades. El eje vertical representa el modelo de procesos de extremo a

extremo, el grupo de procesos o procesos individuales. Estas competencias

básicas son entonces clasificados en base simple de 1, 2 y 3, donde 1 es una

competencia básica obligatoria y 3 es deseable pero no esencial.

Recuerde:

Mirar la capacidad actual vs las necesidades futuras



empresas

144

Hacerlo desde un nivel de "gran imagen", no a nivel de personas, en esta

fase del proyecto

Revisar las la descripción de roles en áreas de alto nivel

Revisar los principales requisitos de mejora de la competencia.

Tabla 6. Matriz de Capacidad de Personas [16]

Habilidades Requeridas

Procesos Clave

Habilidad de

venderle a los

clientes

Habilidades de

Comunicación

Habilidad de

Ingreso de Datos

Tratar con

clientes difíciles

Notificación 2 2 3 1

Valoración 1 1 3 1

Aprobación 3 2 3 1

Pago 2 2 3 2

Finalización 2 3 1 1

7.2.5.6 Paso 6: Reporte final de la fase

Al final de esta fase, el equipo del proyecto debe presentar un informe al

patrocinador de negocios y del proyecto documentando los resultados y

conclusiones de la fase. Este informe debe contener como mínimo la siguiente

información:

El propósito de la fase de entender

Los problemas del proceso encontrados durante los workshops y el análisis

dentro de la empresa.

Una lista de actores y su relación con el proyecto

Resultados:

Proceso actual (es)

Métricas

Una priorización sugerida para la fase de innovar.

Para tener una visión un poco más detallada de la lista de oportunidades y

problemas encontrados hasta el momento ver el ANEXO 6: REGISTRO DE

PROBLEMAS Y OPORTUNIDADES.



empresas

145

7.3 Fase de Innovar

El propósito de esta fase es mejorar o rediseñar los procesos existentes ó

finalmente crear procesos nuevos partiendo de las ideas de los stakeholders y

personas conocedoras del proceso que son un apoyo constante para el proyecto,

la idea es conservar siempre el enfoque inicial, y hacer del proyecto una realidad

tangible.

El objetivo final de esta fase es obtener un proceso que cumpla con las

expectativas de todos los stakeholders, que cumpla con las especificaciones

técnicas y de notación que exige el equipo del proyecto, y con las medidas y el

rendimiento que requiere una empresa que está en continua mejora. Es

importante resaltar que este paso es de vital importancia, porque es donde

finalmente se trae a la realidad el proyecto.

FASE DE INNOVAR

7.3.1 Entradas de esta fase Modelos de procesos AS-IS Análisis de Métricas Matriz de Capacidad de Personas Reporte final de la fase de Entender Caso de Negocio Inicial

Pasos: Grafica 38: Pasos de la fase innovar (Tomada y adaptada de Business Process

Management - Practical Guidelines Successful Implementations)



empresas

146

7.3.3 Pasos




Es importante mantener informado a los stakeholders sobre el enfoque de la fase

de Innovar, las opciones que serán consideradas y el estado de la fase. La

comunicación debería asegurar que los stakeholders no se pierdan en el detalle, y

que siempre mantengan informados. Si tienen sugerencias que no pueden ser

incluidas, es importante informar las razones del por qué no se tuvieron en cuenta.

Esto también ayudara al momento de ganar un gran entendimiento de los

objetivos, las opciones de construcción y el negocio como parte del proyecto.

Es importante también definir los stakeholders externos, se consideran

stakeholders externos todas aquellas personas que pertenecen a una unidad de

negocio externa al área principal pero que hacen parte del proyecto, estos pueden

ser internos o externos, como clientes, proveedores, socios, gerentes de otras

áreas.

Antes de conducir el workshop inicial de innovación, suele ser útil obtener los

apropiados stakeholders junto a los grupos que informan los propósitos de lo

planeado y mejoran las expectativas incluidas en el proceso. Esto debería ser

cuestionado en los conocimientos a través de los procesos actuales y como les

gustaría que el proceso se comporte dentro de la organización para que sea una

de las futuras entradas del proceso rediseñado.

Este es una de las primeras etapas, todas las discusiones deberían contener un

alto nivel de detalle, estos stakeholders externos deberían incluirse también en

cualquier reunión para redefinir o rediseñar los procesos, para que se aporte una

7.3.2 Salidas de esta fase Nuevos modelos de procesos y su documentación Modelos de simulación Anexo 13: Acta de información y aceptación de los stakeholders externos Beneficios del análisis costo-beneficio para el caso de negocio Matriz de capacidad para nuevos procesos (ver Paso 6) Reporte y presentación Metas de los procesos



empresas

147

nueva visión de los procesos y finalmente se obtenga una dirección para el

rediseño de los procesos.

7.3.3.2 Paso 2: Workshop inicial ejecutivo

En esta fase es necesario incluir en el workshop al sponsor del proyecto y los

lideres mayores del proyecto, para determinar y entender la estrategia de la

organización y los objetivos de los procesos asociados con el proyecto y el área

de negocio que será rediseñada. La información obtenida como parte de la fase de

cimientos provee de una información básica para este workshop. Se debería

considerar llevar a cabo este workshop hacia el fin de la fase de entendimiento

para asegurarse que no exista retraso en la fase de innovar

Hay usualmente una persona clave para este workshop que es el stakeholder

principal en el proyecto. Es esta persona quien debería estar incluido

principalmente en la toma de decisiones en el workshop de lluvia de ideas.

Plazos:

Es durante este workshop, al principio de la fase de innovar, que las preguntas

críticas para la fase de innovar son realizadas y respondidas, con respecto a los

plazos y las opciones que deben ser consideradas.

Estas son algunas de las “reglas del juego” de la fase de innovar. Es importante

tener una o más personas de mente abierta que tengan conocimiento en detalle

del proceso actual y que además hayan participado en el o los workshops de

modelamiento de procesos en la fase de entender.

Objetivos del proceso:

En los workshops de innovar, se debe tener claridad sobre el establecimiento de

los objetivos. Es interesante que el enfoque exclusivo de la fase es la reducción de

costos, que frecuentemente afecta la calidad. Esto es especialmente así, si el

enfoque de reducción de costos es soportado por las medidas de rendimiento y se

recompensa con un comportamiento de reducción de costos. El resultado de este

comportamiento puede resultar en problemas de calidad como personas, líderes

de equipo y la administración se enfocan en manejar transacciones a través de

procesos tan rápidos como sea posible para reducir costos. Esta también es una

pequeña señal del enfoque, porque una dirección enfocada en la velocidad puede

terminar disminuyendo la calidad e incrementando el reproceso, y así incrementar

los costos. Es importante que durante esta fase el personal tenga mente abierta.

Esto proveerá una oportunidad de ser mejor, más rápido y más barato por la

aceptación de diferentes maneras de trabajar. Sin embargo el equipo de



empresas

148

administradores ejecutivos deberá tener una lista de estos requerimientos

ordenados según su prioridad.

De otra manera, si el enfoque es en la calidad, entonces la reducción de costo es

un posible resultado cómo será la reducción de errores y re procesos.

Algunos cuestionamientos deberán ser respondidos en orden para determinar los

objetivos del proceso incluyendo los siguientes:

Estrategia

¿Este es un proyecto evolutivo o revolucionario? ¿Quiere un cambio

incremental o un cambio radical, incluyendo la tecnología o sin tecnología? Las

respuestas a estas preguntas serán un cambio sustancial al enfoque y a los

resultados esperados de la fase de innovar.

¿Cómo el proyecto se ajusta a la estrategia de la organización?

¿Cómo el proyecto soporta los planes del año siguiente o de los próximos 2

años?

Planificación

¿Cuál es la razón fundamental de este proyecto?

¿Por qué se está haciendo este proyecto?

¿Para resolver cuellos de botella actuales y futuros?

¿Para proveer una habilidad de implementar productos nuevos y

servicios?

¿Para recortar costos operacionales?

¿Para disminuir la irritación de los clientes?

¿Para mejorar la calidad

¿Para cumplir propósitos?

¿Que son los objetivos específicos y las medidas de rendimiento de los

procesos asociados con esta fase del proyecto? El cliente debería ser utilizado

como enfoque del desarrollo de estos objetivos. Compare que piensa la

organización y que piensa el cliente, porque podría estar en desacuerdo.

¿Tenemos los recursos necesarios para abordar este proyecto?

¿Que desean que pase como resultado del proyecto?

¿Se agregaran capacidades de la organización?

¿Cuáles son las no condiciones?

Limitaciones

¿Qué plazos debería tener el trabajo: tres, seis, doce o veintiún meses?



empresas

149

¿Cuáles son las barreras y limitaciones que existen en la construcción de la

fase de innovar?

¿Existen cambios en los limitantes de administración o de personas?

Sucesos

¿Cómo sabe la organización cuando hay un punto de referencia en el proyecto

o cuando se completa el proyecto?

¿En que estará involucrado usted?

¿Cuáles son las expectativas de los diferentes stakeholders para el proyecto?

¿Cómo sabe cuándo ha sido exitoso? ¿Qué criterio de sucesos debería

construirse, documentarse y entenderse?

Automatización

Cuando se está revisando las posibles opciones viables para la organización y

para el proyecto, una automatización BPM y especialmente un workflow, es

planteado con frecuencia como una posible o deseable opción.

Mientras un workflow puede ser un beneficio significante en las correctas

circunstancias, no es necesariamente el aspecto más importante para mejorar el

rendimiento de los procesos, el único aspecto importante es enfocarse en las

personas, creando una correcta cultura, motivación, responsabilidad, propiedad,

medidas de rendimientos, retroalimentación y beneficios.

Mucha propaganda de BPM nos lleva a pensar que el workflow es realmente una

solución de software que provee los beneficios más importantes. Mientras esto

puede proveer un apropiado y facilitador beneficio, son los aspectos de cultura y

de personal los que pueden hacer limitaciones si no es manejado correctamente o

significa grandes ventajas si se maneja de manera correcta.

Sin embargo la automatización puede ser extremadamente útil en la realización de

procesos más efectivos.

Lista de éxito

Documentar una lista de éxito es importante al momento de determinar el enfoque

para el rediseño de los procesos de negocio. Por ejemplo, la organización podría

estar dispuesta a cambiar la estructura organizacional actual y el impacto que este

tendrá, será el alcance y la habilidad para modificar los procesos. La razón es que,

el equipo del proyecto necesita dirigirse ahora, a diferencia de antes, es esta

usualmente la única etapa del proyecto donde el equipo del proyecto obtiene

claridad en el entendimiento de los probables cambios que el negocio está



empresas

150

contemplando o que el negocio requiere y la magnitud del propósito de estos

cambios.

Es esencial que la evaluación de los criterios de evolución de los procesos sean

aceptados después de que el workshop de innovación comience, y que los

workshops construyan una aceptación y definición de las expectativas de los

stakeholders. Cuando se conducen los workshops es importante asegurarse que

el propósito del nuevo proceso es consistente en relación con los resultados

esperados por los stakeholders, la lista de verificación de los sucesos, los KPIs y

las medidas de rendimiento.

Preparación del workshop administrativo

La preparación de este workshop deberá incluir la distribución de la siguiente

información, que será previamente desarrollada por todos los participantes:

Una vista de procesos de la organización

Un mapa de relaciones de la organización (organigrama)

Una lista completa de los modelos de procesos para el área de negocio que

será examinada con el proyecto (AS-IS).

Una lista de todos los problemas y oportunidades desarrollados durante la fase

de entender.

Una lista de todos los procesos, por nombre y función

Métricas apropiadas que son relevantes para la discusión

Otra información útil para tener disponible, es incluir los planes de negocio y los

presupuestos para el año actual y el próximo año, y una lista de los proyectos de

la organización (para revisar la ubicación del proyecto y los proyectos

relacionados)

El workshop no debe excederse a más de un día, debe durar medio día si es

posible para asegurarse que la atención se mantenga.

Resultados

Como mínimo, los resultados del workshop ejecutivo deben proveer claridad en la

manera de seguir adelante en la fase de innovar. Se deberá incluir lo siguiente:

Un entendimiento de cómo y dónde el proyecto y los nuevos procesos se

enlazan con la estrategia organizacional

Una documentación que asegure el entendimiento del propósito y el objetivo

deseado por los nuevos procesos y las medidas de rendimiento asociadas al

proceso



empresas

151

Una aceptación de una lista de restricciones para hacer el proceso de innovar.

Aceptar los plazos de las opciones de innovar

Un acuerdo para el proyecto, donde se decida si es evolutivo o revolucionario.

7.3.3.3 Paso 3: Workshop de innovación

Esta parte es donde el proyecto cambia de análisis a creatividad (una síntesis de

nuevas ideas y empezar a innovar). Sin embargo hay que tener cuidado: el

enfoque que toma la fase de innovar dependerá en gran parte de los resultados

que usted envíe. Cuando se revisa la mejora de un proceso, los participantes del

workshop necesitarán asegurarse que ellos mismos no tienen límites solo

mirando en la fijación en los problemas del proceso actual (a menos que este

claro los objetivos del diseño). Mirando los problemas del proceso actual se

limitara el pensamiento y las posibilidades de un proceso de innovación y /o el

rediseño.

Si se quieren mejorar o rediseñar sus procesos, entonces sintetizar las nuevas

ideas creativas es importante. Si, sin embargo, el resultado propuesto es

implementar un proceso innovador, el proceso de creatividad no debería ser

limitado para las ideas internas pero debería también incluir ideas externas desde

las diferentes industrias y pensamientos bastante radicales con respecto a la

estructura futura del proceso. La innovación debería incluir cuestionamientos

significantes de los paradigmas actuales, y pensamientos fuera de los

tradicionales para la industria a la que pertenece la empresa.

Ciertamente se necesitará usar el conocimiento obtenido desde fase previa de

entender para replantear el enfoque actual de los procesos. La pregunta obvia

para realizarse es: ¿hay una mejor manera de enfocar o hacer este proceso? El

análisis de fortalezas y debilidades puede ser útil. Esto podría, por lo menos,

proveer un punto de inicio para la discusión.

¿Entonces qué técnicas podría emplear? Workshops y discusiones de los

negocios es definitivamente el mejor enfoque. Empleando creatividad y técnicas

de innovación por facilitadores experimentados en BPM podría ser muy

productivo. Como experiencia, el uso de facilitadores externos con experiencia en

BPM considerable provee los mejores resultados en la fase de innovar (La razón

para facilitadores externos es que ellos no traen información de las sesiones,

información brindada por personas quien trabaja en el área que será examinada.

Externo puede significar facilitadores internos de la organización quienes son

experimentados en BPM y como facilitadores pero no trabajan en las áreas de



empresas

152

negocio sobre las cuales se realizara el proceso de innovar, o facilitadores

externos de la organización. Estos facilitadores externos a la organización pueden

brindar experiencia desde otros sectores de industria).

Durante los workshops, se debe concentrar primero en obtener una cantidad de

ideas. No filtre mucho las ideas en este paso, esto se realizara después.

Inicialmente,

Incluya diferencias de las ideas- esto es, tratar de obtener muchas ideas

(incluyendo las ideas radicales) como sea posible.

Cubra ideas creativas- empleando habilidades de pensamiento lateral

Asegúrese que no se juzgue- esto es esencial que ni el facilitador ni los

participantes del workshop juzguen cualquier idea puesta en esta etapa, este

debería está abierto a todas las ideas presentadas.

Mirar para las oportunidades- especialmente “fuera de cuadrado” (pensamiento

tradicional)

Mirar desde el otro lado- una vista de la organización desde la perspectiva de

clientes, proveedores, socios o competidores.

La pregunta que surge es, ¿cómo lograr que los participantes del workshop sean

creativos?, el facilitador del workshop debe incentivar a los participantes a “pensar

algo diferente” más a menudo. Esto se logra realizando lo siguiente:

Pregunte mucho: „qué pasa si…..‟ y „¿Por qué esto?‟

No acepte lo que le dicen (en primera medida)

Mire la segunda respuesta correcta

La mejor manera de obtener una buena idea es obteniendo muchas ideas

El facilitador debe cambiar regularmente las preguntas y que vengan en

direcciones diferentes, recuerde la respuesta que se obtenga depende de la

pregunta que realice.

Siempre cambie las reglas

Siempre siga las corazonadas intuitivas.

El mejor método para empezar es hacer que los participantes del workshop

modelen los procesos desde una perspectiva de clientes – como el cliente

interactúa con la organización, porque a los clientes no les importa que se haga

dentro de la organización, lo único que les interesa es como se interactúa cuando

se obtiene el producto o servicio que se desea. Se puede modelar también la

experiencia de clientes con los competidores y compararla con la anterior creada.

Esto puede expandirse a incluir las perspectivas de socios y proveedores.



empresas

153

Pasos de un workshop de innovación:

La organización variará dependiendo de muchos factores- el tamaño de la

organización, el número de workshops y los participantes del workshop, la

complejidad de los procesos que han sido revisados, entre otros.

La mejor configuración de roles, asumiendo una organización razonablemente

grande y los procesos complejos, es como la siguiente:

Facilitador: Esta es la persona quien controla el workshop, asegurándose que

la dirección y la guía sean se respeten y que los plazos y resultados se

mantienen presente en todo momento.

Modelador de procesos: Este asume el modelado del proceso, puede ser

dirigido en línea, usando un modelador de procesos y herramientas de gestión

durante el workshop y son proyectados en una pantalla para que todos los

participantes lo vean, se ha encontrado que este sería el mejor enfoque

porque permite que los participantes sean incluidos. El modelador de procesos

no solo crea el modelo para que todos lo vean durante el workshop, también

participa en las discusiones del workshop.

Escritor: Esta persona toma nota de las discusiones; recolectar métricas,

problemas, oportunidades, pensamientos y las ideas, también incluye cualquier

idea futura que podrá entrar en consideración. Miembros individuales del

equipo podrían tener la tarea, después que termine el workshop; por ejemplo,

una oportunidad de mejora puede requerir futura investigación para

asegurarse que no se impacte en otras aéreas, en los sistemas de información,

en los proveedores y clientes. El escritor necesita mantener el seguimiento

de estas tareas, tomando nota en detalle desde el workshop. El escritor provee

un valor agregado; sin embargo. La necesidad de este rol depende del tamaño

y de la complejidad del workshop, un escritor no es siempre necesario.

El comportamiento del facilitador y de otros miembros del proyecto se podría

reflejar en la diferencia de los workshop de las fases de entender y de innovar. Un

facilitador experimentado en BPM entenderá estas diferencias y estará consciente

de lo siguiente:

Los participantes del negocio se pueden sentir amenazados por las

sugerencias de cambio para el proceso y sus futuros roles; el facilitador y el

grupo necesitan estar sensibles a esto.

Si un problema o sugerencia se ajusta dentro de los plazos será considerado.



empresas

154

El facilitador (y los participantes que están fuera del negocio) deberían

permanecer neutros por el mayor tiempo posible dentro de la discusión. Los

participantes del negocio deben tener la oportunidad de hacer mejor los

procesos. Asegurarse que los propietarios del negocio estén comprometidos

con ideas para el mejoramiento de procesos.

El facilitador debe crear un ambiente donde puedan desarrollarse muchos

cuestionamientos- esto serán archivados por el facilitador respondiendo

muchas preguntas, y manteniendo las menores críticas y comentarios

negativos en control.

Debería haber muchos “¿Por qué?” en las preguntas.

No deben existir desacuerdos significativos entre participantes fuera del

negocio y miembros del equipo del proyecto en el workshop.

Podría existir un alto nivel de desacuerdo entre los participantes de negocio de

si los procesos deben ser modificados o cambiados totalmente. Esto es bueno

porque se promueven mejores resultados, es por esto que el facilitador debe

manejarlo con cautela.

El facilitador debería trabajar en los en los miembros creativos del grupo y tal

vez guiarlos a realizar la primera sugerencia, asegurando que todos los

participantes del workshop contribuyan a tener una oportunidad para dar su

opinión.

La información muy detallada debería ser evitada.

Siempre se debe asegurar que todos los participantes del negocio son

reconocidos y elogiados por sus contribuciones.

Metas a corto plazo

A continuación se muestra un ejemplo de agenda de un workshop.

Introducción

Se requiere un ejecutivo mayor para abrir la sección y se describe lo siguiente:

Los objetivos son archivados

Las metas y la visión del workshop – esto deberá ser aceptado en el

workshop ejecutivo

Los limites se tomaran en consideración durante los workshops



empresas

155

Secuencia

Revisar la lista completa de procesos desarrollada por el área que se

consideró durante los workshops de entender, si es necesario este debe ser

rediseñado.

Presentar los dos primeros ítems seleccionados durante la discusión de

fortalezas y debilidades en los workshops de la fase de entender.

Asegurando que estén puestos en una posición prominente, son referidos

en una base regulada y estos se toman en cuenta durante las discusiones

de la fase de innovar.

Revisar las metas de los procesos y los objetivos de organización para

asegurarse que los nuevos procesos los tienen en cuenta.

Hay dos maneras para comenzar la discusión del proceso de innovar:

Discutir las deficiencias del proceso actual y mejorarlas

Rediseñar completamente el proceso.

Iniciar el trabajo creativo de innovar, si se justifica, durante el modelado del

proceso de innovar asegurar que los componentes del modelo tienen un

código de colores destacando las diferencias con los procesos viejos y

representando los plazos incluidos en la presentación de las sugerencias de

mejoramiento, los plazos pueden mostrarse también en modelos de

procesos separados.

Capture ideas y tareas que necesiten revisar su factibilidad. Los miembros

del equipo deberían entonces hacer tareas de responsabilidad con el

negocio y validando la factibilidad de las sugerencias, entonces deberían

volver al grupo y presentar su descubrimiento.

En varias etapas durante los workshops es esencial que los participantes

del negocio presenten las propuestas fuera del grupo e inviten a los

managers para asegurar o consolidar que son los propietarios de los

nuevos procesos. El facilitador debería asegurarse que los participantes del

negocio están acreditados con las ideas.

Muchos de los escenarios de los nuevos procesos deberían ser

desarrollados, no pare en uno y piense q el trabajo está bien hecho. Los

primeros dos escenarios de los procesos rediseñados solo inician el flujo

creativo, es después que los procesos de innovar son más creativos y

eficientes.



empresas

156

Después de las actividades de los workshops

Inmediatamente después del workshop, el equipo de proyecto del workshop

de innovar debe completar una revisión de los modelos contra las notas

tomadas por el escritor, asegurando que las notas y los modelos graben

todos los aspectos discutidos.

Expandir detalles en una lista corta de alternativas

Re aplicar los criterios de evaluación en más detalle para asegurar

consistencia

Seleccionar no más de tres opciones para las consideraciones

administrativas.

Construir un plan.

Metas a largo plazo

Los detalles y agenda para este workshop son principalmente la misma para el

horizonte a corto plazo, con las siguientes excepciones:

Mejor que empezar con un nuevo proceso durante el workshop de entender

y modificar ligeramente o significativamente, se debe iniciar con una hoja en

limpio.

Claramente, esta es una oportunidad totalmente para replantear como

opera el negocio, idear radicales y procesos innovadores podrían ser

considerados. Un enfoque útil es una lluvia de ideas “fuera de la caja”

El facilitador deberá preguntar a los participantes por ideas radicales y

no debe criticar o comentar desde el grupo en este paso, las ideas

deberían ser escritas en hojas pequeñas y luego pegarlas en el tablero.

El siguiente paso es tener lugar para las ideas de los participantes en el

grupo.

La discusión debería llevar a cabo la eliminación de ideas que este por

fuera de los criterios enviados en el workshop ejecutivo de esta fase

Las ideas pueden estar en debate por su mérito.

Estas ideas y propuestas pueden ser usadas en el diseño de nuevos procesos.

Preparación del workshop

Es esenciar que los miembros del equipo involucrados en la conducción de

los workshops de innovar preparen un avance. La preparación debe tener

en cuenta lo siguiente:



empresas

157

Revisar los modelos de entendimiento dirigidos durante el workshop

asegurando un entendimiento común.

Si es necesario, confirmar aspectos del proceso de entendimiento en el

workshop inicial.

Pensar a través de las posibles soluciones del proceso de innovación para

que el workshop pueda ser directo.

Ejecución del workshop

¿Cómo iniciar los workshops? Claramente, la manera obvia de comenzar un

workshop de innovación debería ser preguntando a los participantes del negocio

que piensan de un proceso nuevo más eficiente que satisface los plazos y otros

limites acordados al iniciar.

Otros métodos para desarrollar este proceso es tener en cuenta lo siguiente:

1. Validar el modelo AS-IS:

Se pueden validar con los participantes sus vistas del modelo de acuerdo con

los roles que se han asignados. Los participantes del workshop deben tener

conocimientos básicos de BPMN 2.0

2. Puntos de control:

Si el proceso que será modelado es un proceso financiero o de control,

entonces se debería hacer una lluvia de ideas con varios puntos de control que

serán requeridos con el proceso, por ejemplo, en los procesos de emisión de

recibos y conciliación bancaria, los puntos de control podrían ser los

siguientes:

Asegurarse que toda la información ha sido ingresada por los operadores a

la aplicación del sistema.

Una sola persona recolecta las pistas de auditoría de la información

ingresada al sistema

Un balance de las pistas de auditoría con la aplicación

Combine todas las pistas de auditoría en un reporte

Equilibre las pistas de auditoría para declaraciones bancarias para

asegurar que las declaraciones bancarias estén correctas

Revise las declaraciones bancarias por ítems que han sido depositados

directamente en el banco y se debe introducir en la aplicación del

sistema.



empresas

158

Envié reportes (pistas de auditoría o reportes consolidados) al

departamento financiero para completar la conciliación bancaria

Asegúrese que todos los reportes lleguen al departamento financiero.

Una vez estos puntos de control hayan sido aceptados, el desarrollo de los

procesos puede ser relativamente fácil y rápido porque se tiene la aceptación de

los pasos esenciales que se debe conocer para el proceso.

3. Actividades Criticas:

Para los procesos no financieros, una lista de actividades críticas debe ser el

resultado de una lluvia de ideas y de escribir en un tablero en blanco o en notas

pequeñas. De nuevo los procesos son relativamente rápidos y fáciles de

desarrollar.

Siempre se debe preguntar por las actividades críticas para asegurarse que sea

necesario. Los procesos de innovación pueden afectarse de alguna de las

actividades críticas actuales.

4. Resistencia de los participantes del proceso y retrocesos.

En este momento es cuando la experiencia entra en juego, por ejemplo, los

participantes del proceso creen que los procesos actuales están perfectos y no

pueden ser mejorados, o no existe manera de mejorarlos, entonces no se debe

tratar de rediseñar los procesos actuales.

Se debe preguntar por el mejoramiento de actividad por actividad en el proceso

actual, realizar una lluvia de ideas con los problemas y las áreas que podrían ser

mejoradas. El nuevo proceso debe desarrollarse desde estas propuestas de la

lluvia de ideas y debe mostrarse a los participantes.

Para concluir este paso, se debe realizar un documento donde se reúnan todas las

ideas que se generaron, estas ideas serán parte fundamental del taller de análisis

y mejora donde se diseñará finalmente el proceso futuro TO-BE).

7.3.3.4 Paso 4: Taller de análisis y mejora

Se conoce como técnicas de análisis y mejora a todas aquellas técnicas que se

emplean para analizar y mejorar los procesos organizacionales desde las

perspectivas: tiempo-costo-calidad



empresas

159

Para realizar este análisis como lo propone el framework “BPMN-Framework”, se

debe basar en una serie de factores que llevarán a determinar qué proceso utilizar

para mejorar, rediseñar o realizarle reingeniería a los procesos de la compañía.

Parte importante de los factores que llevaran al mejoramiento del proceso es el

documento de las ideas generadas en el workshop o los workshops de

innovación, un análisis causa y efecto de los procesos actuales, esta información

será útil para la realización del taller.

Una de las posibles soluciones es la reingeniería de procesos, la reingeniería de

procesos que fue descrita por hammer&Champy en el 93 se describe como la

“reconsideración fundamental y reorganización radical” para lograr una mejoría

drástica en el desempeño, los costos y los servicios. Ellos recomiendan que se

deben observar los procesos completos de una organización, desde la

adquisición, pasando por la producción, la venta y la distribución. La empresa

debe concebirse y reconstruirse como un conjunto de procesos.

Los principales aspectos de la reingeniería de procesos son:

Orientación a la satisfacción del cliente ( tiempos de respuesta, calidad de

productos y servicios, costos)

Reconsideración fundamental de la organización del trabajo ( actividades,

flujos, responsabilidades)

Considerar las capacidades de TI para mejorar la eficiencia de proceso.

Un proyecto BPR solo se puede llevar a cabo a través de un proyecto con el

respaldo del directorio de la empresa, es de considerar que un BPR impacta en

forma cultural, procedural y estructural, por lo que se requiere incluir más

disciplinas como “gestión del cambio cultural”, “gestión de conocimiento”,

“programa de capacitación”, etc…

Otro de los conceptos es el REDISEÑO de procesos, es importante resaltar que

reingeniería y rediseño no es sinónimo, rediseño de procesos, no es tan radical

como la reingeniería pero puede mejorar el grado de competitividad a través de

técnicas de optimización de procesos. El mayor impacto de un rediseño se tiene si

el análisis comienza con los eventos generados por los clientes y los resultados

que llegan a ellos, por ejemplo solicitudes, pedidos, pagos, reclamos, etc. Las

dimensiones de optimización en el rediseño son: reducción de los tiempos de

ciclo, mejoramiento de la calidad de los productos y servicios, reducción de costos.



empresas

160

El rediseño como refiere el libro BPMN 2.0, establece los cambios que deberán

efectuarse en la situación actual y detalla cómo se ejecutarán los nuevos

procesos, es la fase más importante, ya que se definirán las nuevas formas de

operar y su desempeño. ¿En qué ámbitos influye el rediseño?:

Estructural: Cambio en el proceso mismo (cambian las operaciones, se

eliminan duplicidades etc.)

Productividad: Análisis de ciclo y costeo de actividades

Responsabilidades: Se modifica la asignación de responsabilidad (personal,

centralizar o descentralizar responsabilidades, etc.)

Integración: Mejorar el grado de integración entre la capa de la estrategia,

operacional (procesos) y tecnología (producción y TI)

Incorporación de tecnología: Automatización de procesos, aplicación de

tecnologías móviles, integración de sistemas, etc.

Finalmente bajo el término de mejora se entiende en forma abreviada en BPM el

círculo virtuoso de mejora continua por medio de gestión de procesos, el concepto

de mejora continua está inserto dentro de la gestión diaria de operaciones y a

diferencia de la técnica de rediseño no requiere de la formulación de un proyecto.

El ciclo de implementación de la mejora queda en manos de los responsables del

negocio y no consumen recursos adicionales a los propios, también se puede

sumas a la técnicas el solo monitorear el rendimiento de los procesos a través de

indicadores de ciclo u otros e iniciar iniciativas de mejora cuando se detecten

desviaciones al comportamiento esperado. El concepto de mejora continua está

limitado a cambios pequeños como reglas de negocio, procedimientos locales,

redistribución del volumen del trabajo, simplificación de formularios etc. Si los

cambios propuestos por la mejora continua impactan sobre la estructura de los

procesos, traspasan los límites de responsabilidad del área, impactan sobre la

tecnología o bien requieren de recursos adicionales, la propuesta de mejora para a

un proyecto de rediseño

A continuación se muestra un cuadro comparativo con las características

principales de los enfoques propuestos.



empresas

161

Tabla 7: Cuadro comparativo con las características principales de los

enfoques propuestos. [16]

Característica Reingeniería Rediseño Mejora

Enfoque Proceso Nuevo Reestructuración Mejora evolutiva

Punto de partida Proceso existente Proceso existente Proceso existente

Objetivo del cambio

Cambio radical, satisfacción del cliente

Rediseño de una parte del proceso

Actualización eficiencia o satisfacción del cliente

Tipo de cambio Radical Estructural Incremental

Periodicidad del cambio

Descontinuado Intervalos intermedios

Continuo

Impulsor del cambio

Proyecto Proyecto o grupo de trabajo

Dentro de operaciones

Impacto del cambio

Transversal Proceso, Subproceso

Dentro de un subproceso

Cultural Cultural Cognitivo

Procesal Procesal Procedimiento regla de negocio

Estructural Estructural Costo.calidad.tiempo

Riesgo Alto Medio Bajo

Clasificación y tipos de mejora

Análisis de Estructura

Con el análisis de estructura se busca mejorar el desempeño de los procesos

sobre todo con miras a reducir los tiempos de ciclo y mejorar la calidad de los

servicios de los procesos. Para estos efectos se puede revisar:

El orden de las actividades en un proceso.

Si existen redundancias.

Actividades, procedimientos o reglas de negocio obsoletas.

Flujos complejos que se pueden simplificar.

El libro BPMN 2.0 nos expone un estudio de Blicher [Gad10] que muestra las

posibilidades que se tienen para reestructurar un proceso



empresas

162

Optimizar el Orden

Grafica 39: Optimizar el Orden [20]

En el primer flujo, se puede revisar si las actividades se pueden iniciar antes. En el

ejemplo se muestra que la actividad 17 puede realizarse después de la 4. En este

ejemplo el tiempo de ciclo del proceso podría reducirse al ejecutar la actividad 17

antes de la 5.

Acelerar

Grafica 40: Acelerar [20]

En segundo flujo, se puede dotar de mayores recursos la actividad 4, con lo que

se logra agilizar el tiempo de ejecución de esa actividad. En este caso representa

el típico cuello de botella, cuando un usuario tiene mucho volumen de trabajo y

otras tareas tienen que esperar a la finalización de esta.

Agregar

Grafica 41: Agregar [20]

El flujo, muestra una posibilidad muy poco considerada en la práctica por que

agregar una actividad aumenta el costo de los recursos, pero puede mejorar

notablemente la calidad del servicio y con esto el grado de satisfacción del cliente.

1

2

4

3

17

5 17

1 4 5

2 3

6

4

DURACIÓN

4



empresas

163

Actividad Obsoleta

Grafica 42: Actividad Obsoleta [20]

En este flujo se muestra como se acorta el ciclo si se puede desistir de una

actividad en el proceso. Para revisar si encontramos actividades obsoletas se

tiene que preguntar en las reuniones de análisis: ¿qué pasaría si se desiste de

esta actividad?

Externalizar

Grafica 43: Externalizar [20]

En este caso se muestra la posibilidad de externalizar un servicio si su realización

es más eficiente entregarlo a especialistas. Piense en el caso de la necesidad de

elaborar o revisar contratos de negocio, contratos de empleo, finiquitos etc… si el

volumen de una actividad es pequeño, pero se requiere de mucho conocimiento

específico para resolverla, es un candidato a la externalización.

1 4 5

2 3

1 4 5

2 3



empresas

164

Unir

Grafica 44: Unir [20]

Aquí se muestra la posibilidad de unir actividades, supongamos que la entrada de

una factura pasa por dos revisiones formales, revisión de validación de datos y

existencia de una orden de compra (2 y 3) antes de que sea enviada al ejecutivo

de área. Si ponemos a disposición la información necesaria para que se puedan

revisar en conjunto, se ahorra el traspaso de una tarea a otra

Paralelizar

Grafica 45: Paralelizar [20]

En este caso se muestra la posibilidad de paralelización de actividades en un flujo

de procesos. Si logramos paralelizar actividades se puede reducir el tiempo de

ciclo de un proceso

Análisis de tiempo de ciclo

El concepto de tiempo de ciclo muestra el tiempo que toma el proceso en ejecutar

una instancia, desde su inicio hasta el fin del proceso.

A la suma de tiempos de las actividades que agregan valor se conoce como

tiempo de valor agregado. Normalmente se expresa como la fracción o porcentaje

respecto del tiempo total o tiempo de ciclo.

2+3

1 4 5

1

2

4

5 3



empresas

165

Así, muchas veces, para obtener mejoras en el tiempo de ciclo se pone más

atención en las esperas o detenciones que afectan a la instancia que en las

actividades mismas del proceso.

Hay que considerar que los tiempos de duración de las actividades son variables

aleatorias, usualmente con distribución de probabilidades exponencial, por lo que

cuando se indica el tiempo de la actividad en realidad está haciendo referencia a

un tiempo promedio observado de duración de la actividad (estimación de tiempo

esperado de duración de la actividad). También hay que tener presente que la

variabilidad se ve disminuida en actividades automatizadas.

Las colas o esperas, también conocidas como buffers o amortiguadores, existen

en los procesos normalmente debido a:

El diseño del proceso consideró la existencia de la espera o almacenamiento

de instancias, para ser ejecutadas.

El proceso responde con una cola ante la incapacidad de procesar el flujo al

que está siendo sometido. Esto podría ser parte del diseño.

En términos generales, además de reducir el tiempo de ejecución de las

actividades, las recomendaciones a fin de reducir el tiempo de ciclo en un proceso

son en relación con:

Reducir las interrupciones del proceso, entre ellas el tiempo de preparación de

máquinas. Cada vez que se interrumpe el proceso quedan instancias

esperando a ser procesadas, una vez restablecido el flujo el proceso tomará

un tiempo en recuperar su ritmo anterior a la interrupción, sin duda en ambos

casos el tiempo de ciclo de las instancias que se encuentren en el proceso se

verá afectado negativamente.

Eliminar los cuellos de botella. Un cuello de botella se produce en una actividad

disminuyendo el flujo y por lo tanto generando una cola o espera previa a la

actividad. Esto ocurre porque el proceso no se encuentra bien balanceado o

por una baja capacidad de la actividad para atender la demanda o flujo.

Balancear adecuadamente el proceso, aumentar la capacidad de proceso de la

actividad, duplicar en paralelo la actividad serian recomendaciones a

considerar frente a un cuello de botella.

Eliminar las colas o almacenamientos. Como se vio anteriormente las colas o

lista de espera se encuentran asociados a los cuellos de botellas, la cola se

produce naturalmente donde el flujo se hace más lento y así un aumento en el

tiempo de ciclo del proceso, por ello es que si se busca disminuir el tiempo de



empresas

166

ciclo se debe poner atención a las colas y eliminarlas cuando se pueda. En

algunos procesos la cola es parte del diseño.

Cambiar el orden de las actividades. Para un mejor entendimiento se utilizara

como ejemplo el proceso de atención de un paciente en una unidad de

emergencia, donde el médico indica realizar a un paciente una radiografía,

para lo cual el paciente debe ser llevado a la unidad de radiografías, y toma

una muestra de sangre para ser procesada en el laboratorio. Para ambas

actividades se requiere del paciente, por lo que no las podemos ejecutar en

paralelo. Si se lleva primero al paciente a radiografía y luego se extrae la

muestra de sangre el laboratorio comenzara a efectuar el análisis de ella más

tarde que si primero se toma la muestra y mientras es enviada al laboratorio se

lleva el paciente a tomar la radiografía. Este cambio en la secuencia de

actividades claramente puede llevar a un menor tiempo de ciclo del proceso de

atención al paciente.

Diseñar actividades en paralelo. El principio es la simultaneidad, es decir que

una misma unidad de tiempo se pueden estar ejecutando más de una tarea a

la vez sobre una misma instancia.

En algunos casos se recomienda la unión de dos o más actividades en una, a

modo de ejemplo que el control de calidad de una actividad sea parte de la

misma actividad, esto conlleva a entregar responsabilidad al operador en la

calidad del trabajo que ejecuta.

Una recomendación es analizar el tiempo de ciclo de un proceso con métodos de

gestión de proyectos, viendo el proceso como una red, identificando la ruta crítica

y luego privilegiando la reducción de tiempos de las actividades o tareas de la ruta

crítica, esto aplicado a las distintas instancias identificadas que serán atendidas

por el proceso.

La reducción del tiempo de ejecución de una actividad no necesariamente

aportará una reducción en el tiempo de proceso. Esto sólo ocurrirá si la actividad

se encuentra en la ruta crítica del proceso.

Se debe tener presente que siempre se debe estar observando las tres

dimensiones ya mencionadas de desempeños de procesos: tiempo, calidad y

costo. Por ejemplo una reducción inadecuada del tiempo de ciclo puede llevar a

una pérdida de calidad y con ello un aumento de los costos, un aumento del

tiempo de ciclo por incorporación de una actividad de inspección temprana, puede

llevar a un aumento de calidad y también una reducción de costos entre otros.



empresas

167

Análisis de costeo de actividades

Las empresas o instituciones proveen sus productos y/o servicios a sus clientes a

través de procesos de negocio.

Los procesos durante la ejecución consumen actividades y las actividades

consumen recursos.

La idea central de costeo de actividades es asignar el consumo de recursos a

cada actividad, por ejemplo: consumo de materiales, mano de obra, energía,

tiempo de máquina, etc.., obteniendo así un costo para cada actividad.

En cada proceso se contabiliza la cantidad de actividades que se requieren para

su ejecución. Y entonces, en términos sencillos, si se tiene el costo de cada

actividad se puede obtener el costo de producto o servicio producido por el

proceso (costo de la instancia).

Con BPM se puede asignar el costo promedio de cada actividad, a través de la

inclusión de un atributo. Si las instancias van acumulando los costos al término de

un periodo, se puede conocer el costo de la producción en el proceso. Estos

cálculos se encuentran sobre la observación de un proceso en particular, y se

puede incluir en un process engine como indicador en un Business Activitiy

Monitoring (BAM), como se hace para tiempos de ciclo en forma agregada.

Un objetivo primario de toda empresa u organización es gestionar sus costos. A

continuación algunas recomendaciones.

Eliminar del proceso aquellas características del producto o servicio que no

agregan valor para el cliente.

Estas características innecesarias consumirán recursos que no serán valorados

por el cliente. Incluso el producto o servicio podría contener una característica que

destruye valor.

Aumentar el uso de los recursos

Las mejoras en el ámbito de disminuir el tiempo de ciclo del proceso, entre otras,

apuntan a aumentar el uso de los recursos, es decir a aumentar la productividad

de la capacidad instalada. Al disminuir el tiempo de ciclo se tiene la oportunidad

que con los mismos recursos fijos (instalaciones, maquinas, personal a contrato

fijo) se puede obtener una mayor producción de unidades, disminuyendo así el

costo unitario de esas unidades.



empresas

168

Aumentar la calidad en todo el proceso

En este punto el criterio es detectar la falla apenas esta se produzca, de modo de

no seguir consumiendo recursos mientras no se repare la falla o se deseche. En

definitiva: ¡hacerlo bien, y a la primera! Esto disminuirá los costos por reprocesos,

reparaciones, garantías post-venta, desprestigio de la marca, pérdida de clientes,

etc. Si bien la mejora en la calidad del proceso podría aumentar inicialmente los

costos se acepta que asumiendo una curva de aprendizaje normal, al cabo de un

tiempo generará beneficios que también se manifestaran en reducción de costos

del proceso

Análisis de responsabilidades

El análisis de responsabilidades estudia la relación entre las actividades del

proceso y su respectiva asignación de responsabilidades (unidades

organizacionales, roles, cargos). En organizaciones grandes y antiguas, como

también en la administración pública se encuentran estructuras jerárquicas y

burocráticas que se pueden reducir, liberando de esta forma actividades que

retienen el proceso y no cumplen con otra función que confirmar o aprobar un

documento que elaboro un ejecutivo o usuario de negocio.

Diseño de modelos de procesos TO-BE

Como resultado principal de esta fase está el modelo de procesos TO-BE, que

representa en un modelo con la simbología BPMN como debería ser el proceso

para ser desarrollado e implementado.

Al analista de procesos le sirve el modelo AS-IS para evaluar la eficiencia del

proceso y poder desarrollar propuestas de mejora. El modelo de procesos TO-BE

constituye la base y el punto de partida para el diseño de una implementación

técnica por medio de TI.

El analista tiene que además de identificar puntos críticos y reconocer problemas

actuales de flujo de trabajo para hacer propuestas de mejora, tanto como técnicas

como organizacionales. Su pregunta esencial es:

¿Cómo se trabaja y cómo podría hacerse mejor? El usuario de negocio en

cambio solo se interesa en aquellos aspectos del proceso que le conciernen a él.

Su pregunta esencial es:

¿Cómo tengo que trabajar? Llegado el momento de querer implementar

técnicamente el proceso, entra en juego el ingeniero de procesos. El ingeniero del

proceso no es parte integrante del equipo para el modelamiento en el segundo



empresas

169

nivel, su rol activo comienza en el nivel técnico, pero él debe enterarse sobre los

requerimientos funcionales que deberán implementarse. Su pregunta esencial en

este nivel es:

¿Qué debe cumplir el sistema de TI? Uno de los desafíos principales en la

creación del modelo TO-BE es de coordinar satisfactoriamente estos tres roles

principales contestando a cada uno de las preguntas, si logra esto obtendrá una

serie de beneficios como:

El modelo TO-BE corresponde en su lógica principal completamente a la lógica

que será implementada técnicamente. Logramos un buen alineamiento entre la

capa de negocio y la capa de TI. La documentación elaborada no se deja de

lado y se empieza de nuevo a modelar como sucede en muchos proyectos.

La brecha entre la capa de negocio y de TI se reduce considerablemente, se

logra una plataforma de entendimiento común: la gente de negocio y la de TI

conversan y se coordinan sobre el mismo modelo. Se reconoce de inmediato el

impacto que puedan tener requerimientos funcionales o el impacto que pueda

tener al negocio una cierta forma de implementación técnica.

En el momento que se implemente la solución, se pueden medir los

indicadores de ciclo y agregar otros indicadores de negocio que permitan

monitorear en línea el comportamiento de procesos y generar reportes

estadísticos en forma automática.

Para la creación del modelo TO-BE cada participante recibe su propio pool. Como

lo establece la norma, cada pool representa un proceso individual. El diagrama de

colaboración que muestra la interacción entre los pools pasa a ser entonces un

asunto de los analistas, de quienes si se espera que tengan un domino sobre la

complejidad. En la forma de proceder presentada por el libro BPMN 2.0, el sistema

se declara como un participante más en el proceso, es decir le asigna un pool

propio. Este es entonces el pool que debe implementar el ingeniero procesos. Si

seguimos este modelo de diseño se cumple claramente con el objetivo que

persigue el estándar BPMN, que tiene su foco en el sistema, con la diferencia que

se piensa traspasar el principio de workflow que queda fuera de implementación

de TI, y que es el workflow manual o humano. Solo una parte de todo el proceso

de negocio se implementa o puede implementarse técnicamente. Por lo general

existen algunas instancias que deben intervenir o tomar decisiones los seres

humanos. Si se requiere implementar el proceso completo, entonces se tiene que

levantar completamente y no solo reducirlo a la parte de TI. Justamente es lo que



empresas

170

se propone y le asigna un pool a cada participante, independiente si se trata de

un sistema u otra persona.

Para realizar este modelo de proceso TO-BE se aplicaran los siguientes pasos:

Definición del alcance y del modelo TO-BE a partir del modelo de procesos AS-

IS

Modelamiento de aquellas actividades que van a ser apoyadas por el sistema.

También este diseño tiene que validarse con el dueño del proceso y los demás

participantes.

Modelamiento de la lógica en detalle del sistema. Gran parte de esta lógica la

podemos deducir de los procesos de los participantes. El modelo aún es

independiente de la implementación técnica, es decir aún no es ejecutable pero

se puede complementar para una implementación técnica.

Desarrollo y documentación del resto de los requerimientos, como pantallas,

datos y reglas de negocio. Estos requerimientos se van agrupando a los

objetos del modelo de procesos del sistema, por medio de marcas y símbolos

adicionales de BPMN reservados para estos fines.

Con la versión de BPMN 2.0 se tiene la posibilidad de reducir la complejidad de

los diagramas de colaboración empleando los diagramas de coreografía. La

ventaja que se tiene con este nuevo tipo de diagrama es que se puede representar

en forma mucho más compacta la interacción entre los participantes. La

desventaja es que no se visualiza la lógica interna, es decir la lógica que no

participa en la colaboración.

La importancia del enfoque del modelo de procesos es el traspaso o el mapeo sin

variaciones de aquella parte de la lógica de negocio que se requiere implementar

en un sistema. Desde el punto de vista de TI es el objetivo principal de cómo la

tecnología puede automatizar o implementar BPM. Una alternativa, no tan actual y

elegante, seria de programar la lógica de los procesos con lenguajes como java,

.Net o C#, en vez de utilizar un BPMS o un process engine.



empresas

171

Consideraciones al implementar procesos con un process engine

En la fase anterior, se puede decir que en los talleres con ejecutivos y usuarios se

levantó el deseo de flujo que se quiere automatizar para mejorar el control y la

transparencia de los procesos. Habiendo levantado la lógica de negocio de la

situación actual, sin considerar que partes se van a implementar, ahora es tiempo

de ver al participante desde la perspectiva de un usuario de un sistema y aclarar

con ellos, que requerimientos y funcionalidades debe cumplir la aplicación.

En este proceso le solicitamos a los stakeholders que nos describa la

funcionalidad deseada para el proceso que será implementado. Puede suceder

que la descripción tenga muchas similitudes con lo descrito en el nivel descriptivo

(fase de entender) pero que tengan algunas diferencias importantes que deben ser

consideradas. Después de esta descripción se amplia de la siguiente manera:

Se divide el pool del área en dos lanes, portal y otros

Se asignan todas las tareas que deben ser ejecutadas por el sistema en el lane

“Portal”. Actividades con flujos de mensajes de salidas representan que el

usuario termino su actividad manual ( human task) y envía el resultado

Las actividades de interacción directa con el área, se asignan en un lane que

se denomina “otros”, porque no son parte del flujo que pasa por el portal, si no

que a través de los canales convencionales como e-mail o teléfono.

Grafica 46: Vista del jefe de Área [20]

El flujo propio del process engine

Como analista de procesos se dirige al ingeniero de procesos. Con él se aclarará

como el sistema puede implementar esta funcionalidad para cumplir con los

requisitos nombrados.



empresas

172

Para estos efectos se integraran todos los modelos desarrollados en un gran

diagrama de colaboración. Se abrirán los pools de los modelos manuales y el pool

del sistema (hasta ahora cerrado). Este último se divide en tres lanes:

Un lane para el jefe de área y uno para el usuario. Todas las actividades que

se le asignan a estos lanes representan, tareas de usuario en el sistema

(human task)

Un nuevo lane que va a representar los pasos automáticos. Se trata la

invocación de servicios (service task), programas internos (scripts), llamados

de subprocesos etc.

OTROS REQUERIMIENTOS PARA LA IMPLEMENTACIÓN

¿Podría el ingeniero de procesos implementar en TI la solución solo con la

información del diagrama? La respuesta es clara, por supuesto que no. Existen

aún muchos requerimientos por aclarar, por ejemplo la interfaz de usuario y los

formularios con los campos respectivos de información que se requiere en el

dialogo. Estos requerimientos no tienen diferencia alguna con los clásicos

proyectos de desarrollo o de configuración de soluciones de software. Estos

requerimientos no están directamente relacionados con la lógica de los procesos

pero son necesarios de considerar en la implementación. El libro BPMN 2.0 no

recomienda seguir con el diseño técnico en los diagramas de BPMN, si no

hacerlos directamente en la plataforma que se va a implementar los procesos.

Lógicamente si se tiene la posibilidad en su entorno de linkear las actividades del

diagrama de BPMN con las actividades del entorno de implementación mucho

mejor. De esta forma el modelo de negocio de BPMN queda integrado a la

plataforma técnica. Cualquier cambio debería hacerse siempre primero en el

modelo de negocio.

En la siguiente tabla se clasifica y enumera los típicos requerimientos técnicos,

que deben considerarse adicionalmente en la etapa de diseño técnico. Si estos

requerimientos se documentan directamente en el entorno de implementación o

utiliza otros medios depende de la organización del proyecto.



empresas

173

Tabla 8: Requerimientos adicionales para la implementación técnica [20]

Tipo Descripción Ejemplos Notaciones BPD Link

Funcional Funcionalidad que debe cumplir la solución

-Lógica del proceso -Características -Caso de uso -Interfaces -Reglas de negocio

-BPMN -UML (use Cases) -User Stories -Test de aceptación -Texto general

-Actividad

No Funcional

Requerimientos técnicos que debe cumplir la solución

-Service level agreements(SLA) -Tiempo de respuesta -Robustez -Control de cambio

-Texto -Pool

Interfaz de usuario

Canales y capa de presentación que interactúa con el usuario

-Pantallas -Workflow guiado -Mobile Devices -E-mail roles

-BPMN -Prototipo de pantalla -User Stories -test de aceptación

-actividad

Datos Información que tiene que procesar el software

-Información -Restricciones -Formatos -Canales -Mappings

-Diagramas de ER -Diagramas de clase UML -Tablas

-Pool -Objeto de datos

Reglas Decisiones que tiene que tomar el software

-Validaciones -Revisiones -Cálculos -Puntos de control

-Tablas -Arboles de decisión -Texto

-Actividad



empresas

174

Implementación de puntos de integración

Reglas de negocio

Dependiendo del entorno de implementación que se haya seleccionado para su

organización, se hará necesario integrar componentes a la plataforma técnica para

implementar procesos, específicamente dependiendo de la arquitectura de

software disponible, tenemos que aclarar cómo se van a implementar las reglas de

negocio

Las reglas de negocio son algoritmos que por lo general son encapsulados en

programas y que se pueden invocar a través de servicios. Sin embargo hoy en día

existen motores de reglas, llamados en inglés Business Rules Management

Systems (BRMS) que administran y ejecutan las reglas de negocio, independiente

de sus actividades en los procesos que las necesitan. Algunas Suite de BPM

(BPMS) traen motores de reglas incorporados, en otros casos existen BRMS

independientes que pueden ser invocados por sistemas de software. Cualesquiera

que sean las opciones por las que su organización ha optado, lo importante es que

no será necesario o mejor dicho no se recomienda modelar las reglas en BPMN, si

no identificar donde se utiliza e invocar estas en las actividades que las requieran.

BPMN 2.0 introdujo justamente para esos fines un tipo de actividad “regla de

negocio”, que indica en el diseño técnico el lugar donde hay q invocarlas

Modelar condiciones que representan “Reglas de negocio” no es una “buena

práctica” en el modelamiento de procesos. Para evitar que esto suceda el analista

debe aprender a diferenciar entre “reglas de negocio” y “reglas de ruteo”.

Gestión de reglas de negocio es una disciplina separada y como el nombre lo

indica reglamenta las condiciones del negocio. En gestión por procesos de

negocio, la administración centralizada e independiente de las reglas de negocio

toma la importancia de un factor crítico de éxito para el negocio. Hoy en día

existen sistemas de software especializados e independientes que administran y

ejecutan las reglas de negocio. Estas funcionalidades pueden ser invocadas

desde un sistema de workflow o BPMS, pero también muchos BPMS traen

editores de reglas, aunque este no sea independiente del sistema.

En el modelamiento de procesos hay que distinguir claramente entre reglas de

negocio y reglas de ruteo, siendo solo estas últimas las que se deben modelar.

Para editar mostrar reglas de negocio por lo general se usan tablas de decisión.



empresas

175

Se traspasan las condiciones y las reglas a una tabla de decisión como la

siguiente:

Tabla 9: Ejemplo de Tabla de decisiones [20]

Condiciones Decisión

Tipo de cliente Valor Revisar credibilidad

Cliente VIP No aplica No

Cliente normal >300.000 Si

<=300.000 No

Cliente nuevo >50.000 Si

<=50.000 No

¿Cómo se relaciona la tabla de decisión con el modelo de proceso? A modo de

ejemplo muestra la figura como deben modelarse reglas de negocio en BPMN:

Antes del XOR-Gateway se introduce una actividad especializada que no tiene

otra función que ejecutar las reglas de negocio asignadas.

El resultado de la actividad es la decisión de lo que debe hacerse a

continuación

El XOR-Gateway ahora solo tiene la función de ruteo a través del flujo de

secuencia

La asociación a la tabla de decisión se realiza en los atributos de la tabla, o se

puede asociar un objeto de datos tipo input a la actividad.

A continuación se describen las diferencias de ambos tipos de reglas:

Reglas de ruteo son evaluadas por XOR-Gateways o flujos de secuencia

condicionales. Las reglas de ruteo son generalmente estables, simples y no

entrelazadas.

Reglas de negocio pueden ser muy complejas y se administran en forma

independiente del modelo de proceso. La regla de negocio puede entregar la

variable que controla el flujo de la regla de ruteo.

Con la finalidad de diferenciar estos casos BPMN 2.0 ha definido una actividad del

tipo regla de negocio. La OMG introdujo justamente este tipo de actividad para

promover la separación de “modelos de procesos” y “modelos de reglas”.

Importante de mencionar en el contexto de la aplicación de reglas de negocio en

modelos de proceso BPMN, es que se puede asociar un evento de condición a un



empresas

176

sistema de reglas de negocio. Sin embargo BPMN aún es pobre en cuanto al

grado de expresividad del evento de condición. Desde el punto de vista técnico se

podría interpretar la asociación de una regla a un evento de condición ya que un

motor de reglas se encuentra continuamente revisando si sucede el evento que

cumple con la condición de la regla especificada. Si ocurre, el motor de reglas da

el aviso al sistema de workflow sobre el evento ocurrido de forma que el evento de

condición asociado a la regla dispare el inicio o la continuación del proceso.

7.3.3.5 Paso 5: Simulación

La simulación es un método para determinar la factibilidad y eficiencia de las

opciones propuestas de los procesos rediseñados, la simulación también puede

ser usada para probar la lógica y consistencia de los procesos antes de la

implementación.

Se requiere una gran cantidad de esfuerzo significante y no debería ser

subestimada o tomada a la ligera, para esto será necesario obtener las métricas

necesarias y las asunciones para correr la simulación. La simulación es un buen

método para probar varios escenarios por ejemplo ¿qué pasaría si se duplica o

cuadruplica la demanda? ¿Qué pasa si se incrementa el número de personas en

un área del proceso? Varios escenarios deben ser probados en las métricas y

asunciones

La simulación debería ejecutar cuando sea evaluado y, finalmente la actividad

basada en costos y la estimación de las capacidades planeadas se han

completado. Esto asistirá en la determinación de las medidas de rendimientos

para las opciones del proceso.

Las opciones podrían ser reducidas para una mayor factibilidad en este paso, y

estas opciones podrían ser trabajadas con varios stakeholders en el siguiente

paso. La simulación permite – cuando es requerido- que muchos supuestos sean

realizados (por ejemplo, la frecuencia y la simulación de la demanda, la velocidad

de trabajo efectivo, numero de errores etc.) es crucial que estas suposiciones

sean documentadas y suministradas a los stakeholder, incluyendo el contexto en

el que fue determinado.

Estas soluciones sugeridas, junto a las evidencias del soporte, deberían ser

procesados y los procesos completamente modelados para la primera distribución

de los primeros workshops.



empresas

177

7.3.3.6 Paso 6: Actualizar la matriz de capacidad de personas.

En este paso se debe tener en cuenta la matriz de capacidad que fue creada en la

fase anterior, esta matriz necesita ser revisada, o creada para los procesos

futuros. Esta información debería ser para comparar con la matriz de capacidad de

los procesos actuales. Un análisis de diferencias debe ser vinculada a las

personas, con planes de acción específicas y cambios potenciales para la

estructura organizacional.

En este paso también se deben tener en cuenta el rediseño de los roles, al cual se

entra en detalle a continuación:

Rediseñar los roles

Una vez se satisfacen las tareas grupales en las actividades, entonces se puede

iniciar para el grupo las actividades.

Los autores del libro Business Process Management han llamado roles a los

trabajos, porque los roles son de naturaleza genérica en este punto, y la palabra

trabajo parece que implica un rol específico para una persona.

Para este paso, un rol es definido como de más alto nivel que una persona o

descripción de un trabajo; es un rol genérico, por ejemplo un recepcionista o un

asesor de clientes (nota: se reconoce un trabajo para una persona particular

puede comprender muchos roles, depende del tamaño de la organización o del

departamento, sin embargo, en el ejemplo se asume que este no es el caso).

Este podría ser un proceso iterativo grupal de varias actividades y roles

discutiendo con las administraciones y las personas que podrían incluirse en esta

ejecución y reagrupándolas, mientras usted y todos los stakeholders están

satisfechos con los resultados de la nueva definición de roles.

Aquí entrar el valor de hablar un momento para mostrar algunos componentes

principales y que debería agregarse durante la creación de las actividades y roles.

La bien conocida matriz RACI (o RASCI o RASIC) es un método útil de ayuda para

identificar actividades, roles y responsabilidades durante esta fase del proyecto.

Este modelo ayuda a describir claramente que debe hacer, quien lo debe hacer,

para que estos nuevos procesos se habiliten y se ejecuten.

RASCI/ RACI es una abreviación de:

R = Responsabilidad – la persona quien es propietaria del problema o actividad



empresas

178

A=A quien se le rinden cuentas – es quien debe aprobar el trabajo antes de q se

realice

S= Soporte – puede proveer recursos u otra información en un rol de soporte en la

realización de un trabajo o actividad

C= Para ser consultada- tiene la información y/o la capacidad que se necesita

para completar el proceso o actividad

I = Para ser informada- deben notificarse los resultados del proceso o actividad,

pero no necesita ser consultada durante la ejecución

Estos componentes principales pueden ser vistos en una tabla, la siguiente tabla

es un ejemplo de cómo cinco (5) roles interactúan con el rol genérico

La secuencia para completar esta tabla es la siguiente:

1) identificar todas las actividades como fueron definidas, se listan en el eje

vertical

2) identificar todos los posibles roles futuros, estos se listan en el eje

horizontal y se completan las celdas en la tabla con una R, A, S, C, I por

cada actividad

3) Resuelva diferencias y sobre posiciones. La situación puede ocurrir donde

no hay „RS‟ o no hay „AS‟ para una actividad, una regla general, todas las

actividades deben tener solo una R y una A

Tabla 10: Tabla RACI [16]

Administración de la

unidad de negocio

Gerente Jefe de la unidad

de negocio

Líder de equipo

Asesor de cumplimiento

Actividad 1 R A Actividad 2 A R S C Actividad 3 RA I I Actividad 4 RA C Actividad 5 A R S

En una revisión de los roles genéricos de las personas, la organización tiene una

única oportunidad no solo para autorizar los puestos y hacer el trabajo de las



empresas

179

personas más interesante, también para recompensarlos de una mejor manera

(otras como financiero) y proveer oportunidades de promoción.

La que mayor se toma en cuenta y la más fácil es que se „venda‟ a las personas y

se implemente. La mayoría de las descripciones de los roles incluyen niveles de

autoridad, políticas y procedimientos, asignación de responsabilidades y desarrollo

de consideraciones.

Sin embargo, una descripción de un rol para un proceso debería incluir también

medidas de rendimiento para cada parte del proceso o subproceso.

7.3.3.7 Paso 7: Workshop de soluciones propuestas.

El equipo del proyecto debe tener las opciones de procesos reducidas a un

pequeño número, y el propósito del siguiente paso del workshop es reunir a todos

los stakeholders para determinar si las soluciones propuestas satisfacen todas las

necesidades de los stakeholders. Los stakeholders deberían incluir lo siguiente:

Negocios

Stakeholders externos ( canales de distribución, vendedores, proveedores,

inversores)

Personal

Información de tecnología

Riesgos operacionales

Auditoría interna

(tal vez) auditoría externa, dependiendo de los procesos.

Esto es donde las opciones de los procesos documentados son presentadas, junto

a los resultados de la ejecución de varias simulaciones, los escenarios de las

actividades basadas en costos y otra evidencia de soporte

Esto es siempre un debate de cómo los procesos deberían ser diseñados

alrededor de la auditoria, requerimientos cumplimiento o requerimientos de riesgos

o no. Se sugiere que se debería considerar rediseñar el proceso lo más eficiente y

efectivo posible, satisfaciendo el negocio y las necesidades primarias de los

stakeholders, y luego considerar la auditoria, cumplimientos y requerimientos de

riesgo operacional en un segundo paso. Auditoria, conformidades y

requerimientos de riesgos operacionales no deben ser dirigidos al rediseño, pero

tampoco deberían ser ignorados: la organización tiene que satisfacer estos

requerimientos.



empresas

180

Otro enfoque es fuera de las reglas básicas desde una auditoria, conformidades y

perspectivas de un riesgo operacional, y el esfuerzo para incluir estos en los

procesos que serán diseñados.

El Framework de 7FE también recomienda que los negocios y los stakeholders

externos críticos participen en el workshop para asegurarse que el rediseño de los

proceses suple con las necesidades y nos son cambiadas por otros

requerimientos competitivos. Solo una vez ellos deberían tomar lugar en las

conformidades, riesgos operacionales, y las auditorías internas y externas que

serán incluidas.

Uno de los requerimientos ha sido dirigido, los negocios pueden entonces tomar

un interesante y expandido proyecto original para tomar una dirección de

mejoramiento BPM

Los resultados de este workshop son: la aceptación y cierre de sesión de las

opciones de nuevos procesos para seguir.

Demostrar y validar la factibilidad

El siguiente paso es demostrar y validar la factibilidad de la solución propuesta,

este análisis es necesario para asegurar que las opciones de rediseño son

operacionalmente viables o factibles:

Los procesos serán habilitados para ser soportados des de una perspectiva de

negocio

Los negocios serán habilitados para funcionar de manera eficiente y efectiva

como un resultado de los nuevos procesos.

Si los nuevos procesos son automatizados, entonces es a menudo una excelente

idea construir una demostración o prototipo de los procesos propuestos. Los

proveedores a menudo se refieren a esta como una prueba de concepto. Si el

proceso es para ser manual, entonces se deberían crear tutoriales de negocio,

cuando se conduce esta demostración o este tutorial, se debe preguntar a los

“Testers” que se debe realizar con las excepciones.

Los roles del juego también ayudan aquí, recuerde siempre regresar a evaluar las

nuevas opciones contra los objetivos del proceso aceptados en el workshop

ejecutivo inicial.



empresas

181

Si es necesario, como resultado de esta actividad, regresar al paso del workshop

de innovar, si se encuentra que algunos aspectos de los procesos no son factibles

o no pueden ser implementados

7.3.3.8 Paso 8: Análisis de diferencias de proceso

Es extremadamente útil desarrollar un análisis de diferencias entre el

entendimiento y el proceso nuevo innovador. Esperando hasta que las opciones

de nuevo procesos hayan sido seleccionadas durante el workshop de la

soluciones propuestas donde se guardara el desarrollo de varias versiones de

este documento. El propósito de completar este paso es suministrar una

comparación entre el viejo proceso y el nuevo proceso (AS-IS, TO-BE), el

departamento de tecnología y desarrolladores del material de entrenamiento. Este

análisis también provee un indicador de la magnitud del cambio. Este análisis de

diferencias debería cubrir los siguientes temas por cada proceso:

Un breve resumen del proceso actual

Un breve resumen del nuevo proceso

Principales cambios entre los procesos

Problemas del proceso

Métricas relevantes

Negocios y comentarios que impactan el proceso

Cambios requeridos

Nuevas oportunidades

Plazos identificados del proyecto

Identificar beneficios del nuevo proceso.

El análisis de diferencias de los procesos también debería ser comentado en el

entrenamiento, salud ocupacional y problemas estructurales de la organización, y

debería ayudar en los aspectos de cambio administrativo en el negocio.

Este análisis debe incluir la siguiente información:

Un análisis completo del impacto de los cambios en los procesos de la

organización

Opciones de implementación y comentarios

Una evaluación general de los impactos identificados

Una identificación de los plazos del proyecto

Impactos del entrenamiento y los requerimientos identificados

Problemas en los cambios administrativos identificados

Impactos en la estructura organizacional y los requerimientos identificados



empresas

182

Riesgos del proceso y de la implementación.

7.3.3.9 Paso 9: Preparación y reunión de aprobación

El caso de negocio inicial fue escrito durante la fase de cimientos, donde se

identificaran algunos beneficios estimados, durante esta fase de innovar del

proyecto, después de que las opciones de rediseño han sido terminadas, se debe

tener más información detallada disponible y habilitada para aprovisionar los

beneficios de una manera adecuada.

El caso de negocio debería ser habilitado para estar más lejos de la definición en

este paso, porque del trabajo completo durante la simulación, la actividad basada

en costos y el paso de las métricas: los beneficios (por ejemplo, procesos

mejorados) y los costos (Por ejemplo, costos de implementación) son mucho más

claros. (Algunas veces, sin embargo es difícil obtener los costos en este paso del

proyecto, una vez las opciones del nuevo proceso han sido decididas y el proyecto

avance a la fase de desarrollo, los costos de desarrollo de implementación pueden

ser determinados más exactamente.

Estos nuevos costos y métricas deben ser comparados con las métricas obtenidas

durante la fase de entendimiento. Una comparación entre estas dos

(entendimiento e innovación) puede proveer beneficios cuantificables para el

rediseño de los proceso. Esto debería proveer una evidencia más robusta que

soporte el caso de negocio.

Asimismo, el caso de negocio debería ser un objetivo para una buena

implementación y transición desde el proyecto a las operaciones usuales del

proceso. Una gran mayoría es posible, esto incluye el conocimiento de la

información con respecto a la nueva situación operacional y el impacto sobre las

personas.

Reportes y presentaciones

También en este paso es donde son desarrollados los reportes y /o

presentaciones, que soportan el caso de negocio, que se entregara al

administrador principal para su aprobación. Obviamente la aprobación es

importante, y requiere que todos los esfuerzos estén centrados en el desarrollo de

estos reportes y/o estas presentaciones, esta presentación debería tener una

planeación y horario durante el paso inicial de comunicaciones, y debe ser dirigido

al administrador principal o los ejecutivos.



empresas

183

El propósito del reporte es suministrar el estado del proyecto, resultados y

recomendaciones de la fase de innovar, y esto debería ser soportado por una

presentación profesional. Esta es la oportunidad del equipo del proyecto y sus

patrocinadores para vender las recomendaciones al ejecutivo para su

financiamiento.

Aprobación

Después de la reunión anterior, la organización aprueba las opciones

recomendadas, cada organización tendrá sus propios procesos para seguir la

aprobación de un caso de negocio, esto ha sido aclarado y tomado de las cuenta

durante la fase de cimientos del proyecto.



empresas

184

7.4 Fase de Desarrollo

Esta fase se centrará en describir el desarrollo de una solución automatizada de

BPM y los temas específicos en torno a dicha solución en comparación con una

solución automatizada 'Standard'.

Esta fase en la que la preparación debe ser completada y la solución preparada.

El concepto detrás de una solución automatizada de BPM es que con la tecnología

BPM, ahora es posible extraer en sus propias “capas” las reglas de negocio y los

componentes de proceso de una aplicación. Smith y Fingar (2002) creen que un

sistema BPM comprende tres grandes áreas, como se muestra en la Grafica 47:

Integración de Sistemas Internos (EAI Component)

Automatización de lo referente a los procesos (reglas de Negocio y repositorios

de procesos)

Colaboración con entidades externas – clientes, socios de negocio, canales de

distribución, etc.

Lo anterior es con el fin de darle a la empresa la suficiente flexibilidad para

adaptarse a los cambios del negocio en un futuro y en tiempo real.

Grafica 47: Sistema BPM [16]



empresas

185

FASE DE DESARROLLO

7.4.1 Entradas de esta fase

Metas del proceso Proceso TO-BE y documentación Arquitectura de la empresa y de las TI

PASOS

Gráfica 48: Pasos de la fase Desarrollar (Tomada y adaptada de Business Process Management - Practical Guidelines Successful Implementations)


Software desarrollado Anexo 14: Resumen de la solución Anexo 14: Guiones de prueba de software y resultados Especificaciones de hardware y disponibilidad Anexo 14: Guiones de prueba de hardware y resultados Anexo 14: Guiones de prueba de la integración y resultados.

7.4.3 Pasos





empresas

186


Durante la fase de desarrollo es importante comunicar el alcance y la propuesta de

automatización a los stakeholders. También es importante abordar las principales

cuestiones que surgen en caso de automatización, tales como:

¿Voy a mantener mi trabajo?

¿Qué nuevas habilidades necesitare?

¿Cómo cambiará mi trabajo?

La automatización también puede influir en la interacción con proveedores, socios

y clientes. Con los servicios web y SOA, se hace mucho más fácil integrar los

procesos a través de las fronteras de la organización. Si ese es el caso, la

comunicación debe extenderse a las partes relacionadas, asegurándose que no

solo los beneficios y el impacto de la automatización son especificados, sino

también el progreso, los problemas y los retrasos potenciales.

7.4.3.2 Paso 2: Determinar componentes BPM

Una de las primeras decisiones en la fase de desarrollar es qué componentes

automatizados de BPM son necesarios - se trata de tomar una decisión con

respecto a las 'herramientas' que serán necesarios.

Una solución automatizada puede consistir de uno o más de los siguientes

componentes:

Motor de procesos (Workflow)

Motor de reglas de Negocio

Integración (EAI)

Sistema integrado de gestión de documentos

Monitoreo de Actividades de Negocio (BAM)

Otros componentes de una solución automatizada son un modelador de procesos

y herramientas de gestión, simulación, costo basado en actividades, y BSC. La

siguiente Tabla 11 muestra todos los componentes:



empresas

187

Tabla 11: Componentes de una solución automatizada de BPM [16]

Modelamiento y Gestión de Procesos

Motor de Procesos (Workflow)

Monitoreo de Actividades de Negocio

(BAM)

Costos basados en Actividades

Motor de Reglas de Negocio

Simulación Integración (EAI)

BSC Sistema integrado de gestión de documentos

Cuando automatizamos parte de un proceso, el mayor desafío del proyecto es

obtener la información que el proceso requiere. Esa información puede estar

dispersa en diversos sistemas legados.

7.4.3.3 Paso 3: Actualizar especificaciones funcionales y técnicas

Debe haber una estructura de enfoque a las especificaciones (funcional, técnica y

sistema o diseño) de desarrollo y pruebas de una solución BPM, sin embargo en el

diagrama-V (Grafica 49) se mostraran los “enlaces faltantes” entre las propias

especificaciones y las especificaciones y pruebas.

A mano izquierda de la figura se muestran los requerimientos de negocio y los

documentos relacionados con el diseño y al lado derecho se muestran las pruebas

que verifican lo que es producido por el equipo de desarrollo conforme con los

requerimientos y diseños. El desafío es asegurar que las expectativas son

cumplidas desde una perspectiva de negocio, y es el negocio quien decide si esto

se ha logrado.

Las cajas por encima de la línea de puntos se relacionan con la funcionalidad,

mientras que las cajas por debajo de la línea de puntos se relacionan con

aspectos técnicos.



empresas

188

Grafica 49: Enlazando requerimientos, realización del sistema y pruebas [16]

Un problema común durante la fase de desarrollo es el conflicto entre lo que los

negocios quieren y como los desarrolladores interpretan los requerimientos. Esto

es a menudo una función de cómo estos dos stakeholders trabajan juntos y

entienden las implicaciones de esa relación de trabajo.

El camino que recorre un requerimiento, desde que es escrito por el negocio, re-

escrito por el personal técnico e interpretado por el equipo de desarrolladores de

BPM, pierde características administrativas y gana características técnicas, por lo

que en el momento de las pruebas es posible que el stakeholder diga que la

solución desarrollada no es lo que él quería, o que lo que se hizo no es a lo que él

se refería.

Esos riesgos pueden ser minimizados de varias maneras, incluyendo las

siguientes:

Realizar análisis "¿Qué pasaría si?"

Realizar simulaciones

Especificar que esta fuera del alcance

Separar el diseño funcional del diseño técnico



empresas

189

Especificar y buscar un acuerdo en las consecuencias del desarrollo

Es crucial incluir los requerimientos de software y de hardware, en la mayoría de

los casos existe una dependencia entre los dos.

7.4.3.4 Paso 4: Desarrollar el software

Existen básicamente dos (2) maneras de desarrollar una solución automatizada de

BPM: La primera de ellas consiste en apoyarse en alguna suite de BPM (BPMS),

sistema de workflow (WfMS) u algún otro process engine, u optar por el desarrollo

propio, el cual puede tener dos tipos de enfoque: El enfoque tradicional

(especificar, desarrollar, probar) “Software development life cycle” (SDLC) y el

enfoque iterativo de “Rapid application development” (RAD).

Sin embargo, cualquier solución automatizada de BPM tendrá tres (3) capas a

tener en cuenta:

1. Capa de presentación de la solución a los usuarios.

2. Capa de procesamiento que contiene las tareas automatizadas.

3. Capa de integración con otros sistemas y bases de datos.

Es crucial entender que cada una de estas tres capas necesita un enfoque

diferente para el desarrollo y las pruebas ya que involucra a diferentes tipos de

personas. La capa de presentación está enfocada en los usuarios finales y

representa su vista del sistema. Algunos problemas a considerar son los

siguientes:

¿La vista tiene una apariencia lógica y le es familiar a los usuarios finales?

¿Los diferentes tipos de usuarios con diversas necesidades tendrán forma de

interactuar con el sistema?

La capa de procesamiento trata con las actividades que el sistema debe realizar.

Esta capa debería ser completada con personas que tienen un buen

entendimiento de los negocios, así como de los objetivos del proyecto. Un

problema importante a tener en cuenta es la documentación y, con la creciente

popularidad de los pilotos, RAD y el desarrollo de herramientas BPM, hay una

tendencia creciente de no documentar todo, o no con el detalle que es necesario.

Los desarrolladores argumentan que esa documentación está implícita en la

configuración de los sistemas y que por lo tanto puede ser extraída de ahí.

Mirando esos sistemas se tendrá un resumen de que ha sido configurado, pero no

de porqué esa configuración ha sido escogida.



empresas

190

La capa de integración de datos es más técnica, y se basa en las interfaces con

otros sistemas. Un conocimiento técnico profundo es requerido, así como una

clara comprensión de cómo se enlazan los sistemas con la solución automatizada

de BPM.

Uno de los aspectos más desafiantes de la fase de desarrollo de software de un

proyecto no es sólo el desarrollo actual, sino también la migración al nuevo

sistema. El camino al éxito está repleto de proyectos en los que se han

subestimado los problemas involucrados con la migración y las interfaces. Se ve

muy fácil, pero es engañosamente complicado; pero como no pensar que es fácil

si a simple vista es tomar los modelos de negocios, los procesos, la información y

transferirlos de un sistema a otro, pero es aquí donde pueden surgir una serie de

cuestionamientos como los siguientes:

¿Son correctos los modelos de negocios, los procesos y la información alojada en

el sistema actual?

¿Debería la organización primero migrar el sistema existente al nuevo sistema y

luego hacer los cambios? ¿O debería ser al contrario? a menudo, la última es la

solución preferida, ya que muchos proyectos y organizaciones se sienten

incapaces de hacer cambios en el nuevo sistema una vez que se puebla de

información.

Mientras se hace este análisis objetivo, es importante diferenciar entre la

importancia que los actores se ponen sus requerimientos diferentes. El enfoque

MoSCoW de la DSDM (método dinámico de desarrollo de sistemas) es muy

práctico aquí. Este enfoque rompe la prioridad de las necesidades en las

siguientes categorías:

Debe tener(Must have)

Debe tener, si es posible (Should have if at all possible)

Podría tener esto si no afecta a ninguna otra cosa (Could have this if it does not

affect anything else)

No lo tendrá (en esta versión), pero me gustaría tenerlo más tarde (Won‟t have,

but would like to have it later)



empresas

191

Opcion1: Desarrollo apoyado en un process engine

Desarrollar una solución automatizada de BPM se torna mucho más efectivo y

simple hacerlo con un process engine.

Los modelos TO-BE bien diseñados pueden montarse directamente en un process

engine. Dicho de otra forma el modelo TO-BE es sinónimo de código fuente para

el process engine, lo que implica de manera importante: Los modelos tienen que

estar correctos y lo suficientemente detallados como para ejecutarse.

En este momento los modelos que vamos a implementar en el BPMS no solo

deben estar sintácticamente y semánticamente correctos, si no también tienen que

considerarse todo el resto de aspectos técnicos que son necesarios para

automatizar procesos con un process engine, por ejemplo los casos de excepción

y errores técnicos, finalmente estamos hablando de código fuente.

Además de las integraciones y otros factores clave a la hora de desarrollar

cualquier tipo de proyecto, BPM se diferencia en que para implementar de manera

adecuada el modelo de procesos en un Process Engine, es necesario considerar

lo siguiente:

Aclarar y validar el modelo TO-BE

Ampliar el modelo de procesos en aspectos técnicos, si se utiliza un engine

BPMN2.0.

Testear y ejecutar puesta en marcha de acuerdo a los métodos tradicionales de

desarrollo de software.

Opcion2: Desarrollo propio

Una solución BPM implementada con desarrollo propio (independiente del enfoque

elegido, ya sea SDLC o RAD) en algún lenguaje como java, C# u otro, es la

posibilidad más arcaica y antigua de programar toda la solución de workflow. Pues

el <<process engine>> seria simplemente su compilador o interpretador. A

diferencia de la alternativa de utilizar una plataforma BPMS, en el caso de

desarrollo propio no podrá traspasar directamente de los modelos de procesos

TO-BE a una implementación técnica. En este caso al igual que en cualquier otro

proyecto de desarrollo debe hacer primero una especificación para el sistema,

luego descomponer el modelo de procesos en casos de uso y llevarlos a una

especificación representada con diagramas de actividad UML.

En pocas palabras sería una aberración implementar una solución BPM con

desarrollo propio.



empresas

192

Sin embargo, si los dueños de negocio consideran esta posibilidad como la más

factible, es la que se debe implementar por lo que a continuación se dará una

breve descripción de los dos tipos de enfoque de desarrollo propio.

Opcion2.1: Desarrollar con el enfoque tradicional SDLC

La siguiente figura (Grafica 50) muestra los probables pasos involucrados en el

desarrollo con enfoque tradicional SDLC de un proyecto BPM.

Mientras este enfoque es testeado y comprobado como una solución de

desarrollo, no es necesariamente el mejor o más apropiado enfoque para un

proyecto BPM.

El enfoque tradicional SDLC requiere que el administrador del proyecto monitoree

el proyecto de manera continua para asegurarse que siguen la especificación de

requerimientos y que los negocios aun soportan las especificaciones originales.

Con demasiada frecuencia, el proyecto entrega una solución de software después

de un largo periodo de desarrollo y testing, solo para encontrar que los

requerimientos de negocio han cambiado.



empresas

193

Grafica 50: Enfoque tradicional SDLC [16]

Determinar

Componentes

del sistema

Desarrollar

cambios del

sistema

Formular

Reglas de

Negocio

Determinar

impacto en el

Negocio

Desarrollar

especificaciones

del sistema

Desarrollar

estrategia de

Migración y

Documentacion

Construir

Infraestructura

física

Desarrollar

Aplicaciones e

Interfaces

Construir

Infraestructura

de TI

Unidad de

Prueba

Unidad de

Prueba

Finalizar estrategia de pruebas, planeación y guiones

Prueba del

sistema

Pruebas de

Integración y

de Regresión

Pruebas de

Aceptación

de usuarios

Desarrollar

cambios del

sistema

Desarrollar Documentacion(Procedimientos y

entrenamiento del sistema)

Opción 2.2 Desarrollo rápido de Aplicaciones

Entre los enfoques tradicionales de desarrollo propio de soluciones BPM, el

enfoque RAD es la solución automatizada de BPM más usada, pues ofrece la

posibilidad de configurar los procesos de una manera más interactiva entre la

empresa y los técnicos. Este enfoque es donde los expertos de procesos y / o

propietarios de los procesos se sientan con un desarrollador técnico y "modela" la

solución automatizada. Este es un enfoque especialmente bueno en un escenario

piloto, para explorar las oportunidades que una nueva solución de BPM ofrece.

También le proporcionará al negocio una rápida apariencia (Look and Feel) de la

solución.

Es esencial que la gente de negocios que facilita la información sobre los procesos

ya que son los responsables de que estos procesos estén plenamente conscientes

de la configuración, su lugar dentro del contexto mayor y las consecuencias de las

decisiones que tomaron. Si esto está claro para ellos, inevitablemente se generará

un sistema dominado por TI, donde el negocio tendrá un conocimiento insuficiente

o solo influenciará sobre el desarrollo y los resultados.

Como la tecnología BPM mejora aún más, este enfoque obtendrá un impacto

significativo y beneficios en el negocio.



empresas

194

7.4.3.5 Paso 5: Determinar hardware

El hardware puede incluir los siguientes aspectos: Computadores para usuarios,

servidores, redes, aparatos relacionados, tales como impresoras, scanner y

medios de almacenamiento. Los problemas que deberían considerarse incluyen lo

siguiente:

Compatibilidad: ¿Son todos los sistemas capaces de comunicarse con los

otros sistemas, particularmente, las interfaces y plataformas?

Escalabilidad: ¿Pueden los sistemas propuestos escalar para hacer frente a

aumentos considerables en los volúmenes de transacción?

Mantenibilidad y soporte: ¿Están todos los componentes de hardware

asignados a personas capacitadas en mantener su componente en particular y

proporcionar o hacer arreglos de apoyo para los usuarios?

Por último, asegúrese siempre de que el entorno de pruebas de hardware es

exactamente el mismo que el futuro entorno de producción. Muchos sistemas se

han probado perfectamente en el "laboratorio", sólo para fallar en producción,

porque los dos no son exactamente iguales.

7.4.3.6 Paso 6: Pruebas

Las pruebas son un paso crucial en la fase de desarrollar. Es el momento donde la

aplicación desarrollada es comparada con los requerimientos de negocio iníciales.

La ISO describe las pruebas como una:

Operación técnica que consiste en la determinación de una o más

características de un producto, proceso o servicio dado, conforme a un

procedimiento especificado.

Una definición más apropiada de pruebas para una aplicación de software es:

Un proceso de planeación, preparación, ejecución y análisis, destinadas a

establecer las características de un sistema de información, y demostrar la

diferencia entre el estado actual y estado requerido.

Probar es por lo tanto una actividad fundamental que debe ser planeada de

manera adecuada y en detalle, y no se debe dejar para el final en el proyecto. Si

los escenarios y guiones de prueba se completan en este momento, habrá una

comprensión más clara de las necesidades operativas por parte del negocio y por

parte de los desarrolladores. Los desarrolladores comprenderán la base sobre la



empresas

195

que será su nuevo sistema de evaluación, lo que contribuiría a disminuir el riesgo

asociado a un malentendido entre los requerimientos del negocio y los resultados

del desarrollo.

Algunos problemas importantes a tener en cuenta incluyen lo siguiente:

Es importante recordar que más de la mitad del tiempo involucrado en

actividades de pruebas es requerido que pase en la preparación y planeación,

y el restante en la ejecución de las mismas.

Es casi imposible y altamente indeseable completar el 100 por ciento de la

prueba, ya que los costes y los plazos involucrados serán prohibitivos. Es

mejor completar un enfoque estructurado de pruebas, maximizando la

efectividad y minimizando el esfuerzo.

Se debe poder distinguir entre los siguientes tipos de pruebas:

Unidad de prueba: Es una prueba ejecutada por los desarrolladores en un

entorno de laboratorio que debería demostrar que una actividad o paso

particular de la solución automatizada de BPM cumpla con los requerimientos

establecidos en el diseño de especificaciones.

Prueba de Integración: Es una prueba ejecutada por los desarrolladores en

un entorno de laboratorio que debería demostrar que una función o un aspecto

de la solución automatizada de BPM cumpla con los requerimientos

establecidos en el diseño de especificaciones.

Prueba del sistema: Es una prueba ejecutada por el desarrollador en un

entorno apropiado de laboratorio que debería demostrar que la solución

automatizada de BPM y sus componentes cumplen con los requerimientos

establecidos en la especificación funcional y de calidad.

Prueba de Aceptación Funcional: Es una prueba ejecutada por los

administradores de sistemas y equipos de pruebas en un entorno que

simule el entorno operacional en lo máximo que se pueda, esto debería

demostrar que la solución automatizada de BPM cumple con los

requerimientos funcionales y de calidad.

Prueba de Aceptación de los Usuarios (UAT): Es una prueba ejecutada

por los usuarios del sistema donde, en “la sombra” de un ambiente

operacional, la solución automatizada de BPM será probada para demostrar



empresas

196

que cumple con los requerimientos de negocio. Estas pruebas están

incluidas en la fase de Implementación.

Prueba de Retroceso: Tienen como objetivo comprobar que todas las

partes del sistema siguen funcionando correctamente después de la

implementación o modificación de una solución automatizada de BPM.

El proceso normal de pruebas debería ser seguido. La secuencia usual es así:

1. Determinar los objetivos de las pruebas. Probar siempre involucra un balance

entre los beneficios de probar y su relación con los costos: 100% pruebas es

casi imposible y extremadamente costoso.

2. Determinar y escribir una estrategia de pruebas: Esta es una estrategia sobre

como la organización desea enfocar las pruebas. Debería incluir unidad de

prueba, UAT, prueba de integración, prueba de retroceso, etc.

3. Escribir plan de pruebas: La organización se decide por el número y tipo de

casos de prueba que deben aplicarse. Recuerde asegurarse que todos los

stakeholders apropiados y otros equipos del proyecto estén involucrados.

4. Escribir varios casos de prueba: El volumen de los casos de prueba dependerá

del tamaño y complejidad del proyecto. Lo más importante es cubrir todos los

escenarios posibles.

5. Ejecutar las pruebas: Los casos de prueba y guiones de prueba son

completados.

6. Revisar los resultados y decidir cómo proceder: Las opciones son seguir

adelante con la implementación, parar la implementación hasta que los

problemas sean solucionados, seguir adelante con la implementación y

asegurarse que los cambios van a incorporarse en el camino, o una

combinación de esas tres.



empresas

197

7.5 Fase de Implementación

En esta fase de implementación se pondrá en marcha el proyecto en un ambiente

real, se tendrán en cuenta muchos factores que definirán el éxito o fracaso del

proyecto desarrollado a lo largo del framework, a continuación se exponen una

serie de pasos que se deben tener en cuenta durante el proceso de

implementación en una compañía.

FASE DE IMPLEMENTACIÓN

7.5.1 Entradas de esta fase Estrategia de Implementación. Matriz de capacidad de Personas Solución de Software desarrollada y documentada

Pasos:

Grafica 51: Pasos de la fase de Implementación (Tomada y adaptada de Business Process Management - Practical Guidelines Successful Implementations)



empresas

198

7.5.2 Salidas de esta fase Personal entrenado y motivado Puesta en marcha, marcha atrás y planes de contingencia Estrategia de implementación Resultados de las mejoras de procesos o nuevos procesos. Resultados de las mejoras de procesos o nuevos procesos que se

encuentran funcionando satisfactoriamente Solución implementada

7.5.3 Pasos:




Una buena implementación requiere buena comunicación, esto incluye dos

maneras reales de comunicación. Invitando a una participación activa de los

usuarios en un proyecto es una excelente sugerencia y esto podría conducir a

críticas interesantes, comentarios y/o sugerencias que contribuyan al objetivo

completo del proyecto. Es importante entender que estar en constante

comunicación disminuye la resistencia al cambio.

7.5.3.2 Paso 2: Actualizar la estrategia de implementación

Al comienzo del proyecto la estrategia de implementación podría haber sido

determinada, cuando se llega a la fase de implementación es crucial realizar una

revisión completa de la estrategia de implementación porque:

El equipo del proyecto y la organización tendrán un mejor entendimiento de las

propuestas de cambio.

La estrategia de implementación fue tomada desde la situación actual esto

podría haber cambiado desde la determinación inicial hasta la estrategia de

administración.

El Framework 7FE que se encuentra en el libro Business Process Management

expone una serie de escenarios de implementación que se mostrarán a

continuación:



empresas

199

Tabla 12: Escenarios de implementación [16]

BIG BANG La propuesta de cambio presenta una mayor revisión Ventaja: velocidad al implementar Desventaja: los riesgos de ruptura en el negocio son altos

Paralelo La propuesta de cambio es presentada paso a paso, con la siguiente implantación iniciando antes de que se realice la implantación actual

Relay La propuesta de cambio es presentada paso a paso, con la diferencia que cada implantación inicia una vez el anterior se haya completado Ventaja: calidad, como la lección fue aprendida desde el anterior paso, puede ser tomado en cuenta y además el mismo equipo de implantación puede ser usado

Combinación Una combinación de los enfoques de implementación mencionados, tal vez un piloto pequeño y luego la construcción de una implementación larga. Ventaja: proveer la organización con beneficios de confeccionar una implementación para una situación específica, flexible, y manejable

7.5.3.3 Paso 3: Prepare para la prueba de aceptación de los usuarios

Durante este paso, si es aplicable, los casos de prueba para probar el negocio

son preparados.

Los usuarios actuales del negocio requieren probar la solución, ellos serán

capaces de probar esta solución completa desde una perspectiva de práctica

normal, desde esta etapa en el proyecto la solución solo será probada contra la

escritura de la especificación de los requerimientos de negocio, mientras tanto la

solución puede ser probada para la integración con la rutina diaria con los usuarios

del negocio, también como las asunciones implícitas y las expectativas de los

usuarios.



empresas

200

Idealmente, la preparación para una prueba de negocio deberá tener inicio durante

el diseño del nuevo proceso, eso podría ocurrir en la fase de innovar o de

desarrollo, dependiendo de las circunstancias particulares, si los casos de prueba

son desarrollados como una etapa temprana, la organización tendrá la habilidad

de comparar los casos de prueba con los resultados esperados en los negocios ,

las especificaciones técnicas y el diseño, asegurándose que no hayan diferencias

en los requerimientos.

7.5.3.4 Paso 4: Capacitar el personal

En la fase de innovar los nuevos procesos serán diseñados, la organización tendrá

desarrollados los procesos y tendrá definidos algunos cambios en la estructura de

la organización y en roles de trabajo. Es tiempo de entrenar a las personas que

ejecutaran estos procesos.

Solo como los escenarios de prueba serán desarrollados basándose en el

rediseño de los procesos, el material de entrenamiento podría ser creado desde la

documentación del rediseño de los procesos.

El entrenamiento podría tomar la forma de un curso normal o un entrenamiento en

el puesto de trabajo, la tutoría y el entrenamiento deberá continuar durante las

pruebas de negocio, pasos pilotos y la implementación inicial.

Obviamente el material de entrenamiento usado debe ser consistente y el este no

debe ser realizado con mucha antelación, en efecto, la mejor forma de entrenar es

justo antes de que las habilidades sean necesitadas para evitar pérdida de

conocimiento

Sugerencias con respecto al entrenamiento son:

Pequeña dosis de entrenamiento justo a tiempo.

Sesiones de entrenamiento individuales, asegurándose que la gente conozca

cuando ha sido su sesión programada.

Probar las competencias después del entrenamiento.

Monitorizar el rendimiento de trabajo después de un periodo de tiempo

apropiado.

Uno de los resultados del entrenamiento del personal puede ser el desarrollo y

entrenamiento de “súper usuarios” en los nuevos procesos, ellos estarán en la

línea frontal de las personas y estarán disponibles durante el paso de

implementación.



empresas

201

Este entrenamiento debería estar enfocado en más que solo actividades

principales o cualquier solución automatizada, también debería incluir aspectos

como:

Impactos de la solución propuesta.

Que cuellos de botella existen que serán abordados.

Cualquier nuevo cuello de botella que los participantes esperen que surja

durante el periodo de implementación.

Los beneficios y posibilidades de la solución propuesta.

7.5.3.5 Paso 5: Completar las pruebas de negocio y pruebas piloto

Aquí es donde se ejecutan las pruebas de usuario por el caso de prueba del

negocio, esto puede variar desde la ejecución de los datos o transacciones a

través de una solución BPM automatizada para una simulación manual de

transacciones procesadas a través del negocio. Obviamente el equipo necesita

haber sido entrenado en el sistema y los procesos antes de comenzar los casos

de prueba.

Es esencial en la organización:

Incluir clientes y proveedores donde sea apropiado.

Tener una fuerte administración de proyecto de los pasos aprobados.

Tener un mecanismo de retroalimentación que sea fácil de usar.

Escuchar y comunicarse honestamente, la retroalimentación es absolutamente

esencial esto será una gran idea para aprender de este paso.

Estar siempre preparados para hacer cambios sobre la marcha y alimentar de

nuevo los ciclos de entrega.

Comunicar los resultados de los pilotos y las pruebas.

Obtener testimonios del personal, clientes y proveedores.

Felicitar y recompensar a los miembros del equipo.

7.5.3.6 Paso 6: Tutor del personal

Como se mencionó anteriormente en el paso del entrenamiento, se seleccionan

personas que son entrenadas como los primeros súper usuarios, ellos podrían ser

útiles para entrenar la gente que falta y ser tutores durante el primer periodo de

uso del sistema.

Es importante que estos súper usuarios/tutores estén disponibles todo el tiempo

durante la fase inicial de implementación, y no se reanude su rol en el negocio



empresas

202

como es de costumbre hasta que se ponga en marcha lo que se ha instalado y

todos estén satisfechos. Es importante suministrar a estas personas incentivos

para que rompan sus actividades diarias e inviertan su tiempo y energía en el

proyecto. Estos incentivos no son necesariamente plata, podría incluir unos

nuevos cambios en el rol de estas personas y una manera de probar sus

habilidades para manejar los proyectos que podrían conducir a una promoción o

reconocimiento de la organización.

7.5.3.7 Paso 7: Cambios en la puesta en marcha

Una vez se pongan en marcha los nuevos procesos que han sido implementados

efectivamente, se debe asegurar que los procesos viejos y los sistemas de soporte

ya están disponibles para el personal. Esto es esencial que este en un

mecanismo de continuo mejoramiento.

Se debe reportar cambios en las relaciones y en la estructura organizacional que

también requiere implementación, esto será una manera de iniciar cualquier nuevo

proceso y esquemas de incentivos basados en resultados de rendimiento.

7.5.3.8 Paso 8: Monitoreo y ajuste

Durante los cambios de la puesta en marcha, se amplía el esfuerzo que se dedica

a monitorizar el progreso de la puesta en marcha y el progreso hacia el logro de

los resultados del negocio.

Es importante establecer indicadores de rendimiento para monitorizar el progreso,

algunos ejemplos de esto incluye lo siguiente:

El número de preguntas en las primeras semanas.

El número de errores en las primeras semanas.

El porcentaje de empleados que trabajan con el nuevo proceso.

El nivel de horas extras requeridas para obtener un trabajo bien hecho.



empresas

203

7.6 Fase de Rendimiento Sostenible

En esta fase se relata la necesidad de un cambio de un proyecto basado en un

proyecto basado en un desarrollo BPM. Aunque esta es la última fase del

framework, es la primera fase de BPM como un negocio como actividad usual.

El mejoramiento de procesos si una sostenibilidad podría decirse que no tendría

valor el esfuerzo, las veloces prácticas mejoras se desvanecen cerca al

crecimiento y cambio del negocio. Además, las expectativas que se tienen

construidas con los stakeholders no se alcanzarían a largo plazo, uno de los giros

harían que ser aumente la dificultad para obtener estos compromisos y confiar

para proyectos futuros.

El propósito de esta fase es asegurarse que esté en marcha la sostenibilidad de

los procesos mejorados y se realice parte del negocio como es usual. Una

investigación considerable hizo que cualquier proyecto pueda ser mantenido y

mejorado sobre el tiempo, realmente no discrimina ni desprecia los procesos. La

organización debe comprender que los procesos tienen un ciclo de vida limitado y

puede continuar el mejoramiento después que el objetivo de mejoramiento del

proyecto se haya realizado.

La sostenibilidad es determinada por la organización que habilita la creación y

entrega valor para todos los stakeholders en una continuidad de bases. Esto es

acerca del entender que valores de clientes ahora y en el futuro podrían influenciar

la estrategia organizacional, diseño y llamada en acción. Esto no sucede en la

organización, la organización simplemente ejecutara los procesos en una vista

sub-optima.

En otras palabras el rendimiento sostenible es acerca de la continuidad de la

administración de los objetivos de los procesos para lograr los objetivos

específicos.



empresas

204

7.6.3 Pasos:



7.6.3.1 Paso 1: Evaluar resultados del proyecto

Durante este paso, el caso de negocio inicial debería ser comparado con los

resultados actuales del proyecto. Las bases originales son revisadas para

determinar lo siguiente:

Que tan rápido se han ejecutado los procesos.

Cuantos errores, reprocesos y atrasos han sido reducidos.

FASE DE RENDIMIENTO SOSTENIBLE

7.6.1 Entradas de esta fase:

Solución Implementada

PASOS

Grafica 52: Pasos de la fase Rendimiento Sostenible (Tomada y adaptada de Business Process Management - Practical Guidelines Successful Implementations)


Mecanismos para gestionar los procesos de negocio e identificar y darse cuenta de las oportunidades para mejorar el proceso.

Gestionar y mejorar los procesos.



empresas

205

Que tan eficiente es el rendimiento de los procesos.

Que tanto se ha mejorado la satisfacción del cliente.

Que tanto se ha mejorado la satisfacción de los empleados.

Un análisis completo costo-beneficio para este proyecto.

Los resultados de esta evaluación tienen dos (2) propósitos:

1. Hacer los cambios necesarios en el entorno actual para corregir cualquier

defecto.

2. Incluir sesiones de aprendizaje para el proyecto con aspectos relevantes para

la fase de cimientos, en otras palabras, ver el mejoramiento del proceso como

un proceso para mejorar la ejecución de un proyecto BPM.

7.6.3.2 Paso 2: Introducir ciclos de retroalimentación

Se ha aclarado que BPM se basa en gran parte en la administración de los

procesos de negocio y, como un nivel básico, BPM tiene dos elementos: los

procesos y la administración de los procesos. Para la administración de la

organización es viable el manejo de los procesos de negocio relevantes, los

siguientes deben estar en su lugar:

Una o más medidas de rendimiento tienen que ser especificadas. Estas

medidas incluyen criterios de efectividad sobre los procesos que serán

evaluados, y debe incluir medidas de cantidad y calidad. El BSC (balance

score card) ayudaría en este proceso.

La gestión debe tener un modelo completo de los procesos que será habilitado

para entender los efectos de las actividades de gestión. Esto deberá ser

documentado parcialmente y parcialmente implícito (ejemplo: sesiones de

aprendizaje desde la previa del proyecto o las medidas). Siempre se debe ser

cuidadoso que las medidas de rendimiento seleccionadas generen el

conocimiento que la gestión desea para promover o crear.

La administración debe tener suficiente información acerca del estado de los

procesos- esto no es solo relacionado con las salidas de los procesos, también

incluye las características de los procesos como errores, problemas mayores,

trabajos y reprocesos.

La administración debe tener suficientes métricas para acordar con la relación

a la incertidumbre y los cambios.

La administración debe tener suficiente información con respecto a la

capacidad de procesamiento para absorber la información generada y sea

capaz de verificar esta información.



empresas

206

Si los resultados parecen difíciles o imposibles de realizar la administración

debe aplazar hasta los niveles más altos de la administración y discutir cómo

proceder en esta situación.

La organización debe también entender que los varios niveles de gestión de la

organización serán enfocados en la administración de los procesos de

diferentes maneras:

Como un nivel estratégico, este es un alto nivel de cambio y de incertidumbre,

pero los gerentes también deben tener más variables a disposición – el

mejoramiento de procesos, la reingeniería de procesos, colaboración,

migración y otros modelos de negocio o incluso outsorcing. Como un nivel

operacional, este está con menos incertidumbre y menos cambios y menos

variables de gestión- por ejemplo, más o menos recursos y habilidad para

escalar.

Gerentes quienes son responsables de la estrategia organizacional tendrán un

enfoque más amplio y subjetivo para mayor fluctuaciones en la vista de los

procesos operacionales.

Los objetivos del nivel más bajo de gestión son enviados por el alto nivel de

gerencia.

Una vez las medidas son puestas en su lugar, es muy importante crear ciclos de

retroalimentación para habilitar el mejoramiento continuo de los procesos. Deming

presenta como mecanismo en su enfoque planear- hacer-verificar-actuar (plan-

do-check-actWalton, 1986), que se mostrará a continuación.

Grafica 53: Ciclo Deming [5]



empresas

207

Administrar no es solo obtener información desde el procesamiento, también es

antes del procesamiento (feed forward / pre alimentación) y después de que el

procesamiento se haya completado (feed back/ retroalimentación).

En la pre alimentación, antes de que inicien sus ciclos de ejecución del proceso,

las influencias relevantes y los factores deben ser habilitadas para permitir la

administración que anticipará el impacto de los procesos y habilita la acción

apropiada para ser tomada (por ejemplo, si el volumen es más alto que lo

anticipado, la gestión debería llevar „on-line‟ más personas para la ejecución de los

proceso). Es importante para entender y anticipar el impacto que la pre-

alimentación puede tener en la capacidad de la organización para alcanzar estos

objetivos, por ejemplo, la introducción de un nuevo producto podría conducir a

más preguntas en un call center, con esto impactaría la capacidad de los call

center para conocer los objetivos específicos para responder a tiempo.

Grafica 54: Ciclo de pre-alimentación [16]

P O SSECORENTRADA SALIDA

ADMINISTRACIÓN

Información decisiones

CICLO DE PRE

ALIMENTACIÓN

En la retroalimentación, los resultados finales de las medidas de los procesos

serán comparadas con los metas u objetivos de los procesos (por ejemplo, un

termostato ajusta el calor o el frio dependiendo de la diferencia entre la

temperatura actual y la temperatura deseada). Esto es importante para entender

como los procesos necesitan ser ajustados para asegurar que en la próxima

ejecución se realicen de manera correcta, los procesos más grandes son

orientados hacia la reunión de objetivos y metas de procesamiento. Esto podría

requerir el ajuste de los procesos, o podría requerir un ajuste de los recursos



empresas

208

disponibles para los procesos, por ejemplo, esto podría ser un requerimiento para

habilitar más personas que realicen transacciones y enruten a más personas para

aprender habilidades.

Grafica 55: Ciclo de Retro-alimentación [16]

P O SSECORENTRADA SALIDA

ADMINISTRACIÓN

Información decisiones

CICLO DE

RETROALIMENTACIÓN

La ventaja de un ciclo de pre alimentación es que se anticipe a nuevas

situaciones. Una desventaja es que se dificulta la obtención de la información

necesaria y luego determinar el impacto sobre el proceso.

Una ventaja de un ciclo de retroalimentación es que se puede medir exactamente

el grado para saber cuál de los procesos reúne los objetivos o metas. La ventaja

es que solo provee información después de que el proceso sea haya finalizado y

puede ser muy tarde para que el proceso reúna las metas u objetivos.

Con claridad lo mejor es combinar los dos ciclos de información habilitados con

anticipación, monitorizando, manejando y corrigiendo. Es crucial que la

información de la realimentación permita gestionar y considerar no solo los

problemas resultantes del proceso, también las medidas que han tenido para

monitorizar los ciclos. Esto proveerá mejores señales para de como los procesos

son inicialmente impactados por los cambios en las circunstancias y/o las medidas

de gestión relacionadas.

La retroalimentación no debe ser restringida a un paso particular de un proceso,

debe ser asociada con la perspectiva completa de un proceso de negocio, la

mayoría de errores, retrasos y frustraciones ocurren en un proceso completo,

especialmente cuando las personas causan los problemas y las personas

afectadas por esto no saben las otras actividades o no se dan cuenta de otras

actividades. Esto puede ser dirigido como lo siguiente:



empresas

209

Pre alimentación: Si al comienzo de los procesos debe ser cambiada

una práctica normal (por ejemplo, un incremento de aplicaciones que

han sido recibidas), los pasos del futuro proceso pueden ser informadas

de este hecho y se pueden tomar medidas anticipadas.

Monitorizar: Los propietarios de los procesos completos deben

monitorizar el flujo de los procesos y asegurarse que este flujo esta sin

problemas como lo planeado; cualquier problema necesita ser dirigido.

Retroalimentación: Si los procesos completos no reúnen los objetivos o

metas, es importante que las personas sean informadas.

A menudo el relato de la retroalimentación para el mejoramiento de procesos

proviene de un paso previo en el proceso, donde solo se conduce a la sub-

optimización a menos que sea dirigido al proceso completo.

7.6.3.3 Paso 3: Integrar la sostenibilidad

La sostenibilidad de la mejora de procesos solo puede ser lograda si las personas

usan los procesos mejorados de la manera correcta. Después de que los nuevos

procesos hayan sido implementados, las personas pueden volver atrás y trabajar

como lo hacían anteriormente a menos que se haya realizado una comunicación

suficiente y una convicción con respecto a los beneficios del nuevo proceso

mejorado. Otra razón puede ser la falta de entrenamiento profundo en el soporte

de la implementación, causando que la gente olvide los detalles del nuevo

proceso. Esto puede llevar a que se devuelvan a la manera antigua o que los

procesos o las personas puedan crear sus propios nuevos procesos sobre la

marcha.

Un método para soportar y guiar las personas durante la ejecución de las etapas

iníciales de los nuevos procesos es publicando en la intranet toda la información

de soporte necesaria (por ejemplo que disparadores existen, que actividades

tienen un rendimiento, etc.), esto podría complementarse con información

adicional como: formas que pueden ser usadas, documentos que pueden ser

tomados, que documentos y sistemas son incluidos, etc. Usando los modelos de

proceso como principal para encontrar toda esta información se tienen dos

beneficios principales: el primero, la gente en realidad consultaría los procesos, y

segundo, todos siempre tendrían acceso a la mejor versión de la documentación.

La sostenibilidad de BPM solo puede ser lograda cuando los procesos se

mantienen al día. Este punto no puede ser exagerado. Cuando los workshop de

modelamiento de procesos son iniciados, la gente a menudo dice, „¿por qué



empresas

210

nosotros modelamos los procesos de nuevo? Nosotros los hicimos el año pasado‟

cuando se responde a esa pregunta para los resultados del ejercicio previo, es

increíble pero cierto que muchas circunstancias del modelo del proceso no fueron

encontradas, dejando en realidad que solo sea usado por los negocios, la mejor

manera de mantener los procesos y relacionar la información actualizada es

publicándolo en la intranet y haciendo más fácil para las personas proveer una

retroalimentación de las etapas de los procesos y proveer ideas para el

mejoramiento de los procesos.

Cuando es puesto en marcha el proceso en la intranet, es crucial para tener un

enfoque de un usuario centrado: ¿Qué información desean ver los usuarios, y

como pueden lograrlo mejor? Los modelos de procesos y toda la información

relacionada deben obtenerse de varios lugares y estar en un repositorio, y de ser

posible de diferentes tipos de usuarios para obtener diferentes vistas, tipos e

información detallada. Por ejemplo, los analistas del procesos deberían estar

interesados en que tareas deben ser realizadas; el personal de TI debe estar más

interesado en como los sistemas, procesos y documentos son realizados; y el

departamento financiero debería estar interesado en el procesamiento financiero y

en la segregación de deberes. Considere que tanta información puede ser

disponible para varios tipos de usuarios, por ejemplo, información de riesgos y

problemas relacionados a los procesos podría no debe ser apropiados para todos

los empleados.

¿Los procesos deben ser publicados en la web a beneficio de los clientes,

proveedores y socios?, esto puede proveer puntos de vista en los pasos que la

organización debe tomar para permitir un seguimiento al progreso de los procesos

dentro de la organización. Se debe tener cuidado también en la información que

esto debe ser disponible para perspectivas privadas y confidenciales.

Una buena manera de integrar la sostenibilidad de BPM al final del proyecto es

estableciendo un centro de business process excellence (excelencia de procesos

de negocio) que sirve a las unidades de negocio.

Analizando los procesos, identificando cuellos de botella, puntos de mejora y

actuando es como se debe integrar a la organización, como una manera de vida,

las personas quienes ejecutan los procesos a menudo conocen que problemas

existen pero son incapaces o no quieren comunicar estas ocurrencias. La

identificación y publicación de los propietarios del proceso identificaría también el

„alguien que se preocupa‟.



empresas

211

7.6.3.4 Paso 4: Monitorear la sostenibilidad

No solo los procesos deben ser monitoreados, la ejecución de programas BPM

deben ser también medidas y monitoreadas. En otras palabras „practique lo que

predica‟. La mejor manera de lograrlo es estableciendo por adelantado metas que

deben ser logradas. Las medidas potenciales deberían incluir lo siguiente:

Satisfacción de clientes, socios y empleados con los programas y servicios

internos de BPM.

El número de veces que el modelo de procesos es consultado.

El número de quejas de las personas que los modelos de procesos no son

actualizados o correctos.

El número de descripciones del modelo de procesos que no han tenido la

rotación del personal (interno y externo).

El porcentaje de proyectos que han sido realizados, sus metas y fueron

realizados en tiempos y en presupuesto.

La disponibilidad de los modelos de procesos.

El giro de tiempo para el modelamiento de procesos.

Las personas que hagan las propuestas de BPM en la organización deben tener

claro que el énfasis principal sea conocido en la correcta ejecución de los

procesos. Nuevas iniciativas deben ser iniciadas solo donde el caso de negocio es

fuerte y los negocios y /o la gestión está ansiosa para que esto ocurra. Nuevas

iniciativas no deberían iniciarse solo porque los recursos de BPM son viables. Los

cambios de negocio nunca deben ocurrir con el mejoramiento del negocio.

7.6.3.5 Paso 5: Mantener los modelos de procesos

Los procesos no son estáticos, son dinámicos, ellos se ajustan a nuevas

circunstancias internas y externas. Las descripciones de los procesos para ello

necesitan ser modificadas como reflejo de estos cambios.

Cualquier cambio en el proceso debe ser tratado como un requerimiento y seguir

los pasos:

1. Registrar el cambio (por ejemplo, quien requiere el cambio).

2. Determinar el tipo de cambio y los conductores para el cambio.

3. Priorizar los cambios.

4. Determinar una valoración del impacto.

5. Obtener aprobación para el cambio.

6. Realizar un plan de cambio.

7. Implementar el cambio. Revisar la implementación del cambio.



empresas

212

8. RECOMENDACIONES Y TRABAJOS FUTUROS

Para futuros proyectos que se realicen, y tengan como base esta tesis se

recomienda:

Realizar una investigación a fondo de las entidades colombianas que

tengan en producción una implementación BPM, o hayan intentado realizar

una y no haya sido exitoso, para documentar aciertos y fracasos que

tendrán en cuenta para implementaciones futuras.

Realizar una investigación a fondo de cómo mantener y renovar aquellos

procesos que se han implementado en un proyecto BPM pero están sujetos

a continuos cambios y que afectan drásticamente el funcionamiento de la

implementación desarrollada, el objetivo que planteamos es tener una

metodología o un framework que permita realizar seguimiento a estos

procesos y tener una guía para una toma de decisiones acertada.

Desarrollar una estrategia y un plan de pruebas para este tipo de

tecnologías no convencionales, pues bien se ha dicho que este tipo de

proyecto rompe los limites convencionales y afecta mucho más que solo

tecnologías de información, pero actualmente no se cuenta con un

protocolo de pruebas indicado que permita establecer con cifras acertadas

el éxito o el fracaso de un proyecto en su desarrollo y que permita

determinar si se aprovechó al máximo este tipo de implementación.



empresas

213

9. CONCLUSIONES

El proceso evolutivo hasta llegar a BPM ha arrojado una muy buena

documentación sobre aciertos y fracasos que se recopilan finalmente en

BPM. Esto permite que BPM se convierta en un conjunto de herramientas,

métodos y tecnologías utilizadas para diseñar, representar y controlar los

procesos de negocio operacionales [14].

En el desarrollo del framework se puede observar que no todas las

empresas son iguales, y que de sus características propias depende el

tiempo de implementación de un proyecto BPM, el tiempo de

implementación máximo estimado es de 7 meses.

No hay abundante documentación relacionada con metodologías que

apoyen el análisis y la implementación de BPM.

Aunque han pasado 12 años desde las primeras apariciones de BPM, éste

es un tema aún muy inexplorado por las compañías, bien sea por el temor a

fracasar o por la falta de información.

Según el sondeo realizado por BPTrends: State of Business Process

Management – 2008(EEUU); el artículo escrito por Jeremy Payne, Director

de Marketing Europa: BPM y la metodología de la ―bola de cristal‖; Y el

diagnóstico realizado en algunas empresas nacionales y multinacionales de

Cali y Bogotá(CIAT, Coomeva Sector Salud, Ecopetrol, Fundacion WWB

Colombia, Geniar, Lucasians, Cadbury Adams Colombia, Assenda Carvajal,

Confandi, Enterprise Data System - Grupo Bimbo, UPS Supply Chain

Solutions (Colombia), KeyVolution3, Synapsis, Acueducto de Bogotá y

Quebecor World), se concluye que: empresas de todos los tamaños, en

todas las zonas geográficas, están explorando opciones e inviertiendo

enBPM. Se mueven más rápidamente en la adopción del modelado de

procesos y rediseño, y más lentamente cuando se enfrentan con las

nuevas tecnologías como BPMS para automatizar, simular, ejecutar y

monitorear sus procesos. Un grupo aún mayor de empresas, en todo el

mundo, asisten a conferencias en busca de obtención de formación con el

fin de comprender mejor sus opciones en un mercado versátil pues las

empresas no conocen alguna metodología para la implementación de BPM,

solo siguen los métodos que indican cada herramienta en particular.



empresas

214

10. GLOSARIO

Actividad: Conjunto de operaciones o tareas propias de una persona o entidad.

Muchos procesos pueden ser subdivididos en pequeñas unidades o subprocesos,

una actividad es la unidad más pequeña de análisis, una actividad involucra uno o

varios pasos y puede ser realizada por uno o muchos empleados, por un sistema

o por una acción en conjunto.

Existen actividades atómicas que son las que no pueden ser subdivididas, constan

de un solo paso o una acción.

Automatización de procesos de negocio: Se refiere al uso de sistemas de

cómputo y software para automatizar un proceso. Los procesos pueden ser

automáticos totalmente, semiautomáticos cuando algún humano interviene para

alguna toma de decisiones o para manejar casos de excepción no controlados por

el sistema.

BPMN - Notación de definición de procesos de negocio: La Notación del

Modelado de Procesos de Negocio (BPMN) es una notación gráfica normalizada

para dibujar los procesos de negocio en un flujo de trabajo. Define diagramas de

procesos de negocios basados en la técnica de diagramas de flujo, adaptados

para graficar las operaciones de los procesos de la organización. Se compone de

un conjunto de elementos gráficos que facilitan un diagrama entendible tanto por

audiencias de negocios como técnicas.

BPMS – Sistemas de Administración de Procesos de Negocio: A diferencia de

los sistemas tradicionales basados en gestión de datos, los BPMS sistemas se

especializan en la gestión de procesos de negocio. Un BPMS ejecuta modelos de

procesos de negocio y proporciona herramientas para la simulación,

monitorización y ajuste de los procesos de negocio.

Una definición más completa:

Está constituido por el conjunto de tecnologías que posibilitan desarrollar la

administración de los procesos. Suelen involucrar varios tipos de componentes:

Herramientas para la configuración/diseño de procesos

Motores para la ejecución de flujos de trabajo

Sistemas de Administración de Documentos y Activos Digitales



empresas

215

Sistemas/Tecnologías para la integración de aplicaciones (EAI)

Sistemas de interacción con operadores humanos (correo, web, IM,

formularios)

Sistemas de Monitoreo

Diseño o rediseño de procesos de negocio: El rediseño de procesos de enfoca

en realizar mejoras a los procesos existentes o creando nuevos procesos,

dependiendo el tamaño del proceso este puede definirse una sola vez y estar

sujeto mejoras continuas, a diferencia del BPR (Reingeniería de Procesos de

Negocio).

EAI – Enterprices Application Integration: Enterprise Application Integration

(EAI) se define como la utilización de software y sistemas informáticos de

principios de la arquitectura para integrar un conjunto de aplicaciones de empresa.

Comunican las diferentes aplicaciones mediante conectores, tanto dentro de la

organización como Inter organizativas.

Orquestan los diferentes procesos de negocio: definen y controlan el orden y

secuencia de los elementos del proceso.

EAI es la integración de nuevas aplicaciones con las ya existentes, incluyendo las

aplicaciones heredadas o los paquetes de software, de forma que todas juntas

proporcionen las funcionalidades necesarias para soportar los procesos de

negocio de la empresa. Esta integración permite a la organización mantener el

ritmo de los cambios del mercado y reaccionar a tiempo frente a ellos.

Epistemología: La epistemología es la doctrina de los fundamentos y métodos del

conocimiento científico. También conocida como gnoseología, su objeto de estudio

es la producción y validación del conocimiento científico. De esta forma, la

epistemología analiza los criterios por los cuales se justifica el conocimiento,

además de considerar las circunstancias históricas, psicológicas y sociológicas

que llevan a su obtención.

Herramienta de modelamiento de procesos de negocio: Es Una herramienta

de software que permite a los administradores o analistas crear diagramas de

procesos de negocios. Herramientas simples que solo soportan la arte de

diagramación. Las herramientas de modelamiento de procesos de negocio

almacenan cada elemento del modelo en una base de dato, entonces cada

elemento puede ser rehusado u actualizado, muchas herramientas profesionales

soportan simulación y generación de código



empresas

216

Proceso de Negocio: Un proceso de negocio es un conjunto de tareas

relacionadas lógicamente llevadas a cabo para lograr un resultado de negocio

definido. Cada proceso de negocio tiene sus entradas, funciones y salidas. Las

entradas son requisitos que deben tenerse antes de que una función pueda ser

aplicada. Cuando una función es aplicada a las entradas de un método, tendremos

ciertas salidas resultantes.

Un proceso de negocio es usualmente el resultado de una Reingeniería de

Procesos. El modelado de procesos es usado para capturar, documentar y

rediseñar procesos de negocio.

Hay tres tipos de procesos de negocio:

Procesos estratégicos - Estos procesos dan orientación al negocio. Por

ejemplo, "Planificar estrategia", "Establecer objetivos y metas".

Procesos centrales – Estos procesos dan el valor al cliente, son la parte

principal del negocio. Por ejemplo, ―Repartir mercancías‖

Procesos de soporte – Estos procesos dan soporte a los procesos centrales.

Por ejemplo, ―contabilidad‖, ―Servicio técnico.

Los procesos de negocio consisten en subprocesos, decisiones y actividades.

Un subproceso es parte un proceso de mayor nivel que tiene su propia meta,

propietario, entradas y salidas.

Las actividades son partes de los procesos de negocio que no incluyen ninguna

toma de decisión ni vale la pena descomponer (aunque ello sea posible). Por

ejemplo, ―Responde al teléfono, ―Haz una factura.



empresas

217

11. BIBLIOGRAFÍA

[1] “Para lograr los objetivos. Metodología ,” 1967.

[2] T. Gonz, “BPM COMO PALANCA DE PRODUCTIVIDAD BPM como palanca de productividad y competitividad,” pp. 1-17, 2010.

[3] Q. Excellence, “Total Quality Management ( TQM ),” pp. 1-5.

[4] C. Total, T. Q. Management, and L. Tqm, “Capítulo 7 OTRAS HERRAMIENTAS DE GESTIÓN : TQM , COMPARACIÓN.”

[5] O. D. E. La and A. E. N. Los, “MEJORA C ONTINUA DE LA,” no. 6, pp. 89-94, 2003.

[6] E. Deming and J. Juran, “BPM & Quality Management ( TQM ): Will the Twain Meet ?,” Management, pp. 1-4, 1930.

[7] “Análisis del valor 1,” pp. 1-20, 1985

[8] C. D. Vera, “Aplicación de la metodología seis sigma en la mejora de resultados de los proyectos de construcción.”

[9] S. Sigma, A. Signal, and D. Chemical, “Que es Seis Sigma,” 1994.

[10] P. A. Quishpe and A. C. Giron, “Implementación de BPM,” pp. 2-247, 2007

[11] C. Jeston, “BPM and Six Sigma.” ,2008

[12] “PPT-Documentos_Presentaciones_Simplificación de procesos.”

[13] S. Sigma, “Introducción a seis sigma,” pp. 48-53, 1997.

[14] K. Garimella, M. Lees, and B. Williams, para Introducción a BPM para Dummies.

[15] S. Zigiaris, “BUSINESS PROCESS RE-ENGINEERING BPR,” Methodology, pp. 0-24,1997

[16] John Jeston & Johan Nelis, “Business Process Management,” 2008.



empresas

218

[17] F. W. Breyfogle, “Leveraging Business Process Management and Six Sigma in Process Improvement Initiatives,” Business, pp. 1-10, 2004.

[18] González Montoya Paola Andrea, “Caracterización de un protocolo de pruebas”, Proyecto de grado, Santiago de Cali, 2012.

[19] Salazar Oscar Javier, “Caracterización de métodos para la implementación de procesos en un sistema de administración de procesos de negocio (business process management system -BPMS)”, Proyecto de grado, Santiago de Cali, 2008.

[20] Freund-Ruecker-Hitpass, Jakob Freund, Bernd Rucker, Bernhard Hitpass, “BPMN 2.0 Manual de Referencia y Guía Práctica”, 2011

[21] G. H. V. E, L. F. G. A, and R. L. Isaza, “proceso de implementación de una plataforma BPM (business process management ) implementation process of a platform BPM ( business process management ).”, 2010



empresas

219

WEBGRAFIA

[22] (2011) Definición abc [Online]. Disponible: http://www.definicionabc.com/general/proceso.php

[23] (2011) Arp calidad [Online] Disponible en: http://arpcalidad.com/definicin-de-

proceso/

[24] (2011) sitio web Definicion [Online] Disponible en: http://definicion.de/metodologia/

[25] (2011) sitio web Monografías [Online] Disponible en: http://www.monografias.com/trabajos6/elme/elme.shtml#elmetodo

[26] (2011) sitio Web Wikipedia [Online] Disponible en: http://es.wikipedia.org/wiki/Mejora_continua

[27] (2011) sitio Web Wikipedia [Online] Disponible en: http://es.wikipedia.org/wiki/C%C3%ADrculo_de_Deming

[28] (2011) sitio web Ciclo PDCA [Online] Disponible en: http://www.pdca.es/pruebas/pdca.html

[29] (2011) sitio web SHT ser humano y trabajo [Online] Disponible en: http://www.sht.com.ar/archivo/Management/analisis_valor.htm

[30] (2011) sitio web Monografías [Online] Disponible en: http://www.monografias.com/trabajos28/reingenieria/reingenieria.shtml

[31] (2011) sitio Web Wikipedia [Online] Disponible en: http://es.wikipedia.org/wiki/Reingenier%C3%ADa_de_procesos

[32] (2011) sitio web alagse [Online] Disponible en: http://www.alagse.com/pm/p14.php

[33] (2011) sitio web redbooks [Online] Disponible en: ftp://www.redbooks.ibm.com/redbooks/REDP4543/2009_08_31_BPM_Prescriptive_Guide.pdf

http://www.definicionabc.com/general/proceso.php

http://arpcalidad.com/definicin-de-proceso/

http://arpcalidad.com/definicin-de-proceso/

http://definicion.de/metodologia/

http://www.monografias.com/trabajos6/elme/elme.shtml#elmetodo

http://es.wikipedia.org/wiki/Mejora_continua

http://es.wikipedia.org/wiki/C%C3%ADrculo_de_Deming

http://www.pdca.es/pruebas/pdca.html

http://www.sht.com.ar/archivo/Management/analisis_valor.htm

http://www.monografias.com/trabajos28/reingenieria/reingenieria.shtml

http://es.wikipedia.org/wiki/Reingenier%C3%ADa_de_procesos

http://www.alagse.com/pm/p14.php

ftp://www.redbooks.ibm.com/redbooks/REDP4543/2009_08_31_BPM_Prescriptive_Guide.pdf

ftp://www.redbooks.ibm.com/redbooks/REDP4543/2009_08_31_BPM_Prescriptive_Guide.pdf



empresas

220

A N E X O S



empresas

221

ANEXO 1. BIBLIOGRAFÍA DE LAS TENDENCIAS EN MEJORAMIENTO DE

PROCESOS

En este anexo es importante resaltar que la tesis presentada anteriormente no

tiene como principal razón de ser la investigación de Tendencias en mejoramiento

de procesos, es por esto que facilitando información al lector se decide organizar

una serie de referencias para aquellos lectores que le interese profundizar sobre el

tema.

Gestión de la Calidad total- una herramienta para el diseño del entorno

Total Quality Management - A tool for design for environment

http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5227948

Resumen

Gestión total de la calidad TQM ( Total Quality Management) está basada en un

numero de ideas y conceptos, esto significa pensar sobre la calidad en términos

de todas las funciones de la empresa y una lista completa de procesos que

integren funciones relacionadas entre sí en todos los niveles, el problema aparece

cuando se definen los términos de la calidad total, en el paper, calidad no es solo

conocer los requerimientos formales e informales del cliente, como bajo costo

como primera medida y siempre, también incluye los requerimientos del desarrollo.

Estos requerimientos permiten la ampliación de los conceptos tradicionales de

TQM y la creación de un nuevo modelo y framework para la conciencia ambiental

de la gestión total de la calidad (ECTQM) donde TQM está dentro de la calidad

con un entorno de calidad

Gestión Total de la calidad (Total Quality Management )

http://www.businessballs.com/dtiresources/total_quality_management_TQM.pdf

Introducción

TQM es una manera de gestionar para el futuro, es mucho más amplio en su

aplicación que solo asegurar la calidad en un servicio o en un producto – esto es

una manera de gestionar las personas y los procesos de negocio para asegurar

una completa satisfacción del cliente en cualquier escenario interno o externo.

TQM combina lideres efectivos con resultados, en una organización que hace las

cosas bien y las hace a la primera vez.

http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5227948

http://www.businessballs.com/dtiresources/total_quality_management_TQM.pdf



empresas

222

ANEXO 2. COMUNIDADES MÁS DESTACADAS

NOMBRE DE LA ASOCIACION ENLACE

CLUB-BPM http://www.club-bpm.com

BPM-FORUM (PAISES BAJOS) http://www.bpm-forum.org/pageflow/default.asp?pageid=37&nt=2

BPTRENDS http://www.bptrends.com/index.cfm

ASSOCIATION OF BUSINESS PROCESS MANAGEMENT PROFESSIONALS (Asociación de profesionales en BPM)

http://www.abpmp.org

WORKFLOW MANAGEMENT COALITION (WFMC)


OBJECT MANAGEMENT GROUP (OMG)

http://www.omg.org

BPM CHILE http://www.bpmchile.org/

BPM http://www.bpm.com/

BPM –SPAIN http://www.bpm-spain.com/tipologia.php?id=15

BPM INSTITUTE


BPMI http://www.bpmi.org

ARIS COMMUNITY http://www.ariscommunity.com/

CORDYS COMMUNITY http://community.cordys.com/

http://www.club-bpm.com/




http://www.abpmp.org/


http://www.omg.org/


http://www.bpm.com/



http://www.bpmi.org/

http://www.ariscommunity.com/

http://community.cordys.com/



empresas

223

ANEXO 3. TABLA DE ROLES INVOLUCRADOS [16]

Fase Paso Rol Involucrado

Cimientos

Comunicaciones Gerente del proyecto

Gestión de Stakeholders e implicados en el

proyecto

Gerente o Senior del proyecto

Miembros del proyecto Analista de procesos

Talleres Ejecutivos Gerente del proyecto Analista de procesos

Comité Ejecutivo

Aceptar y entregar Plan de Negocios

Gerente del proyecto y Propietario del negocio

Desarrollar plan de implementación

Gerente del proyecto Sponsor del proyecto

Propietario del negocio

Desarrollar/Terminar caso de Negocio


Entender

Comunicaciones Gerente del proyecto

Revalidar el alcance Gerente del proyecto Sponsor del proyecto

Principales Stakeholders

Workshop de Entender Analista de procesos Expertos del negocio

Completar análisis de métricas

Analista de procesos Gerente del proyecto

Completar matriz de capacidad de personas

Analista de procesos

Reporte Final de la fase

Responsable: Gerente del proyecto.

Quien lo ejecuta: Analista

de procesos

Innovar

Comunicaciones Miembros del equipo del

proyecto

Workshop Inicial ejecutivo Gerente del proyecto Sponsor del proyecto

Workshop de extracción de ideas

Analista de procesos Facilitador

Taller de análisis Analista de procesos



empresas

224

Ingeniero de procesos Analista de Negocios

Simulación Analista de procesos

Personal de TI Gerente del proyecto

Actualizar matriz de capacidad de personas

Analista de procesos RH

Gerente del proyecto Administración

Workshop de soluciones propuestas

Analista de procesos Gerente del proyecto

Análisis de diferencias de procesos


Preparación y reunión de aprobación


Desarrollar

Comunicaciones Equipo del proyecto

Determinar Componentes BPM

Analista de procesos TI

Actualizar especificaciones técnicas

y funcionales

Analista de procesos TI

Desarrollar Software

Analistas de Negocios Analistas de pruebas

Desarrolladores …

Pruebas

Analista de procesos Personal TI

Analistas y equipo de pruebas

Implementar

Comunicaciones Miembros del equipo del

proyecto

Actualizar el plan de implementación

Gerente del proyecto Propietario del negocio

Testing Analista de pruebas Analista de procesos Usuarios de Negocio

Grupo de Tutores Equipo del proyecto

Súper Usuarios

Cambios en la puesta en marcha; Monitoreo y

ajuste Gerente del proyecto

Rendimiento Sostenible Evaluar resultados del Gerente del proyecto



empresas

225

proyecto Propietario de los beneficios

Introducir ciclos de retroalimentación

Sponsor del proyecto Gerente del proyecto Gerentes del negocio

Integrar la sostenibilidad Gerente del proyecto

Propietario de los beneficios

Monitorizar la sostenibilidad


Mantenimiento de los modelos del proceso





empresas

226

ANEXO 4. FORMULARIO 1 – Pre Fase [16]

Objetivos Generales

Queremos crecer en ingresos un 200 por ciento en los próximos tres años

Queremos aumentar las ganancias un 150 por ciento

Principios Generales

Nuestros valores corporativos son los siguientes:

Mejor relación calidad-precio

Honestidad: prometemos lo que hacemos y hacemos lo que prometemos

Premios: Los resultados y la innovación se premian a lo largo de la

organización

Seguimos una estrategia de excelencia operativa con bajos precios agresivos y

logramos esto a través de:

Las economías de escala (sólo ofrecemos servicios en los cuales podemos

obtener volumen crítico)

Organización clara y directa, los procesos y sistemas de aplicación.

Nosotros comunicamos abiertamente nuestros objetivos y opciones

estratégicas.

Queremos ser una organización destacada a nivel nacional, nos centramos en

toda la nación, no tenemos ninguna intención (aún) de salir al exterior.

Elegimos las mejores prácticas, no inventaremos nuestros propios métodos y

herramientas, si con las mejores prácticas en la empresa no podemos cumplir

con una actividad en particular, entonces externalizamos esa actividad

Pautas Relevantes de productos

Tenemos un número limitado de productos y componentes

El cliente puede obtener la solución más adecuada en función de los

componentes de nuestro producto

El descuento depende exclusivamente de la cantidad total de fianza y se aplica

para todo el mundo

Nosotros no inventamos los productos por sí mismos, adoptamos ofertas

prometedoras.



empresas

227

Pautas relevantes de la organización

Tenemos una organización nacional

Animamos a los empleados a capacitarse y servimos de guía para esto.

Retamos a la gente a usar su potencial y favorecer a los candidatos internos

Tenemos una estructura organizativa flexible y plana

Abogamos por una organización de aprendizaje y definir los objetivos en todos

los niveles relevantes.

Todos los empleados tienen una bonificación en función de su desempeño

individual, y trabajo en equipo con su unidad de negocio.

Pautas del proceso

Todos los procesos tienen un propietario de negocio

Sólo existe un proceso por defecto para cada función de negocio, las

excepciones necesitan aprobación de la Junta.

La arquitectura del proceso tiene que incluir la elección de modelos de

referencia.

No habrá procesos personalizados para clientes individuales, si las peticiones

llegan hasta nosotros, se evaluará en las condiciones establecidas.

Queremos entregas reducidas

Automatizamos las actividades cuando sea posible, pero garantizando

flexibilidad

Todos los procesos tienen indicadores de desempeño, que estarán abiertos,

para que todos los vean.

Pautas de información relevante

Las siguientes aplicaciones son estándar:

o A / B / C

Las siguientes aplicaciones están disponibles después de la aprobación de la

administración.

o Z / Y / X

Todas las demás aplicaciones necesitan la aprobación de la Junta

Subcontratamos todo el desarrollo de software

Todos los datos se introducen una sola vez



empresas

228

Pautas Importantes de Tecnología

Usamos X sistema operativo

Utilizamos una configuración de servidor de cliente ligero

Además de lo anterior, es muy importante anexar a este formulario (si existen) los

siguientes modelos del proceso:

Vista de procesos de la organización

Lista completa de los procesos de la organización.



empresas

229

ANEXO 5. TEMPLATE DEL CASO DE NEGOCIOS[16]

Propósito de un caso de Negocio

El caso de negocio es un instrumento importante en la gestión de un proyecto

BPM, y tiene tres funciones principales:

1. En el inicio del proyecto, proporcionará la información para tomar una decisión

sobre si se debe aprobar y financiar el proyecto - en otras palabras, si los

beneficios previstos justifican la inversión solicitada, teniendo en cuenta los

riesgos y alternativas. Los beneficios que se obtendrán como resultado de este

proyecto deben ser claramente especificados.

2. Durante el proyecto, servirá de guía para asegurar que el proyecto todavía está

en el buen camino. Esto es crucial ya que el negocio se desarrollará durante la

vida útil del proyecto, y el patrocinador y el director del proyecto deben revisar

continuamente que el proyecto aún contribuya a la estrategia organizacional y

verificar el rendimiento de los beneficios deseados en relación con los costos

proyectados. En otras palabras, el director y el patrocinador del proyecto deben

continuamente 'gestionar el caso de negocio"

3. Después del proyecto, permitirá al equipo de negocios y proyecto evaluar si el

proyecto ha dado los resultados esperados (beneficios) y contribuyó a los

objetivos señalados, dentro del presupuesto aprobado y el calendario. Esta

evaluación proporciona lecciones cruciales que deben ser tenidos en cuenta en

próximos proyectos de BPM.

TABLA DE CONTENIDO

1. Resumen Ejecutivo - El Resumen ejecutivo tiene por objeto proporcionar

al lector una breve descripción del caso de negocio. El próximo debe ser

fuerte y al punto.

1.1 Descripción del proyecto y propietario del proyecto

1.2 Los requerimientos del negocio

1.3 Contribución estratégica

1.4 Resumen financiero (incluidos costos y beneficios)

1.5 Factores críticos de éxito



empresas

230

1.6 Análisis de riesgos

1.7 Recomendaciones a los siguientes pasos

2. Fondo

2.1 Análisis de problemas

3. Objetivos

3.1 Los objetivos de negocio

3.2 Los objetivos del proyecto

3.3 Factores críticos de éxito

4. Alcance del proyecto

4.1 Resultados / Entregables

4.2 Inclusiones y exclusiones

4.3 Dependencias

4.4 Análisis de los stakeholders

4.5 Suposiciones

4.6 Limitaciones

4.7 Documentos relacionados

4.8 Cumplimiento de la arquitectura

5. Enfoque del proyecto

5.1 Opciones consideradas:

5.1.1 Opción 1:

5.1.1.1 Resultados esperados

5.1.1.2 Beneficios

5.1.1.3 Costos

5.1.1.4 Retorno de inversión, etc.

5.1.2 El enfoque preferido



empresas

231

6. Cronograma del proyecto

6.1 Duración del proyecto

6.2 Plan de implementación de alto nivel

7. Recursos

7.1 Stakeholders internos del proyecto - interacción con otras divisiones

7.2 Otros recursos del proyecto

8. Análisis de riesgo Inicial



empresas

232

ANEXO 6. REGISTRO DE PROBLEMAS Y OPORTUNIDADES [16]

Una parte muy importante de la fase de Entender es la captura de ideas,

oportunidades y problemas, y registrarlas en el “Registro de problemas y

oportunidades”. Este registro debería mantenerse a través de la fase de Entender

(y las otras fases), y contener la siguiente información:

Número del problema.

Nombre del proceso.

Descripción del problema

Consecuencia (¿Es amplia o estrecha?)

Prioridad

¿Este problema afecta la estrategia, los negocios, la organización, la

arquitectura o TI?

¿Cuál es la solución?

¿Es un problema a corto o largo plazo?

Responsabilidad (¿De Quién?)

Posibles beneficios:

Descripción

Valor ($)

Como se deriva

Restricciones

Suposiciones

Impacto cualitativo/cuantitativo

¿Costos Asociados?



empresas

233

ANEXO 7. LISTA DE LOS STAKEHOLDERS INVOLUCRADOS

NOMBRE COMPLETO

NUMERO DE TELEFONO

CORREO ELECTRONICO

CARGO DESEMPEÑADO

DEPARTAMENTO AL QUE

PERTENECE

EMPRESA



empresas

234

ANEXO 8. ACTA A STAKEHOLDERS QUE VALIDE SU PARTICIPACIÓN,

COMPROMISO Y EXPECTATIVAS DOCUMENTADAS Y ACORDADAS.

[NOMBRE DE LA ORGANIZACIÓN/COMITÉ]

Actas de la reunión

[Fecha de la reunión]

Asistentes: [Lista de asistentes]

Próxima reunión: [Fecha], [Hora],[Lugar]

I. Participación

Lista de todos los stakeholders que participaran en el proyecto y que fueron

acordados durante la reunión.

II. Compromiso

Resumen de cada uno de los compromisos aceptados por parte de los

stakeholders

III. Expectativas

Resumen de las expectativas de los stakeholders de cada área/departamento.



empresas

235

ANEXO 9. LISTA DE PROCESOS DE NEGOCIO IDENTIFICADOS

NOMBRE DEL PROCESO AREAS IMPLICADAS EN EL PROCESO

OBSERVACIONES



empresas

236

ANEXO 10. LISTA DE PROCESOS PRIORIZADOS

NOMBRE DEL PROCESO AREAS IMPLICADAS PUNTUACION OBSERVACION



empresas

237

ANEXO 11. EQUIPO DEL PROYECTO ESTABLECIDO Y SUS RESPECTIVOS ROLES

AREA

ROL NOMBRE PERSONA CORREO ELECTRONICO

FIRMA

LIDERAZGO


Consultor BPM

EQUIPO DE DECISION DEL

PROYECTO

Patrocinador del proyecto

Responsable del proyecto

Propietario del negocio

CIO o directivo sénior

Representación en aspectos organizativos

COMITÉ DE ARQUITECTURA DE

PROCESOS DE NEGOCIO

Patrocinador del proyecto

Director del proyecto




empresas

238

AREA

ROL NOMBRE PERSONA CORREO ELECTRONICO

FIRMA

EQUIPOS DEL PROCESO

Líder del equipo

Líder de usuarios

Usuarios del equipo

Expertos en el proceso

CENTRO DE EXCELENCIA DE PROCESOS DE

NEGOCIO


Ingeniero de proceso

EQUIPO DE DESARROLLO TI

Líder del equipo

TI Expertos

EQUIPO DE GESTION DE DOCUMENTOS

Gerente de proyecto

Líder del equipo

Equipo de usuarios

Expertos



empresas

239

ANEXO 12. INFORME FINAL DE LA FASE

INFORME FINAL

PROPOSITO DE LA FASE:

PROBLEMAS:

NOMBRE DEL PROCESO PROBLEMA ENCONTRADO OBSERVACIONES

ACTORES:

ACTOR RELACION CON EL PROYECTO

RESULTADOS:

PROCESOS ACTUALES:

METRICAS:



empresas

240

LISTA DE PRIORIDADES DE LA FASE DE INNOVAR

NOMBRE DEL PROCESO QUEDA IGUAL

MEJORAR REDISEÑAR INNOVACION TOTAL

TERCERIZACION

INTERNALIZACION

ELIMINACION



empresas

241

ANEXO 13. ACTA DE INFORMACIÓN Y ACEPTACIÓN DE LOS

STAKEHOLDERS EXTERNOS

[NOMBRE DE LA ORGANIZACIÓN/COMITÉ]

Actas de la reunión

[NOMBRE DEL PROYECTO]

[Fecha de la reunión]

Asistentes: [Lista de asistentes]

Próxima reunión: [Fecha], [Hora],[Lugar]

[RESUMEN DEL DIA]

______________________

Firma Stakeholders



empresas

242

ANEXO 14. FORMATO PARA LA ESPECIFICACIÓN DE UN PLAN DE

PRUEBAS. [18]

Tabla 13. Formato para la especificación de un Plan de Pruebas [18]

ID: Describa la identificación del plan de prueba

ID de producto / Nombre:

Describir el nombre del producto / Proyecto

Versión / Build del producto:

Describir la versión / build actual del Producto

Propietario actual:

Describir el nombre del propietario del documento Plan de Pruebas en la actualidad.

Creado en: Describa la fecha en que se creó inicialmente el documento

Revisado en:

Describa la fecha en que fue examinado y actualizado por última vez el documento

Revisar por: Describa el nombre y cargo de quien revisó el documento.

Comentarios de la revisión:

Describir los comentarios (si hay), y si estos se han incorporado o no

Versión actual:

Describir la versión actual del Plan de Pruebas

Detalles del cambio:

Describir la descripción delos cambios implementados en el documento, y el tramo afectado del Plan de Pruebas

Estado actual:

Proyecto / En proceso / Aprobado

Firmas: Nombre Posición Firma, Fecha

Describir el nombre

Por ejemplo, Gerente de Calidad, Gerente de desarrollo, Gerente de producto, Gerente de Equipo de lanzamiento

Componentes típicos y directrices Descripción detallada

(1) Ámbito de aplicación del Plan de la prueba: Describa el alcance del plan de prueba para ver lo que cubre y que son las personas afectadas por ella.

(2) Resumen del producto: Breve descripción del producto bajo prueba.



empresas

243

(3) Objetivos de calidad del producto: Describe objetivos importantes de calidad del producto. Algunos de los objetivos de calidad típicos pueden ser. a) La fiabilidad, el correcto funcionamiento según lo especificado y espera. b) La robustez, la respuesta aceptable a las entradas habituales, cargas y condiciones. c) Eficiencia en el uso por los usuarios frecuentes d) Fácil de usar, incluso para los usuarios menos frecuentes

(4) Objetivos de las pruebas: Describir los objetivos de prueba que deben llevarse a cabo por el equipo de pruebas. Los objetivos deben ser mensurables y deben ser priorizados. Algunos del típico ejemplo de objetivos de la prueba puede ser. a) Verificar el correcto funcionamiento. b) Probar la estabilidad y robustez del producto. c) Medir el rendimiento de los lugares o características que son áreas problemáticas.

(5) Supuestos: Describir las expectativas de la situación, para el cumplimiento de las cuales tienen un impacto negativo en la ejecución del plan de pruebas. Los ejemplos típicos de estos supuestos pueden ser los recursos necesarios del presupuesto o de prueba que deben asignarse etc

(6) Ámbito de aplicación de la prueba: Describir de qué va a ser cubierto por las pruebas y lo que se omitirá.

Ámbitos del Testing

Sr. Área Cubierto (Sí / No) Comentarios

1 Datos Por ejemplo, sí

2 Instalación Por ejemplo, sí

3 Interfaz de usuario Por ejemplo, sí

4 Manejo de Errores Por ejemplo, sí

5 Rendimiento Por ejemplo, no

6 Estrés Por ejemplo, no

7 Utilidades --------

8 Escenarios de usuarios --------

9



empresas

244

Aspectos contemplados en pruebas

Sr. Característica Prioridad H - Alto, M - Medio, L-Bajo

Probado (Sí / No)

Comentarios

1 Característica 1

L Por ejemplo, sí

2 Característica 2

H Por ejemplo, sí

3 Característica 3

M Por ejemplo, sí

4 Característica 4

H Por ejemplo, sí

5 Característica 5

L Por ejemplo, no

6 Característica 6

M Por ejemplo, no

(7) Métodos de prueba: Describir el proceso de pruebas o el enfoque que se implementará para probar el producto en sus diferentes fases del ciclo de vida como: a) Fase de elicitación de requerimientos b) Fase de diseño c) Fase de desarrollo d) Fase de estabilización

Descripción detallada

7a) Describir las actividades realizadas por el equipo de pruebas durante cada fase del ciclo de vida del producto

7b) Describa si el equipo de pruebas va a participar en la evaluación de los requisitos y el diseño o no.

7c) Describa si el equipo de pruebas se va a hacer las pruebas de usabilidad o no.

7d) Describa el momento en que el equipo de pruebas iniciará el proceso de levantamiento de casos de prueba, etc

7e) Describir el número de rondas que se han acordado para las pruebas funcionales.



empresas

245

7f) Describa el momento en que la prueba se detendrá.

7 g) Describir los criterios para determinar que el producto es de buena calidad y puede ser liberado.

(8) Tipos de pruebas a utilizar: Identificar los tipos de las pruebas utilizadas de los siguientes elementos.


8a) Pruebas funcionales: El objetivo es confirmar que todos los requisitos funcionales se aplican correctamente

8a1) Técnica de Pruebas funcionales: Ejecute cada caso de uso, utilice el flujo de casos de uso, o la función; a partir de datos válidos y no válidos con el objetivo de verificar que: 1) Los resultados esperados se producen cuando se utiliza datos válidos. 2) El error apropiado o mensajes de advertencia se muestra cuando los datos no válidos se utiliza. 3) Cada regla de negocio se aplica correctamente.

8A2) Criterios de terminación: Asegúrese de que 1) Todas las pruebas previstas se han ejecutado. 2) Todos los defectos identificados han sido abordados.

8a3) Consideraciones especiales en su caso

8b) Pruebas de Interfaz de usuario:

8b1) Técnica de Prueba de Interfaz de usuario:

8b2) Criterios de finalización:

8b3) Consideraciones especiales en su caso

8c) Pruebas de carga:



empresas

246

8c1) Técnica de Prueba de carga:

8c2) Criterios de finalización:

8c3) Consideraciones especiales en su caso

8d) Prueba de resistencia:

8D1) Técnica de Prueba de estrés:

8D2) Criterios de finalización:

8D3) Consideraciones especiales en su caso

8e) de configuración de prueba:

8E1) Técnica de Prueba de Configuración:

8E2) Criterios de finalización:

8e3) Consideraciones especiales en su caso

8f) Pruebas de Instalación:

8f1) Técnica de Pruebas de Instalación:

8F2) Criterios de finalización:

8F3) Consideraciones especiales en su caso

(9) Herramientas de prueba:

Sr.

Nombre de tarea

Herramienta de nombre y la versión

Nombre de distribuidor

Free / Shareware / Comprar

1 Administración de las pruebas

Quick Test Professional 9.2

HP Comprar

2 Pruebas de regresión

Quick Test Professional 9.2

HP Comprar

3 Seguimiento de defectos

Bugzilla Libre

4 Gestión de … … …



empresas

247

Proyectos

5 …

(10) Calendario de pruebas:

10 a) Calendario del proyecto completo

Sr. Proyecto Hito Fecha Programada

Fecha real Comentario

1 Comienza la fase de planificación

2 Finaliza la fase de planificación.

3 Inicia la fase de diseño

4 Test de usabilidad

5 Prototipo completo

6 Finaliza la fase de diseño

7 Inicia la fase de desarrollo

8 Pruebas de la versión interna en aceptación

9 Las pruebas de lanzamiento interno completo

10 Pruebas alfa en aceptación.

11 Pruebas alfa completas.

12 Fase de desarrollo completa.

13 Inicia fase de estabilización

14 Pruebas beta en aceptación.



empresas

248

15 Pruebas beta completas.

16 Liberación del producto.

17 Examen crítico del proyecto

10 b) Programa detallado del proyecto: Describir el calendario de pruebas en detalle, indicando las fechas de inicio y fin de todas las actividades de prueba.

Sr. Actividad Fecha de inicio

Fecha de finalización

Comentario

1 Actividad -1

2 Actividad -2

3 -3 De actividad

4 ........

(11) Recursos: Describir todos los recursos necesarios para ejecutar el plan con éxito.


11a) Personal: Describir el número de personas necesarias, sus roles y responsabilidades y qué habilidades se requieren. Si la formación es necesaria para ellos, entonces los recursos necesarios para capacitar a ellos debe ser mencionado aquí. Detalles de los requisitos de tiempo para ser mencionado en el 'Calendario de Pruebas detalladas que la sección

11 b) Requisitos de hardware: Describir el número de puestos de trabajo necesarios para el equipo de pruebas y sus configuraciones.

11c) Requisitos de software: Describir los sistemas operativos necesarios para estaciones de trabajo y otros programas de software genérico como MS Word, etc excluyendo el software de herramientas de prueba que se menciona en la sección siguiente.

11d) Requisitos de Herramientas: Describir las herramientas de pruebas comerciales necesarias y



empresas

249

cuántas licencias se necesitan.

11e) Entornos de prueba: Describe la configuración del entorno en el que se instalará el producto y el número de tales casos son necesarios para la prueba. La mayoría de los productos necesitan servidores de bases de datos y aplicación. Su configuración de hardware y de software necesitan ser mencionados aquí. ¿Cuántos casos de productos se mantendrá y qué instancia será utilizado para lo que, es necesario mencionar aquí. Por ejemplo una instancia puede ser utilizada para la prueba, otra instancia se puede tener para comprobar las correcciones de los errores antes de aplicarlos en la instancia de prueba.

(12) Comunicación: Describa cómo el equipo de pruebas informará de los errores para el desarrollo, cómo se va a informar del progreso de las pruebas a la administración, cómo se va a informar de los problemas e inquietudes a los niveles más altos.


12 bis) informe y seguimiento de errores: Describa cómo se reportarán los errores al desarrollo y la forma en que se realizará un seguimiento hasta el cierre.

12b) Reuniones: Describa qué tipo de reuniones se llevarán a cabo, su finalidad, sus participantes, sus horarios y su duración prevista.

12c) Informes: Describir los tipos de informes se generan, su contenido, su finalidad y que están destinados a, y si se genera a diario o semanalmente, etc.



empresas

250

ANEXO 15. ESTIMACIÓN DE TIEMPO EN MICROSOFT PROYECT

FRAMEWORK DE APOYO EN EL ANÁLISIS E IMPLEMENTACIÓN...

Documents

Transcript of FRAMEWORK DE APOYO EN EL ANÁLISIS E IMPLEMENTACIÓN...