Après le troisième atelier sur agiles BPM il ya des questions nouvelles 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é sur leur applicabilité dans des projets BPM.

La thèse selon laquelle les techniques agiles, des modèles de processus, les principes et approches de la foi dans les projets de BPM ont une des méthodes classiques gegnüber avantage tient toujours. Surtout, la vitesse de pointe et la flexibilité, la «agilité» tout en œuvre avec succès des projets de BPM.

Pour vérifier cette hypothèse, nous avons (ami de camunda Jacob, Christian Weiss de oose, Martin et moi Bartonitz du Saperion sept principes) sont basées sur les structures, le chrétien dans sa vidéo montre plus engagé avec la question. Ici nous avons une fois de plus constaté que les projets sur le BPM peut être très très différentes. Même si nous nous fixons un très simple basés sur les TI processus. Les technologies d'aujourd'hui sont basées sur une mise en œuvre reste programmée très intense (par exemple, jBPM) pour le 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 mises à profit à nouveau.

Les questions intéressant pour moi à ce jour sont:

• Comment puis-je faire face à zéro de codage itérations dans BPMS?
• Que dois-je regarder les différentes itérations lorsque les interfaces sont impliqués?
  • Cette interface et un contrat Enterprise Service Bus sens?
• Yat-il un sens dans le BPM 2.0 prototypage démarche appliquer?
• Que dois-je si je suis dans mon itérations huitième, un degré élevé de dépendance à l'égard «des systèmes externes"? (Par exemple, si une interface est également chargé de consommer l'on veut, mais d'accès, de compléter le BZ n'a qu'une influence limitée)
• Comment pouvez-vous briser les projets de sens? Si mon processus doit encore être développé comme une interface graphique, puis ce développement GUI est encore un thème classique dans le développement du projet BPM
• Comment traiter les demandes de changement dans le projet de BPM? Surtout si ces CRS ont une influence significative sur le processus.

Dans toutes ces considérations, je me retrouve encore une fois très proche de projets informatiques. Mais il est toujours important de mentionner que c'est la part est dans des projets de BPM souvent que 20% de l'ensemble du projet.

Comme l'article de " Kick-Off: BPM Scrum + "a publié le Jacob ami sur bpm guide.de nous voulions des exemples de différents" modèles "apporter. Un sprint dans Scrum est de durer entre un et un maximum de 4 semaines. Par conséquent, il peut être nécessaire de décomposer un processus en unités plus petites de ces unités à être en mesure de modifier dans les sprints. Depuis le résultat d'un sprint un «produit livrable exécutable" devrait être, doivent être des processus grandes divisée afin que ces processus sous-traitance peut être utile et déployé de façon aussi autonome que possible. Suite à mon exemple du démantèlement des processus avec de multiples trains processus parallèle. (more ...)

J'ai de l'expérience fréquente de projets avec un très long sur le Business Process Management a fait. Principalement grâce à la collaboration de plusieurs ministères dans un processus de bout en bout est un processus s'agrandit et plus difficile attendue du projet. Bien que de nombreuses activités dans le processus souvent été entièrement clarifiée et peut même avoir été développé déjà complété le processus ne peut pas être importé parce que quelque part un peu d'activité doit être coordonnée. Grâce à une approche agile permettrait à toutes les activités devant être mises en œuvre plus rapidement et clairement le résultat souhaité pourrait s'adapter 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 pour des projets de BPM. Mes premières pensées sur cette combinaison, j'ai décrit ici dans le blog avant (voir la partie 1 et partie 2 ). Les mêmes idées ont également le Dr Martin Bartonitz du Saperion et ami Jacob fait à partir camunda. Pour nous voir pour échanger et discuter de la combinaison de Scrum et de BPM, nous avons tenu un petit atelier avec James à Berlin. Les résultats de nos premiers ateliers sont sur ​​le BPM guide.de et regarda dans la tribune du réseau BPM sont discutées. Je suis impatient de la rétroaction dans le forum.

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

(More ...)

Agile Project Management est en effet l'époque, en particulier dans les projets informatiques a annoncé au total. De plus en plus sont intéressés à Scrum, XP et Cie échouent parce que de nombreux projets sont réalisés par des méthodes conventionnelles PM. Les raisons sont souvent la complexité des projets et une mauvaise communication.

Les mêmes problèmes je sais aussi de projets de BPM. Il se perd dans la modélisation des processus, l'analyse et de conception dans le détail. Ces phases prennent souvent plusieurs mois. Les processus sont conçus en fonction de l'analyse ne sont plus au début de la conception à jour, mais après encore mis en œuvre dans tout système. En effet, les processus ne sont pas aptes à la déjà depuis longtemps une entreprise changé réel.

Fonctionne le mieux dans cet environnement, une approche agile?

(More ...)