Unser Ansatz wie wir Geschäftsfälle definieren, verarbeiten und dokumentieren:
Um die bekannten Probleme der ERP-Systeme zu umgehen, benötigen wir einen neuen Ansatz, wie Geschäftsfälle beschrieben, verarbeitet und dokumentiert werden. Ansonsten landen wir zwangsläufig wieder dort, wo die heutigen Systeme stehen. Unsere Erkenntnis ist, dass die Probleme der heutigen ERP-Systeme unumgänglich sind, da sie Architektur bedingt sind.
Die folgenden Beiträge veranschaulichen, wie wir mit enablerr einen komplett neuen Ansatz in betriebswirtschaftlicher Software realisieren. Damit nach den Menschen und Organisationen auch Business Software agiles Verhalten erfolgreich nutzen kann.
In dieser Mini-Serie beschreiben wir die folgenden drei Themen, die zum Kern unserer innovativen Lösung gehören:
Teil 1: «Asset-Purpose-Model» – autonome Ereignisse, anstelle von starren Prozessketten
Teil 2: «Ereignisklassen» – Trennung von Business-Logik und Regulation
Teil 3: «Plug-ins» – Basis unserer No-Code Business Solution
Autonome Ereignisse: Das Asset-Purpose-Model
Michael E. Porter hat 1985 das Prinzip der Wertschöpfungskette (Value Chain) so beschrieben:
Jedes Unternehmen ist eine Ansammlung von Tätigkeiten, durch die sein Produkt entworfen, hergestellt, vertrieben, ausgeliefert und unterstützt wird. All diese Tätigkeiten lassen sich in einer Wertkette darstellen.
Michael E. Porter
Bei pier4all verwenden wir Porters Definition und unterteilen die Prozesskette zusätzlich in den Produkt- (analog, digital, Ware), Informations-, und den Entgelt-Fluss. Das ist die eine Voraussetzung um autonome Ereignisse zu realisieren und sehr flexibel Statusinformationen und Auswertungen zu generieren.
Die zweite Voraussetzung besteht darin zu wissen, in welchem Zustand sich ein Ereignis befindet, damit wir ese automatisch verarbeiten können. Das System muss erkennen «wo» das Ereignis in seiner Verarbeitung steht und «was» mit ihm geschehen soll, damit es zu einem Abschluss kommen kann. Deshalb erweitern wir das Model um die Bereiche «Asset» und «Purpose»:
Das kann wie folgt umschrieben werden: Wenn eine Ware zum Unternehmen hinbewegt wird («Einkauf») oder ein Entgelt das Unternehmen verlässt («Lieferantenzahlung»), sprechen wir von Asset. Wenn eine Ware das Unternehmen verlässt («Verkauf») oder ein Entgelt zum Unternehmen hinbewegt wird («Kundenzahlung»), sprechen wir von Purpose.
Damit schaffen wir zwei Kreise, die natürlicherweise die Kosten- und Umsatztreiber beinhalten. Es gibt eine fixe Anzahl möglicher Zustände, die ein Ereignis einnehmen kann.
Das führt uns zu unserem generischen Asset-Purpose-Model:
Von starren Prozessketten zu dynamischen Workflows
Das System kennt also den Zustand eines jeden Ereignisses und ist somit in der Lage, einen Abschluss zu forcieren, bzw. es weiss, wann etwas initialisiert oder eskaliert werden muss.
Jedes Element der Wertschöpfungskette, egal ob es sich um Produkt, Information oder Entgelt handelt, wird im jeweiligen Kontext (Einkauf, Produktion, Verkauf, etc.) in einem einzelnen Ereignis abgebildet. Diese Ereignisse werden nicht fix verdrahtet, sondern erhalten Eigenschaften, welche es ihnen erlaubt, sich dynamisch zu verketten:
- einen Auslöser, welcher eine zeitliche und/oder situative (aufgrund eines anderen Ereignisses) Komponente beinhalten kann;
- ein Input, der bestimmt, welche Informationen aus einen vorausgegangenen Ereignis übernommen werden;
- eine Selektion, welche aufgrund der Merkmale (Asset/Purpose, Produkt/Information/Entgelt) und weiterer Eigenschaften vergangener Ereignisse als Quelle nutzen kann.
Aus diesem Grund kann enablerr ohne starre Prozessketten arbeiten und agiles Arbeiten mit der Business Solution erst ermöglichen. Das führt zu einem Pool von Ereignissen, die sich autonom und situativ verketten:
Ereignisse können wir uns wie in David Allens Buch «Wie ich die Dinge geregelt kriege» beschriebene Aufgaben vorstellen. Es sind Elemente die in sich geschlossen verarbeitet werden können. So zum Beispiel:
- Auftrag erfassen
- Projekt anlegen
- Offerte erstellen
- Zeit erfassen
- Rechnung auslösen
- Lohnzahlung auslösen
Im nächsten Teil geben wir Einblick in die von uns verwendeten «Ereignisklassen».