Dans la deuxième partie de ma série sur la pointe de Business Process Management, je voudrais aborder des questions fondamentales de gestion de projet: stratégie, objectifs, communication et gestion des risques.

(More ...)

Une longue journée tire à sa fin. Aujourd'hui j'ai été invité à la 5ème PSD de GFO (www.gfo-kongress.de). En trois volets parallèles ont été présentés par les vendeurs BPMS diverses. Chaque fabricant a 45 minutes de temps de se référer à l'un des trois sujets. Le premier thème a été la modélisation et la documentation. Sujet deux Sujet trois était SOA et du workflow humain et portails processus. J'ai essentiellement vu les présentations sur un workflow humain.
Je suis surpris à quel point les fabricants d'outils sont maintenant. Tous les produits ont été exclusivement zéro de codage des solutions . Au cœur de l'BPMS guère de différences peuvent être discernés. Tous les processus de gestion des versions de soutien, les rôles, les documents, pièces jointes, et différentes interfaces d'autres systèmes. Mais le diable est dans les détails. Certains de ces outils viennent avec les notations de modélisation auto-conçu. Malheureusement, je trouve également que certains des présentateurs de la modélisation des processus a dû être pas beaucoup d'un indice (qui, s'il vous plaît appelez une activité "supérieure "???). Généralement, les plus grandes différences ont été trouvées dans la modélisation. Alors que certains outils doivent être modélisées dans les modèles de processus très technique (presque Modèle-Vue Contrôleur), d'autres fabricants peuvent continuer et il sera très proche de passer processus d'affaires pour le moteur (par exemple sur Xpert.ivy ou Appia ), ou encore modèle prend en compte des différents niveaux (comme avec inubit ).
D'abord j'ai maintenant le temps seulement de traiter l'impression entière. Il n'ya pas de façon compacte sur un tel grand nombre de produits pour informer. Certains de ces outils, je vais regarder dans les prochaines semaines, certainement pas plus précis.

Dans les semaines suivantes, je tiens à publier une série de petits avec des conseils utiles sur le thème du Business Process Management. Cet article est le premier de cette série, qui comprendra un total de 20 conseils. Les trois premiers conseils traiter les questions de normes, l'expérience et des modèles de processus incomplet. (more ...)

Il ya maintenant quelques bons systèmes de BPM suites et les processus de lui permettre de pleinement mettre en œuvre sans programmation. Dans certains outils, et d'autres modèles sont plus susceptibles configuré. Par la diffusion régulière des normes reconnues (web services, BPEL et BPMN plus) ont également le fabricant de logiciels d'une base plus large sur laquelle leurs outils peuvent être construits.

Mais où sont les opportunités et les risques existants sur le marché des solutions de codage à zéro? (more ...)

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.