Lecciones aprendidas de un proyecto BPM

La información de históricos de proyectos BPM es beneficioso para nuevos proyectos y deben ser revisados y analizados preferiblemente al inicio de cada fase.

Se debe promover una cultura organizacional permanente para documentar lecciones aprendidas, la cual debe ser revisada permanentemente y debe contar con un método formal para hacerlo.

Debemos entender que las lecciones aprendidas significan el conocimiento obtenido a través de la reflexión sobre una experiencia o proceso.

Tienen que ser:

Reales: se deben basar en hechos ciertos

Correctas: Tienen un impacto potencial

Importantes: Porque descubren procesos que eliminan errores o construyen un resultado positivo.

Cuando documentamos lecciones aprendidas debemos tener en cuenta como mínimo:

· Qué se hizo bien

· Qué se hizo mal

· Qué no se hizo

Hoy quiero compartir con ustedes sobre lecciones aprendidas en desarrollo de proyectos BPM, las cuales pueden parecer obvias pero son REALES….

1. Análisis y especificación del proceso del negocio

Si volviera a iniciar el proyecto qué repetiría (Qué hice bien):

– Definir las fronteras de los procesos ( integraciones entre procesos)

– Definir un rol para controlar integración entre procesos

– Realizar talleres de entendimiento del negocio con todos los expertos del negocio

– Formación sobre el alcance metodológico en cada una de las disciplinas previo al inicio del proyecto

– Enfoque metodológico equilibrado frente a la herramienta de modelado

Establecer como entregables los siguientes artefactos:

– Documento de visión o definición de alcance

– Documento de caracterización del proceso

– Documento Glosario de Términos

– Documento Modelo de Información (modelo como tal)

Si volviera a iniciar el proyecto qué NO repetiría (Qué hice mal):

– Permitir cambios constantes en el alcance del modelo, planificar gestión de cambios y definir cuáles son realmente relevantes
– Iniciar elaboración de Casos de uso hasta que el modelo de negocio no esté cerrado y aceptado.
– Realizar el modelado del negocio sin la participación del Arquitecto de software y el Ingeniero de Procesos.
– Realizar la fase de conceptualización sin el alcance adecuado, ya que no genera completa claridad del proceso del negocio.
– Utilizar una metodología formal
– Permitir discusiones prolongadas sobre el alcance de un componente del modelo
– Intentar reemplazar la herramienta de BI con BPM
– Plantear que el proceso debe quedar perfecto, se debe pensar en una siguiente iteración

Si volviera a iniciar el proyecto qué haría (Qué no se hizo):

– Incorporar las políticas de escalamiento en el proceso

Espere en mi próximo capítulo lecciones aprendidas en las siguientes fases………..

Ofir Borja Castaño

Business Process Specialist