BPM Lecciones Aprendidas

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

...