In meinen Projekten bzw. Trainings werde ich immer wieder von meinen Kunden gefragt, worin denn genau die Unterschiede in den Methoden, Techniken oder dem Vorgehen zwischen einer reinen System- und einer Geschäftsprozessanalyse bestehen. Diese Frage ist eigentlich ziemlich schnell und einfach zu beantworten: die Unterschiede in der Dokumentation (das Vorgehen unterscheidet sich stark) sind nur marginal, denn im Prinzip ist nur der Betrachtungsgegenstand (z.B. ein System gegenüber einer Abteilung) ein anderer.
Diese Verwirrung kann man jedoch leicht erklären: Die einschlägige Literatur zu den Themen „Geschäftsprozessanalyse“ und „Systemanalyse“ verwendet meist für einen im Grunde gleichen Sachverhalt/Artefakt/Element zwei unterschiedliche Begriffe. Ein einfaches Beispiel für diese Behauptung sind die Begriffe „Business Rule“ und „Anforderung“, die ich Ihnen innerhalb dieses Blog-Beitrags genauer vorstellen will, in dem ich Ihnen die Unterschiede bzw. Gemeinsamkeiten aufzeige.
Vergleicht man diese Definitionen, so kann man auf den ersten Blick nicht erkennen, dass sie etwas Ähnliches beschreiben. Man könnte lediglich mutmaßen, dass „Statement“ evtl. mit „zu erfüllende Eigenschaft oder zu erbringende Leistung“ übereinstimmen, aber genau wissen wir das nicht.
Also müssen wir noch etwas tiefer graben! Dazu habe ich noch weitere Definitionen im Angebot.
Definition „Operative Geschäftsregel“ nach [SBVR05]:
„Eine Geschäftsregel, welche die Durchführung von Geschäftsaktivitäten reguliert. Eine Geschäftsregel sollte immer wahr sein und formuliert eine Verpflichtung. Für die Situation, dass die Verpflichtung falsch ist, können Konsequenzen definiert werden.“
Definition „Funktionale Anforderung“ nach [IREB07]:
„Eine funktionale Anforderung definiert eine vom System oder von einer Systemkomponente bereitzustellende Funktion bzw. Service.“
Aha, schon besser: zum Einen regulieren wir also die Durchführung von Geschäftsaktivitäten durch eine Verpflichtung, zum Anderen definieren wir eine bereitzustellende Funktion. Doch was hat das für Folgen?
Der detaillierte Vergleich
Um nicht ständig über abstrakte Definitionen zu diskutieren, wollen wir uns das an einem einfachen Beispiel verdeutlichen. Dazu lassen wir einmal die semantische Definition unserer Begriffe und Prozesswörter außer Acht.
Business Rule (Verpflichtung):
„Nachdem der <Akteur> einen Auftrag erstellt hat und falls der Auftrag OK ist, muss der <Akteur> den Auftrag abwickeln.“
Business Rule (Konsequenz):
„Nachdem der <Akteur> einen Auftrag erstellt hat und falls der Auftrag nicht OK ist, muss der <Akteur> den Auftrag ablehnen.“
Wenn wir jetzt diese Regel als funktionale Anforderungen an ein System formulieren würden, so bekämen wir:
Anforderungen 1:
„Nachdem das System einen Auftrag erstellt hat und falls der Auftrag OK ist, muss das System dem <Akteur> die Möglichkeit bieten, den Auftrag abzuwickeln.“
Anforderungen 2:
„Nachdem das System einen Auftrag erstellt hat und falls der Auftrag nicht OK ist, muss das System dem <Akteur> die Möglichkeit bieten, den Auftrag abzulehnen.“
Ich hoffe Sie stimmen mir zu, dass diese Umformulierung eigentlich nicht schwer war, da ich die beiden Sätze mehr oder weniger kopiert habe. Dennoch zeigt dieses einfache Beispiel sehr gut, dass operative Geschäftsregeln eigentlich funktionale Anforderung an das System „Geschäftsprozess XY“ sind. Dementsprechend könnte man sogar noch einen Schritt weiter gehen und auch Geschäftsregeln nach unserem Requirements-Template [Rupp07] formulieren:
„Nachdem der <Akteur> einen Auftrag erstellt hat und falls der Auftrag OK ist, muss der Geschäftsprozess XY dem <Akteur> die Möglichkeit bieten, den Auftrag abzulehnen.“
Ich gebe allerdings zu, dass durch den Ausdruck „die Möglichkeit bieten“ die Verpflichtung nicht ganz deutlich wird. Aber vielleicht haben Sie dafür eine Lösung?
Literatur
[BRG08]:
Business Rules Group, http://www.businessrulesgroup.org
[IREB07]:
International Requirements Engineering Board, http://certified-re.de/de/services/glossar
[Rupp07]:
Rupp, C. & SOPHIST Group: Requirements-Engineering und Management. München, Wien, Hanser 2007. ISBN 3-446-40509-7
[SBVR05]:
SBVR Excerpt. The Key Notions of the SBVR Approach. In: Business Rules Journal, Vol. 6, No. 12, Dec. 2005. URL: http://www.BRCommunity.com/a2005/b263.html