Après le troisième atelier sur Agile BPM il ya de nouvelles questions pour lesquelles nous devons trouver une réponse. Tout d'abord, nous avons élargi notre attention. Nous considérons maintenant non seulement mêlée. Nous allons maintenant examiner certains aspects de l'agilité de leur applicabilité dans des projets BPM.

La thèse selon laquelle les techniques agiles, modèles de processus, les principes et les approches de la foi dans les projets de BPM ont un avantage méthodes ablatives est toujours un classique. Surtout dans la vitesse de place et la flexibilité prend en charge le «agilité» tout en réussissant à mettre en œuvre des projets de BPM.

Afin de tester cette hypothèse, nous avons (ami de camunda Jacob, Christian Weiss, de oose, Martin et moi Bartonitz de Saperion sept principes) sont basés sur les structures, le chrétien dans sa vidéo montrant davantage préoccupés par la question. Ici, nous avons une fois de plus constaté que les projets sur BPM peut être très très différent. Même si nous nous engageons à une très simple basé sur les TI processus. Les technologies actuelles sont basées sur une mise en œuvre de programmation encore très intensive (par exemple jBPM) au zéro-code "de développement" (par exemple Intalio ou inubit). Ces différences se reflètent dans la considération qui composants naturellement agiles peuvent être utilisés à bon escient à nouveau.

Les questions intéressantes pour moi à ce jour sont les suivants:

• Comment puis-je faire face à des itérations dans les BPMS zéro de codage?
• Que dois-je regarder les différentes itérations lorsque les interfaces sont impliqués?
  • Cette interface et un contrats Enterprise Service Bus de sens?
• Est-il possible de sens dans la démarche de BPM 2.0 prototypage appliquer?
• Que dois-je regarder dehors pour quand je suis dans mes itérations d'un degré élevé de dépendance à l'égard "des systèmes externes"? (Par exemple, si vous avez aussi besoin d'interfaces, de consommer vous voulez, mais d'accès, de compléter l'bz qu'une influence conditionnelle)
• Comment pouvez-vous briser les projets de sens? Si mon processus doit encore être développé comme une interface graphique, puis le développement d'interface est encore un thème classique dans le développement de BPM projet
• Comment faire face à des demandes de changement dans le projet de BPM? Surtout si ces CRS ont une influence significative sur le déroulement du processus.

Dans tout cela, l'esprit, je me retrouve une fois de plus très proche de projets informatiques. Mais il est toujours important de mentionner que c'est la part est en projets de BPM souvent seulement 20% de l'ensemble du projet.

Comme dans l'article " Kick-Off: BPM + Scrum "publié sur le guide.de James ami bpm nous voulions des exemples de différents« modèles »apportent. Un sprint dans Scrum est de durer entre 1 et un maximum de 4 semaines. Par conséquent, il peut être nécessaire de diviser un processus en unités plus petites de ces unités de travail dans les sprints à. Comme le résultat d'un sprint un «produit livrable exécutable" devrait être, doit être divisée de manière grands processus que ces sous-processus peuvent être utiles et mis en œuvre de façon aussi autonome que possible. Suite à mon exemple du démantèlement des processus avec de multiples trains de processus parallèles. (more ...)

J'ai de l'expérience fréquente avec quelques projets très longs sur le Business Process Management faites. Principalement grâce à la collaboration de nombreux ministères dans un processus de bout en bout est un processus de plus en plus grande et le projet plus fortement en retard. Bien que de nombreuses activités dans le processus souvent été totalement élucidées et peut-être même été développé déjà achevé le processus ne peut pas être importé car l'activité quelque part un peu plus seront coordonnés. Avec une approche agile permettrait toutes les activités à mettre en œuvre plus rapidement et plus clairement le résultat souhaité pourrait être ajusté plus rapidement. Par conséquent, la question de Scrum est très intéressant, mais pas facile. Scrum a été initialement conçu pour le développement logiciel et non pas pour des projets de BPM. Mes premières pensées sur cette combinaison, je l'ai déjà décrit dans le blog (voir la partie 1 et partie 2 ). Les mêmes idées ont également le Dr Martin Bartonitz de Saperion et ami Jacob fabriqués à partir de camunda. Pour que nous puissions discuter et de partager la combinaison BPM Scrum et nous avons tenu un petit atelier avec James à Berlin. Les résultats de nos premiers ateliers sont sur ​​bpm guide.de et leva les yeux dans le forum du réseau BPM sont discutés. Je suis impatient de la rétroaction dans le forum.

Dans la première partie du sujet Business Process Management Agile , j'ai écrit mes premières réflexions sur la façon d'analyser les processus modélisés avec Scrum. Dans la deuxième partie, je voudrais de plus près la question.

(Plus ...)

Parce que je vient de se passer de venir d'une formation PRINCE2 et maintenant mon mal à l'épaule de livres portant j'en suis venu à ces méthodes légèrement différentes de comparaison entre Scrum et PRINCE2.

(Plus ...)