Adaptive Processes and SAP Business ByDesign

I have not been blogging for quite a while. But now I need to.

There have been quite some articles about SAP Business ByDesign recently. But I found none as informative as necessary.

Why do I blog about SAP Business ByDesign? Recently my main topic blogging were Adaptive Processes. However what is happening now with the SAP cloud portfolio is a lot about Adaptive Processes. I will explain this.
Last week I heard Vishal Sikka say in a call something like “SAP Business ByDesign is probably the best designed Application in the history of Applications.” I fully agree. This has a lot to do with the fact, that ByDesign is model driven, service oriented and BPM driven in a way that no other business application in the world is. But these are technical attributes. They have a reason.

The reason is one of the most difficult problems in the world of application development, that is most relevant for providers of business software as well as for the customers using the business software. It is the problem of implementing and using standard processes as well as customer specific processes – running smoothly together.

No software provider in the world will ever offer a software solution that covers all business processes in one solution or suite. It is absolutely logical, that every software provider needs to concentrate on core standard processes that are relevant for defined markets – that is the only reason why standard processes have a cost advantage over individual processes – they are re-used in defined markets. At the same time an individual solution for an individual customer needs to fulfil the requirements of individual business processes – the same business processes that make a company unique and often are their competitive advantage.

In the same way as is important to be able to support customer specific processes that run integrated with standard processes it is important for partners to be able to provide specific processes for defined markets, those markets that the standard process software provider does not address.

We have three levels of processes:
1) standard processes,
2) partner processes and
3) customer processes.
All of these need to be ingrated.

It is important to understand this as a basis for the further discussion.

For this to happen there are these two preconditions:
1) The right process technology
2) The right technology platform

As we already said, SAP Business ByDesign is the best designed business application in the history of business applications. All people I meet, that know enough about ByDesign witness to this. In essence the reason is, because ByDesign uses the right process technology, a process technology that makes it fit for adaptive processes. Adaptive processes is the process technology, that is extensible enough to support the kind of process extensions, that I mentioned before. For example, Salesforce has no process technology at all – with the exception of some little workflows. But this is not what I mean. So Business ByDesign fulfils the first precondition. That is why it is called “ByDesign”.

The second precondition is the right technology platform. In this context, as we are speaking about the cloud, we need the right technology platform for the cloud, that is flexible and extensible in the most effective way. In the last 20 years database technology has not changed substantially. Therefore – of course – ByDesign was built with existing database techology – just as any other application has been. Current database techology however is not as extensible as needed. I do not want do go into details about it now. Things are currently changing dramatically. With the apperance of SAP HANA there is a new era of databases. So now it is possible to build an extensible Cloud Platform as never before.

Therefore it is 100% logical, that SAP will bring the ByDesign to the SAP HANA Cloud Platform. SAP must do this, because in this way ByDesign can fulfil both of the preconditions – which – by the way – no other business application can fulfil.

I will explain more in other posts. I will then explain, why even today ByDesign is ahead of the competition with regards to process extensibility.

Posted in BPM | Comments Off

BPMN für die Abstimmung zwischen Fachseite und IT

Es werden hin- und wieder Zweifel laut, inwieweit BPMN für die Abstimmung zwischen Fachseite und IT wirklich geeignet ist, oder ob es von der IT Seite bevorzugt wird. Darauf möchte ich hier eine Antwort geben.

BPMN ist nur ein Standard für die Definition von Geschäftsprozessmodellen, nichts weiter.
Natürlich werden mit jedem neuen Standard oder mit jeder neuen Methode Hoffnungen verbunden und auch Enttäuschungen erlebt.
Hier hilft Nüchternheit.

Es ist ein Werkzeug, das für bestimmte Aufgabenstellungen nützlich sein kann und für andere Aufgabenstellungen ist es wiederum nicht nützlich. Liegt im Hammer die Zukunft? Oder doch eher in der Zange? Vielleicht in der Bohrmaschine? Für die richtige Aufgabenstellung ist jedes dieser Werkzeuge für sich nützlich. So ist es auch mit den Modellierungssprachen.
Ein Fehler sollte nicht gemacht werden: Aus einer falschen Anwendung einer Methode Rückschlüsse darauf ziehen, ob die Methode für bestimmte Aufgaben geeignet ist oder nicht. Die Methode, die man nicht falsch anwenden kann, die ist auch noch nicht erfunden worden. Zu der Nutzung einer Methode gehört darum auch immer das “Gewusst wie!”.
Zurück zur Ausgangsfrage bezüglich der Abstimmung von Fachseite mit der IT-Seite. Die Aufgabe des Modells dabei ist es Transparenz zu schaffen, die Qualität in einer frühen Phase zu sichern (und dadurch Geldverschwendung durch die IT-Umsetzung falscher Prozesse zu vermeiden), Integration zu schaffen, Struktur zu geben und letztendlich eine höhere Stufe der Flexibiltät zu erreichen (sprich es geht schneller, wenn ein Ablauf geändert werden muss als vorher ohne Modell).

Alles in ein Modell ist sicher falsch dabei. Ein Beispiel: Ein Modell sollte nicht wesentlich mehr als um die 7 Aktivitäten beinhalten. Warum das? Weil der menschliche Geist umgefähr 7 Dinge gleichzeitig erkennen kann. Übersteigt ein Modell die Anzahl dieser Modellierungselemente wesentlich, dann wird es als verwirrend und unübersichtlich wahrgenommen. Sie glauben das ist nicht möglich? Natürlich ist es möglich. Dazu muss das Modell nur entsprechend strukturiert werden. Dazu dienen zum Beispiel die Möglichkeiten der Sub-Prozesse in BPMN.
Zudem beleuchten verschiedene Modelltypen verschiedene Aspekte des gleichen Prozesses.
Nehmen Sie zum Beispiel das Konversationsmodell

Siehe dazu auch dieses Kurzvideo:

Hier kann man mit nur drei Modellierungselementen eine gute Übersicht über eine Prozesslandschaft erstellen und der ganzen Modell-Landschaft die richtige Struktur geben. Von dort aus ist es dann möglich in weitere Ebenen darunter zu drillen.

Ein weiterer Punkt ist, dass Fachseite und IT-Seite unterschiedliche Informationsbedürfnisse haben. Die Fachseite interessiert sich mehr dafür, welche Geschäftsdokumente (Auftrag, Lieferung, Rechnung, …) wann wie erzeugt und bearbeitet werden und wer dafür verantwortlich ist. Die IT-Seite interessiert sich mehr für die Strukturierung der Anwendungen (Schnittstellen) und für die Sonderfälle (Stornierung, Änderungen im laufenden Prozess). Natürlich muss auch die Fachseite diese Fragen nach den Sonderfällen im Prozess mit beantworten, nicht aber die Strukturierung der Anwendungen (Schnittstellen). Hier kommt es darauf an, verschiedene Modelle mit verschiedenen Details des gleichen Prozesses zu machen.

Sprich es ergibt sich eine Modell-Landschaft, die aber untereinander verbunden ist. Änderungen, die sich in einem Modell ergeben können – das richtige Tool vorausgesetzt – dann leicht in anderen Modellteilen nachvollzogen werden, da es für die entsprechenden Elemente (Geschäftsobjekte) Verwendungsnachweise gibt – also die Auskunft in welchem anderen Modell dieses Geschäftsobjekt – das jetzt geändert werden soll – ebenfalls vorhanden ist, und das damit ggf. ebenfalls angepasst werden muss. Diese Möglichkeiten wurden erst durch das BPMN Metamodell erschaffen.
Diese Änderungen wiederum sollten natürlich, vor allem wenn es eine größere Modell-Landschaft ist, einem Reviewprozess unterworfen sein. Gerade der ordentliche Reviewprozess wird oft gerne vernachlässigt. Man denkt: Naja – wir reden eben schnell einmal darüber oder wir machen einen Workshop. Da kommt es oft zu mehr Missverständnissen als Lösungen. Ein strukturierter Reviewprozess sorgt dafür, dass bei jeder relevanten Änderung, die Einfluss auf andere Bereiche hat, den entsprechenden Stakeholder eine Reviewphase zugebilligt wird, offene Punkte formuliert werden, und diese strukturiert abgearbeitet werden. Das ist in der Summe weniger aufwändig, als es “Auf Zuruf” zu machen, weil eben viele Missverständnisse vermieden und von Anfang an ausgeschlossen werden. Es gibt auch keine Modellierungsmethode der Welt, die einen solchen Prozess überflüssig macht, wenn die Aufgabenstellung eben entsprechend groß ist. Für kleinere Aufgaben kann der Reviewprozess natürlich schlanker sein – das ist klar.

Im Reviewprozess wird ein Leitfaden zugrunde gelegt. Dieser Leitfaden wird für ein spezifisches Projekt maßgeschneidert erstellt und legt die Regeln fest. Die Regeln besagen, welche Modellierungselemente für welche Ebene des Modells erlaubt sich und welche nicht. Das generell und allgemeingültig festzulegen ist nicht sinnvoll, da es immer vom Projekt abhängt und von der Aufgabenstellung, die das Projekt erfüllen muss. Natürlich gibt es einige Gemeinsamkeiten mit anderen Projekten. Jedenfalls ist der Leitfaden die wesentliche Grundlage dafür, welche Modellierungselemente zu Einsatz kommen. Das vom Standard zu erwarten heißt, den Standard zu überfordern. Der Standard hat schon einige solcher Regeln bereits festgelegt, aber eben genug Freiraum gelassen, damit sowohl die Bedürfnisse der Fachseiten als auch die der IT-Seiten berücksichtigt werden können.
Ob BPMN zu viele Modellierungselemente hat? Ich sage einmal so: 20% der Elemente werden in 80% der Fällen verwendet. Und das ist auch gut so. Ich halte einige der Elemente ebenfalls für überflüssig oder warne sogar vor deren Einsatz. Aber viele sind auch gut, und gerade mit BPMN 2.0 sind wieder sehr gute neue Modellierungsmöglichkeiten dazu gekommen, die beispielsweise viel Transparenz in B2B Prozesse bringen können.  Was auch wichtig ist: Die Fachseite vesteht konkrete Modellierungselemente viel besser als abstrakte. Konkret ist beispielsweise: Datenobjekte (Geschäftsobjekt wie Rechnung, Bestelltung, Lieferung, …), der Status eines Datennobjektes (Offen, Erledigt, In Bearbeitung, Genehmigt, Bezahlt, …) die Aktivität (wie Freigeben, Genehmigen, …) als auch eine Rolle (Einkäufer, Gruppenleiter, …). Ich hatte noch nie und bei niemandem Probleme mit der intuitiven Verständlichkeit eines solche Modells. Intuitiv heißt hier: Ohne Schulung. Schlechter verstanden werden dagegen abstrakte Modellierungselemente wie Gateways, Events, etc. pp.  Ungefähr in der Mitte sind Nachrichten und Nachrichtenflüsse. Es ist die Aufgabe des Leitfadens, den Einsatz der Modellierungselemente dahingehend zu regeln.

Man darf nicht die Leistung, die man eigentlich von einem ordentlichen Reviewprozess erwarten muss, von der Methode erwarten.
Ist BPMN die Zukunft? Ich sage: Es ist im Moment sehr nützlich, wenn es richtig – also für den richtigen Zweck und auf die richtige Weise – eingesetzt wird. Und dazu gehört definitiv die Abstimmung zwischen Fachseite und IT.

Posted in BPM | Comments Off

Digging deeper into the current school of BPMN modeling versus adaptive modeling style

I want to go a little bit deeper into discussing problems with the current school of process modeling (focus on BPMN and BPMN styles) based on publications.

If we take for example (Allweyer, 2009) chapter 2 we find a first simple BPMN model in figure 1 (translated by me). There is a remarkable statement about this model.

In practice the process of creation and publication of a job post can be much more complex and considerably larger. This model is a strong simplification – as all models in this book are. The purpose is to have clearly arranged models in order to be able to well explain the BPMN modeling elements. (Allweyer, 2009) – Translation by me.

What can we conclude from this? Can we conclude that if BPMN models reflect the full lifecycle and variants of a real job post creation and publication the models are too big and complex to be arranged clearly?

Well – I know the difference between a real modeling project and a didactical book chapter or training. I am giving training myself and therefore simplification for didactical reasons has my full sympathy.

But still it is a remarkable statement, if we think about it for a moment.

Adaptive Process Modeling would state it differently. Adaptive Process modeling would say:

What are the real requirements of the full lifecycle of the creation and publication of a job post including all variants and complexities? How can this be modeled in a simple, concise way? How can the resulting model be free of unnecessary repetitions? How can the model be easy to maintain? Which of the BPMN modeling elements can or must we use for that purpose (and which do we not use)? How do we combine these elements, which rules (or style) govern the composition of these elements to models that fulfill these criteria?

It is a different question and a different approach. Just to make one example: An adaptive process model would always contain data objects (without or with state). Why is this so important? I leave the answer to this question to another post. An adaptive model tries to avoid all the problems that come with tokens and gateways. Tokens and gateways are extensively discussed in chapter 2 and 3 of (Allweyer, 2009). You can see there what happens if a two start tokens are created and run through the process, how tokens are duplicated by gateways, how they circle around in loops and make the whole model very difficult.

The basic flaw of most process models is this: There are two ways of capturing process state:

  1. Tokens running through a process.
  2. The state of data objects that are used in or are part of the process

Alternative 2) is by far the better way of capturing process state. It is more natural to say the job posting is approved, than to have an artificial invisible token in a sequence flow line after an activity “approve job posting”. It makes models much simpler, cleaner and concise. Why is this? Because the result of a task is much more important that the task itself. This gives much more flexibility to a process. Why? Because there can be many ways to achieve the same result, and many ways to use the result (the approved job posting for example). In token flow, all of these variants have to be combined into chains and this makes a model complex. Modeling the data object and it`s state is a natural way to decouple parts of a process and adding a point of flexibility.

Notwithstanding 95% of the models I see try to solve their problems with method 1). Why is this so? I do not know. Probably data objects and their state are not considered as part of the process. This is a great error. Actually we need to establish an understanding in which data objects and their states are completely part of the process just as activities are.

And this leads us into the direction of Adaptive Case Management as well. Because Adaptive Case Management is said to be a goal oriented way of modeling instead of a task oriented way of modeling. So the result counts more that the tasks, that lead to the result. The goal in ACM is to achieve a certain result. Just as with data objects and their state. We can say goal oriented modeling, result oriented modeling or data object state oriented modeling. In the end it is very similar.

I teach these principles in (Kraft, 2011).

References

Allweyer, T. (2009). BPMN 2.0 – Business Process Model and Notation: Einführung in den Standard für die Geschäftsprozessmodellierung. Books on Demand.

Kraft, F. M. (2011). Training: BPMN 2.0 smart anwenden. Retrieved from http://www.adapro.eu/site/seminar/sem-bpmn

Posted in BPM | Comments Off