Kurz-Seminar BPMfuture

Wo stößt die BPMN an ihre Grenzen? Warum werden manche Modelle kompliziert und unflexibel? Funktioniert BPMN nur für Standardprozesse? Wie können unvorhersehbare Prozesse ad-hoc modelliert werden? Management für Prozesse für Wissensarbeiter.

Ideal für BPM Profis und BPM Strategen, Berater und alle, die einen Blick in die BPM Zukunft werfen wollen.

Im Anschluss haben Sie ein Bild von der zukünftigen Richtung von BPM und wie gegenwärtige Grenzen überwunden werden können.

Das Besondere am Seminarformat ist die Interaktivität in der kleinen Gruppe. Jederzeit können kurze Diskussionen das Lernen vereinfachen. Der Trainer hat jahrelange Erfahrung mit solchen Lerngruppen.

Termin: 14. Dezember 2011 von 13.00 Uhr bis 17.30 Uhr
Ort: TechnologieZentrum Ludwigshafen, Donnersbergweg 1, 67059 Ludwigshafen

Das Seminar kostet 250€ zzgl. MwSt.
Snacks, Getränke und Seminarunterlagen sind inbegriffen.

Anmeldung bitte bis zum 1. Dezember. Die Teilnehmerzahl ist auf 8 begrenzt.
http://www.adapro.eu/site/seminar/BPMNfuture

Ihr Trainer:

Frank Michael Kraft, Geschäftsführer der AdaPro GmbH, ist Mitautor des BPMN 2.0 Standard. Er hat 19 Jahre Industrieerfahrung als Systemanalytiker und Software-Architekt für Individualsoftware und Standardsoftware. Er ist Experte und Innovator, vor allem im Bereich der Serviceorientierten Architektur (SOA) und des Business Process Management (BPM). Herr Kraft hat umfangreiche praktische Erfahrung im Mentoring der Modellierung von Geschäftsprozessen und ist als Gutachter für die EU-Kommission tätig.

Posted in BPM @de | Leave a comment

What is a SOA enabled Application?

In one of my last posts I said, that I think it is a good SOA strategy to buy SOA enabled applications and to interweave them. But I did not define, what I mean by “SOA enabled”.

  1. The Web Service Operations that are the interface to the application must be described as WSDL.
  2. Technical Means must be available to connect the application to an Enterprise Service Bus (ESB).
  3. WSDL is not enough, because it only describes the signature of the service interface. What is also needed is a model of the service behavior. The allowed sequence to call service operations must be modeled as business process model (for example BPMN 2.0 choreography diagram). For example it must be modeled if or if not it is possible to cancel an order after it has been released or not. This is not visible in the WSDL signature, but can only be visible within a service behavior model. And it is decisive to integrate.
  4. The application should not be monolithic, but decomposed into components that represent individual process participants that communicate with each other in a loosely coupled way.
  5. The granularity of the service operations must represent real reuse. This means, that the service operations may only do one thing at a time and not a chain or sequence of many activities. This is necessary to compose the service operations to new composed services. For example it must be a different step to create an order and to release it.
  6. Extension Points must be modeled. Extension points are those points in an application process where extenders are allowed to attach an individual process. For example it might be possible to add additional an approval to a purchasing process. This must be modeled. Also integrity conditions must be modeled. For example it is necessary to have exactly one purchase order for individual purchase order confirmations. This is an integrity condition that must be modeled.
  7. It must be possible to define new business objects or extensions to existing business objects.
  8. All of this model information must be available in a repository.

This is my requirement list for a SOA enabled application. Yes, I admit, these are many requirements and I do not know one single software package that does fulfill them all. I know software packages that come close. I would not buy any software that falls short of many of these points.

I think most would say, that 1 and 2 is sufficient. I wouldn’t. I think that 3 till 8 is also necessary to make a SOA integration project successful. This knowledge often is only available through the individual knowledge of consultants. But there is no reason to not model it and thus make a SOA project much more economic.

Posted in BPM | Leave a comment

Adaptive Processes Taxonomy

Last week at the BPM | SOA Integration Days we also discussed about Taxonomy for Adaptive Processes.

In my first discussion with Max J. Pucher I said, that I still struggle with the “Case” in the “Adaptive Case Management”. He proposed the use of the term “Adaptive Processes” instead.

Later, following our talks, the audience also raised the same question. They said: Why “Case”? I said that a “Case” is the business object that is the reason to start an adaptive process or workstream. However the generic “pure” workstream would be a set of activities with status somehow (loosely) related – comparable to a workflow that is also not a business object, but a generic “pure” entity.

I believe that Case is a business object, and a Case may as well relate to Workstream or also to Workflows. The distinction between Workflow and Workstream in my eyes is this:

  • A Workflow is a flow oriented model of interrelated Activities that is preplanned.
  • A Workstream is a set of Activities, that is not necessarily preplanned, that are related, but not necessarily in a flow oriented way (probably in a constraint oriented way).

These two are generic while the Case is a business object of a certain form. For example there may be Customer Service Cases or Insurance Claim Cases – both of which have different attributes. The Case is the common super class of all of these possible variants of Cases and maybe their predominant commonality is that they can be related to a Workstream.

However why only Cases should be related to Workstreams? Why not Opportunities, Campaigns, Sales Orders, Logistic Orders, Accounts, and in general all Business Objects that may exist? I believe there are use cases for all of these business objects to be involved within an unpredictable Workstream.

That is the Case Part of the discussion. But there is also another part of the discussion.

As I discussed in Dead or Alive! I have the opinion, that it is also possible to define characteristics of Workflows and of SOA that make them adaptive. In this case we would have three categories of adaptive processes:

  1. Adaptive Case/Workstream Management
  2. Adaptive Workflow Management
  3. Adaptive SOA

If this is true, then I would use the term “Adaptive Process Management” or “Adaptive Business Process Management” to name everything that falls into one of these categories. So an Adaptive Process would be either an Adaptive SOA process, an Adaptive Workflow or an Adaptive Case/Workstream.

I suspect that if Max J. Pucher sais “Adaptive Process” he means something within Category 1), while I mean all three categories.

So – I think there is still something to discuss before we have a common Taxonomy for Adaptive Processes and Adaptive Case Management.

Posted in Adaptive Processes | Leave a comment