In the second part of my tip-Series for Business Process Management I would like to address fundamental project management issues: strategy, goals, communication and risk management.

(More ...)

A long day ends. Today I was a guest at the 5th PSD of the gfo (www.gfo-kongress.de). In 3 parallel streams various BPMS were presented by the manufacturers. Each manufacturer had 45 minutes time to refer to one of three topics. The first topic was modeling and documentation. Topic two Topic three was SOA and human workflow and process portals. I've mainly seen the presentations on human workflow.
I'm surprised positively how far the tool manufacturers are now. All of the products were exclusively zero-coding solutions . At the core of the BPMS is little difference can be discerned. All support versioning process, roles, documents, attachments, and various interfaces to external systems. But the devil is in the details. Some of the tools come along with self-designed modeling notations. Unfortunately, I also find that some of the presenters of process modeling had to be not much of a clue (who called an activity please "boss"?). In general, the greatest differences were found in the modeling. While some tools have to be modeled in the process models are very technical (are almost model-view controller), other manufacturers can continue and there will be very close to passing business processes to the engine (for example on Xpert.ivy or Appian ), or even model takes into account different levels (as with inubit ).
First, I must now process the first time all impressions. There is no compact way over such a large number of products to inform. Some of the tools I'm going to look at in the next few weeks, certainly not more accurate.

In the following weeks, I would like to publish a small series with useful tips on the topic of Business Process Management. This article is the first of this series, which will include a total of 20 tips. The first three tips deal with the issues of standards, experience and incomplete process models. (more ...)

There are now some good BPM suites systems and processes allow it to fully implement without programming. In some tools will be modeled more and more in other configuration. Due to the continuous distribution of recognized standards (web services, BPEL and BPMN over) have the software maker a wider basis on which their tools can be built.

But where are the opportunities and risks existing in the market zero-coding solutions? (more ...)

After the third workshop on Agile BPM there are new questions for which we must find an answer. First, we have expanded our focus. We now consider not only scrum. We will now examine some aspects of agility for their applicability in BPM projects.

The thesis that the agile techniques, process models, principles and approaches to faith in BPM projects have an advantage ablative methods is still a classic. Especially in the spot speed and flexibility supports the "agility" while successfully implement BPM projects.

In order to test this hypothesis we have (friend of camunda Jacob, Christian Weiss of oose, Martin and I Bartonitz of Saperion Seven Principles) are based on the structures, the Christian in his video showing more concerned with the issue. Here we have once again found that the projects on BPM can be very very different. Even if we commit ourselves to a very simple IT-based process. Today's technologies are based on a still very intensive programming implementation (eg jBPM) to the zero-code "development" (eg Intalio or inubit). These differences are reflected in the consideration which naturally agile components can be put to good use again.

The interesting questions for me to date are:

• How do I deal with iterations in the zero-coding BPMS?
• What should I look at the various iterations when interfaces are involved?
  • This interface and an enterprise service bus contracts make sense?
• Is it possibly make sense in the BPM 2.0 prototyping approach apply?
• What should I look out for when I'm in my iterations of a high degree of dependence on "external systems"? (Eg if you also need interfaces, consume you want, but to access, complete the bz only conditional influence)
• How can you break down projects make sense? If my process still needs to be developed as a GUI, then the GUI development is yet again a classic theme in the development of BPM project
• How to deal with change requests in the BPM project? Especially if these CRs have a significant influence on the process flow.

In all this mind, I find myself once again very close to IT projects. But it is always important to mention that IT's share is in BPM projects often only 20% of the overall project.