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.

L'utilisation de Scrum dans des projets de BPM dépend de plusieurs facteurs. La première est la complexité des processus et l'objectif du projet.

Ces différents scénarios, je voudrais vous expliquer ci-dessous:

Pour tous les niveaux de complexité quelques précautions doivent être observées avant que l'on commence à exécuter des processus dans les systèmes informatiques à mettre en œuvre:

• Stratégie pour le processus de mise en œuvre est disponible
• BPMS est un système exécutant disponibles
• Des professionnels expérimentés sont disponibles pour l'analyse des processus

Si ces points ne sont pas remplies, vous devez créer dans les étapes en amont du projet, ces bases. Il est conseillé de mettre en œuvre une stratégie pour traiter à définir. Il décrit comment les processus dans l'environnement informatique pour être intégré, comment les responsabilités doivent être réglementés pour les processus (propriétaire du processus) et les méthodologies, les techniques et les conventions qui seront utilisés. Par une bonne stratégie pourrait être mise en œuvre plus tard, les processus de manière rapide et flexible. La stratégie de croissance que progressivement avec la personne à mettre en œuvre processus conduit souvent au fait que les processus ne sont pas standardisés, difficiles à maintenir et à volonté inflexible. Une stratégie unifiée réduit également la documentation nécessaire et réduit ainsi la courbe d'apprentissage des nouveaux employés. Depuis les éléments essentiels des différents procédés sont identiques et suivent les mêmes règles.

Scrum pour les processus avec une faible complexité:

Scrum peut être vécu ici dans sa forme pure complètement. Surtout quand de nombreux processus devrait être mis en œuvre avec une faible complexité de modèle de processus avec les systèmes informatiques, cela peut être réalisé avec de très bonnes mêlée. Processus analystes se réfèrent au modèle de ces processus avec le client le meilleur et avec une notation de modélisation standardisée (par exemple, BPMN). Des procédés simples peuvent être analysées au cours du processus de modélisation par des analystes expérimentés pour optimiser le flux de processus pour un, mais aussi de déterminer les ressources requises, les données et indicateurs de performance. Les modèles que l'on peut être mis en œuvre sculptée dans un BPMS. Certaines suites de BPM existantes commerciales offrent la possibilité de construire des processus modélisés et mettre en œuvre le processus de conception (mise en œuvre des détails techniques qui sont nécessaires pour l'exécution des processus). Après le processus peut être testée immédiatement par le client dans les BPMS. Processus de faible complexité qu'elle permet à tous de ces étapes au sprint (soit 4 semaines) à effectuer.

Scum sur des projets d'une complexité moyenne:

Ici, il devient difficile de se conformer à l'itération courte de la mêlée. Scrum définit qu'après chaque Sprint est l'exécution d'un produit compatible peut être livré. Les processus sont trop grands pour les modéliser au cours du sprint, analyser, concevoir et mettre en œuvre on a en principe trois possibilités:

1. Processus de réduire la fracture /
2. Le sprint de prolonger
3. Les résultats d'un sprint de définir différents

Pour décomposer 1) Le processus n'est pas possible pour tous les processus. Premièrement, cette approche ne prend pas en charge toutes les suites BPM, et des systèmes. Pour d'autres processus de délivrer un résultat précis. Avec les intermédiaires, qui peuvent survenir au cours d'un processus, le propriétaire du produit rien faire. Ainsi, ce processus de briser que si le processus permet à tout cela. C'est souvent le cas lorsque les processus montrent de nombreuses branches parallèles. Ensuite, ces branches parallèles sont mises en œuvre progressivement. Une réduction des processus pourrait signifier que les mesures devraient être automatisées, ou les interfaces sont mappés dans un processus dans la version d'essai d'une tâche manuelle. Ce n'est évidemment pas possible dans le traitement des données de masse, les processus avec l'interactivité humain élevé déjà bien. Par exemple, les utilisateurs peuvent avoir besoin dans la première version de données transférées manuellement dans des systèmes tiers et dans le sprint suivant, les interfaces développées et automatisé. Un inconvénient majeur du processus de décomposition / réduction est que l'utilisateur doit s'habituer pendant le processus de mise en œuvre après chaque étape d'un processus légèrement différent. Cela peut conduire à la confusion et de frustration.

Pour 2) Une extension générale des sprints dans un projet Scrum est possible. Donc on peut s'écarter de la 4 semaines habituelles et éventuellement de définir six ou même huit semaines comme une durée de sprint. Généralement, ce n'est pas dans le sens de Scrum. Grâce à plus de sprints, une grande partie de l'agilité serait perdu par Scrum. Le propriétaire du produit doit attendre trop longtemps dans certaines situations à de nouvelles exigences peuvent être réalisées. Par conséquent, l'extension des sprints avec prudence et ne doit pas excéder 8 semaines.

Le 3) La troisième possibilité est une combinaison de Kanban et Scrum. Il n'est pas mis en œuvre à la fin d'un sprint l'étape finale, mais il ya par exemple besoin d'un total de trois sprints. Dans le premier sprint, les processus sont modélisés dans le second Sprint pour analyser les processus et les trois Sprint est dans la conception et la mise en œuvre. Cela réduit l'agilité tout en arrière (le processus est terminé seulement après 3 sprints), mais par rapport à l'avantage de l'extension de Sprint, qui est toutes les 4 semaines pour fournir des résultats visibles. Le propriétaire du produit peuvent intervenir toutes les 4 semaines et éventuellement faire de nouveaux produits pour le backlog de sprint avec et peut rendre le projet meilleur. Par ailleurs, cette variante permet que vous instruire dans toutes les équipes de sprint avec des tâches différentes. Ainsi, la modélisation sera réalisée par une équipe d'analystes qui possèdent aucun savoir-faire technique des processus à modéliser et se portent très bien avec les processus futurs utilisateurs dans les ateliers ou d'entretiens à recueillir. La prochaine équipe analyse et optimise les processus et est spécialisée. La troisième équipe est spécialisée dans la mise en œuvre les processus nécessaires et le développement d'interfaces. Cela peut augmenter considérablement l'utilisation d'équipes et d'éviter les temps d'inactivité des spécialistes individuels. On voit ici déjà, mais que l'on est aussi des "classiques" des processus Scrum doit s'écarter de complexité moyenne à réaliser.

Scrum pour les processus de grande complexité

Processus de grande complexité peut éventuellement uniquement avec l'décrites ci-dessus traitent "Kanban et Scrum" combinaison. Si cette modélisation atelier de longs processus et l'analyse nécessaires et sont nécessaires à l'introduction de changements organisationnels majeurs déjà vrai des experts Scrum besoin de travailler. C'est probablement un des Points de presse Scrum est utilisé pour séparer les activités runterzubrechen et distribués aux différentes équipes. Ceci est encore important de s'assurer que les histoires d'utilisateurs sont divisés en parties significatives des paquets qui peuvent être réalisées dans un sprint. Néanmoins, le Manifeste Agile est également à noter ici. Et il devrait être modélisés aussi rapidement que possible essayer de rendre les processus de fonctionner. Parce suivi une phase de modélisation et d'analyse, qui dure plusieurs mois d'une mise en œuvre de longues conduit souvent à l'échec des projets. Il devrait également tenter de "commencer petit grandir« l'approche à suivre. Avec la version d'essai afin que vous ne devriez pas essayer de traiter 100% sûr car avec tous les cloches et sifflets (interfaces, automatisation, etc) à mettre en œuvre, mais une réduction significative. Pour les derniers 10% sont toujours les plus chers de toute façon.