Dates for BPMN 2.0 Training in 2012

Purpose Driven BPMN 2.0 Application

Short description

The training explains how BPMN 2.0 can be used for these purposes: “documentation”, “specification”, “model execution” and “model driven development”. The goals for modeling are transparency, integration and flexibility.

The model types of BPMN 2.0 and their purpose-driven application will be explained. You will learn how to use the right modeling elements for the right purpose. You will learn how to assure the quality of the models and how a guideline will support your model creation.

The guideline taught in this training has been proven to achieve short modeling project duration and high customer satisfaction even for difficult modeling tasks. It is based on deep experience in the bpm modeling space and in bpm mentoring.

The training will be in german.

Duration:

2 Days

Price:

1.200€ netto

Participants:

8 Persons

Audience

The training is ideally suited to give you a start in BPMN 2.0 and to have an overview afterwards.

Day 2 is also suited very well for those who already know BPMN 1.x and to learn the new modeling possibilities with BPMN 2.0.

For project leads, members of a modeling project, business process architects, director business process management, business architects, system architects, SOA architects, quality managers.

Dates

Von

Bis

Ort

7. Februar 2012 – 10:00

8. Februar 2012 – 17:00

Stuttgart

6. März 2012 – 10:00

7. März 2012 – 17:00

TechnologieZentrum Ludwigshafen

18. April 2012 – 10:00

19. April 2012 – 17:00

München

22. Mai 2012 – 10:00

23. Mai 2012 – 17:00

Frankfurt

19. Juni 2012 – 10:00

20. Juni 2012 – 17:00

Düsseldorf

12. September 2012 – 10:00

13. September 2012 – 17:00

TechnologieZentrum Ludwigshafen

16. Oktober 2012 – 10:00

17. Oktober 2012 – 17:00

Hamburg

6. November 2012 – 10:00

7. November 2012 – 17:00

Karlsruhe

11. Dezember 2012 – 10:00

12. Dezember 2012 – 17:00

Berlin

Registration and Details

http://www.adapro.eu/site/seminar/SEM-BPMN

Posted in BPM | Leave a comment

Taylorism

In this blog post Jakob Freund shares his arguments why taylorism is a good thing.

He argues, that taylorism is good, because it makes work effective, predictive and scalable – which are in essence the same arguments that Taylor himself brought up – that´s why it is called “Taylorism”.

My answer to this is: It depends. Taylorism is not a good thing per se nor a bad thing per se. It is a good tool if it is used for the right purpose but it is a bad tool, if it is used for the wrong purpose. Take for example physical production of goods – cars, machines and jewelry for example. The production of these typically follow different production types. Cars are typically produced with the production type of line production (Linienfertigung) (this is where all the “Toyota production system” and “Lean Production” ideas come from). Machines are typically produced in job shop production (Werkstattfertigung) and jewelry is typically produced in manufacturing production (Manufakturfertigung). All of these production types follow different rules and management principles. The key is to use the right tool for the right type of product. It is not right to conclude from the fact that line production is good for cars that it is good for jewelry as well.

Now in the area of business process management we are talking in most part about intellectual work or brain work – not so much about physical production. We cannot conclude that if a management style is good for physical production that it is good for brain work as well. Also within brain work we have different types of work that require different styles of work. We cannot conclude that if a work style is good for one kind of brain work, that it is good for the other as well. We need to differentiate.

Yes, the discussions about Adaptive Case Management versus classical Business Process Management are sometimes heated – but I think this is fine. Sometimes it may sound like: “ACM is the only thing” – no – “BPM is the only thing”. Both is not true. It depends. So far we only had BPM and no ACM. So far we tend to see every problem as a nail because we only had a hammer. No – BPM is not the answer to every process management problem; especially not for knowledge work. So far there was no other solution. Now we have ACM – the new kid in town. Now we have more tools available and we are able to address more types of processes that we were able to address before.

BPM itself is a technology to make processes more flexible than – standard software. So BPM is more flexible than standard software and ACM is more flexible than BPM. We need all of the three. No one claims that we do not need standard software in the future. Nor anyone claims that we do not need BPM in the future – at least no one I know. But yes – we claim that we also need ACM in the future. It depends on the type of work. Knowledge work is clearly ACM. But there will also and in the future a lot of routine work that is best done by BPM or by standard software. In routine work effectiveness, predictiveness and scalability are the main attributes. But in knowledge work it is not. In Knowledge work problem solution, creativity and flexibility and goal achievement are the main attributes. These contradict with effectiveness, predictiveness and scalability to some degree. There are always work types that are kind of “in the middle”. For example customer problem processing. Who is more effective? The worker that solves 5 very easy customer problems per hour; or the one that solves a very difficult customer problem in three days? See – it is just wrong to measure work only by throughput.

So my claim is: The right type of tool for the right type of work.

It also depends on the degree of process maturity. If a process is immature – and we always have immature processes if we have innovation – then it is less predictable than a process that is mature. If it is a mature process, it is predictable and scalable.

This is why mature processes can be implemented in ERP Systems, half-mature processes can be modeled with workflow and immature processes cannot. However – now they can be managed by using ACM. In my view it is obvious that there are far more immature processes than there are mature processes. A typical employee has far more emails in his inbox than workflow items. Most of the emails represent knowledge worker processes – processes for ACM.

And – what we need is a “process funnel” – as I tried to depict in the diagram. That is – a process that today is a completely unmanaged process (only by email) should become an ACM managed process. After a while – if it is a mature process – it can become a BPM managed process (for example by exporting it from an ACM system and importing it into a BPM system). After a while – if the process has further matured – it may become part of an ERP system. This approach has the advantage that each step is easier than doing the whole thing from scratch. And only proven processes become part of the mature process landscape. But even then there will be new more unpredictable processes – and that is a good thing. Because they spawn creativity, challenge, competition, achievement and all things that make life interesting and companies flourishing.

An important aspect to this is, that the seamless integration best works if all of those levels follow some basic rules, that I call rules of adaptive processes (that covers more than just adaptive case management). I work to promote the concept of adaptive processes that is a holistic approach to the whole process landscape – be they standard processes, workflows or adaptive case processes – and makes all levels fit to each other.

Posted in BPM | 2 Comments

A common misconception in SOA

I think it is very necessary to think about this statement:

It is not possible to map behavior.

Assume there is a given system landscape of different business systems each fulfilling a part of the business processes. Now assume the goal is to model a common layer of services around these systems, a SOA layer, and to map this layer back to the different business systems. The purpose is to allow flexibility in the underlying system landscape, because the SOA layer remains stable, even if underlying systems change.

I wrote about this already here.

The Enterprise Service Bus (ESB) is designated to fulfill the mapping job. This – often – is a naïve assumption. Why?

What is an Enterprise Service Bus able to do? It can route and transform messages (if we omit the discussion of technical adapters that is irrelevant for now). This is not very much. Message transformation is not enough for mapping the process logic of different application systems. Yes – they can map interfaces from one format to the next – if the mapping is easy. Even if we start to discuss structural transformations and key mapping it is not so easy – but I want to omit this discussion as well.

The point I want to make is about behavior. What is behavior? Behavior is the contract that a service provides to service clients with regards to the messages that it is able to receive or send depending on the state of the business process that the service offers. A service contract that only defines the signature of service operations (WSDL) is too less to understand a service. It is necessary to know if it is possible to send an order cancellation after an order confirmation has been sent from the supplier to the customer or if it is not possible. It is necessary to know if it is possible to send two purchasing change requests in a row, even before the first purchasing change request has been answered or if it is not possible. This is a contract that a service offers to its clients – and it has to be defined. This is behavior. A means to define such a behavioral contract is the BPMN 2.0 choreography and interaction modeling for example.

So – now – if one participant – the customer – of the interaction is able to send a cancellation of an order after the order has been confirmed, but the other participant – the supplier – is not able to process such a cancellation request, then there is no way to make this scenario work by mapping. What should an Enterprise Service Bus do in such a situation? The Enterprise Service Bus certainly does not solve the problem.

So – how can the problem be solved? The only way is to agree on the contract before the business system(s) that should interact are purchased or developed – or to be lucky and thus be able to configure each of the business systems to comply to a contract that is defined afterwards. But good planning is always better than hope to be lucky.

How can this planning be done? Use BPMN 2.0 choreography and interaction modeling.

Posted in BPM | Leave a comment