Después de que el tercer taller sobre BPM ágiles hay nuevas preguntas para las que tenemos que encontrar una respuesta. En primer lugar, hemos ampliado nuestro enfoque. Consideremos ahora no sólo scrum. Ahora vamos a examinar algunos aspectos de la agilidad en su aplicación en proyectos de BPM.

La tesis de que las técnicas ágiles, modelos de procesos, principios y enfoques de la fe en los proyectos de BPM tiene una ventaja gegnüber métodos clásicos sigue en pie. Por encima de todo, la velocidad del punto y la flexibilidad, la "agilidad", mientras que con éxito proyectos de BPM.

Para comprobar esta hipótesis tenemos (amigo de CAMUNDÁ Jacob, Christian Weiss, de OOSE, Martin y yo Bartonitz de Saperion siete principios) se basan en las estructuras, el cristiano en su vídeo muestra más comprometido con el tema. Aquí tenemos una vez más que los proyectos de BPM pueden ser muy diferentes. Incluso si nos fijamos un muy simple, basado en el proceso. Las tecnologías actuales se basan en una implementación aún programado muy intensa (por ejemplo, jBPM) al cero del código de "desarrollo" (por ejemplo, Intalio o inubit). Estas diferencias se reflejan en el examen de los componentes que naturalmente ágiles pueden dar un buen uso de nuevo.

Las preguntas más interesantes para mí hasta la fecha son los siguientes:

• ¿Cómo puedo lidiar con cero de codificación de iteraciones en BPMS?
• ¿Qué debo buscar en las diferentes iteraciones cuando entran en juego interfaces?
  • Esta interfaz y un contrato de servicios de la empresa de autobuses tiene sentido?
• ¿Hay algún sentido en el enfoque de BPM 2.0 prototipos se aplican?
• ¿Qué necesito si estoy en mi octavo iteraciones, un alto grado de dependencia de los "sistemas externos"? (Por ejemplo, si una interfaz es también instruyó a consumir se quiere, pero el acceso a, complete el bz sólo tiene una influencia limitada)
• ¿Cómo se puede dividir proyectos de sentido? Si mi proceso todavía tiene que ser desarrollado como una interfaz gráfica de usuario, entonces el desarrollo GUI es una vez más un tema clásico en el desarrollo de proyectos BPM
• ¿Cómo tratar las solicitudes de cambio en el proyecto de BPM? Especialmente si estos CRs tienen una influencia significativa en el proceso.

En todas estas consideraciones, me encuentro de nuevo muy cerca de los proyectos de TI. Pero siempre es importante mencionar que la participación es en los proyectos de BPM a menudo sólo el 20% de la totalidad del proyecto.

Como el artículo " Kick-Off: BPM Scrum + "ha publicado el amigo Jacob en bpm guide.de queríamos ejemplos de los diferentes" modelos "traer. Un sprint de Scrum es que dure entre uno y un máximo de 4 semanas. Por lo tanto, puede ser necesario un proceso de descomposición en unidades más pequeñas de estas unidades para poder editar en los sprints. Dado que el resultado de una carrera de velocidad de un "producto ejecutable entregable" debe ser, deben ser procesos grande dividido para que estos procesos sub-pueden ser útiles y lanzó la mayor independencia posible. Siguiendo el ejemplo del desmantelamiento de los procesos con múltiples trenes de proceso paralelo. (más ...)

Tengo experiencia frecuente, con una muy larga en proyectos de Business Process Management hecho. Principalmente a través de la colaboración de muchos departamentos en un proceso de extremo a extremo, es un proceso cada vez más grande y más difícil de retraso del proyecto. A pesar de las muchas actividades en el proceso a menudo sido totalmente aclarado y puede que incluso han desarrollado ya ha completado el proceso no se puede importar porque en algún lugar un poco de actividad debe ser coordinada. A través de un enfoque ágil permitiría a todas las actividades que se ejecutarán más rápido y claro el resultado deseado podría ajustar más rápidamente. Por lo tanto, la cuestión de Scrum es muy interesante, pero no es fácil. Scrum fue originalmente diseñado para el desarrollo de software y no para los proyectos de BPM. Mi primer pensamiento en esta combinación, que he descrito aquí en el blog anterior (véase la Parte 1 y Parte 2 ). Las mismas ideas también han Dr. Martin Bartonitz de Saperion y Jacob amigo a partir de CAMUNDÁ. Para llegar al intercambiar y discutir la combinación de Scrum y BPM, hemos tenido un pequeño taller con James en Berlín. Los resultados de nuestros primeros talleres son en bpm guide.de y miró hacia arriba en el foro de la red de BPM se discuten. Estoy esperando a los comentarios en el foro.

En la primera parte del tema de Agile Business Process Management , escribí mis primeros pensamientos sobre la forma de analizar los procesos de modelado utilizando Scrum. En la segunda parte, me gustaría abordar la cuestión con más detalle.

(Más ...)

Ágil la gestión de proyectos es de hecho el tiempo, especialmente en proyectos de TI anunció total. Cada vez más empresas están interesadas en Scrum, XP y compañía no porque muchos proyectos se llevan a cabo por métodos convencionales PM. Las razones son a menudo la complejidad de los proyectos y la falta de comunicación.

Los mismos problemas que yo también sé de los proyectos de BPM. Se pierde en el modelado de procesos, análisis y diseño en detalle. Estas fases suelen tomar varios meses. Los procesos están diseñados de acuerdo con el análisis ya no están en el comienzo del diseño de la fecha, pero después de aplicado todavía en ningún sistema. En efecto, los procesos no se ajustan a la ya desde hace mucho tiempo un verdadero negocio cambió.

Funciona mejor en este ambiente, un enfoque ágil?

(Más ...)