Business Process Framework

Moin moin und hallo,

in diesem Artikel möchte ich eine meiner Ideen für die Digitalisierung von Geschäftsprozessen vorstellen.

Ausgangssituation

Das Thema “Digitalisierung” beschäftigt auch weiterhin sehr viele Firmen, doch wo und wie setzt man an?

Ein Ansatz, auf den ich immer wieder gestoßen bin ist der, von mir jetzt so genannte, “Monolith”.

Monolithen kennen wir in der Software Entwicklung als diese großen und aufgeblasenen Software-Anwendungen, die in der Regel nur als Ganzes oder gar nicht genutzt werden können.

Auf Geschäftsprozesse bezogen, meine ich damit große und schwergewichtige Sofwtare-Produkte, die versuchen möglichst viele Bereiche einer Unternehmung an zu fassen und mit vielen eigenen Prozess-Definitionen zu unterstützen.

Das Problem dabei ist, dass man seine eigenen Geschäftsprozesse der Software angeleichen muss, da man diese sonst nicht effektiv nutzen kann.

Für sehr große Firmen stellt dies sicher weniger ein Problem dar, da man sich häufig der Software (wie z.B. SAP) adaptiert und dann mehr nicht so schnell ändert.

Kleinere Unternehmungen sing eher agil und haben den Vorteil, dass sie sich viel und schnell an neue Begebenheiten umstellen können. Prozess-Definitonen sind für diese kein Thema.

Meine Idee betrifft also vor allem den Mittelstand. Hier haben sich gewisse Prozessstrukturen, selbst wenn diese formal noch nicht Definiert wurden sind, eingespielt.

Wenn das Geschäft an Volumen anzieht, ist es nicht immer einfach mit der internen Struktur mit zu ziehen.

Personal-Fluktuationen sind dann häufig die Folge, und damit verschwindet dann auch Fach- sowie Hintergrundwissen zu Abläufen udn Strukturen.

Um aber mit dem Volumen mit zu halten und weiter zu wachsen muss man diese Barriere durch brechen.

Eine Lösung dafür ist die Digitalisierung bzw. Automatiersierung von Prozessen.

Dafurch hält man das Fachwissen in der Unternehmung und der Eingriff durch Menschen wird auf ein Minimum reduziert, wo es sinnvoll und unvermeidlich ist.

Eine Folge ist außerdem dass man weiter Kosten einsparen und einfacher Skallieren kann.

Lösungsansatz

Mein Geschäftsprozess-Framework setzt genau hier ein.

Ich möchte weg vom Monolithen, hin zu kleineren spezialisierten Software-Komponenten, die entweder selbst mit Masken (Progressiv Web Apps) für manuelle Eingriffe ausgestattet sind, für die Integration bestehender Software-Anwendungen genutzt werden.

Alles diese Komponenten werden dann von einem übergeordneten Framework zusammen gehalten.

Am besten versteht man das Ganze wenn wir es Schritt für Schritt anhand eines Beispiels durch gehen.

1. Prozessdefintion mit Hilfe von BPMN

Im aller ersten Schritt der Software-Erstellung muss man sich die Zeit nehmen und zunächst den aktuellen Prozess formal definieren.

Das fehlt ganz häufig in den Unternehmen. Die Definition muss immer mit dem Kunden zusammen getroffen werden und sollte nicht jetzt schon ins Klein-Klein gehen.

In dem vorliegenden BPMN sehen Sie einen einfachen Prozess eines E-Commerce-Shops abgebildet.

Wie man sehen kann beginnt der Prozess mit dem Eingang einer Bestellung, geht dann über zu der Verarbeitung der Bestellung und endet schließlich mit dem Versand der Ware.

Die Definition kann als “weich” betrachtet werden, d.h. es ist jeder Zeit möglich Schritte wieder zu entfernen oder neue hinzu zufügen.

Die Strukturen sollen sich der Unternehmung anpassen und nicht umgekehrt.

2. Identifikation von digitalem Potential

Bevor man sich auf eine Software stürzt, die möglichst den vollständigen Prozess mit ihren Features erschlägt, sollte man sich noch einmal zurücklehenen und erstmal schauen wo es überhaupt sinnvoll ist und wo man nur untersütztend eine kleinere App liefern kann.

Wir wissen, dass die eingegangene Bestellung in jedem Fall über einen Online-Shop herein kommt, d.h. wir haben die Daten in jedem Fall zu Beginn beriets in digitaler Form vorliegen. Dann würde das Framework automatisch einen neuen Vorgang zu dem beschriebenen Prozess anlegen und die weitere Verfolgung übernehmen.

Für den fiktiven Fall, dass wir mal eine Bestellung per z.B. E-Mail zulassen würden, müssten wir dann einen Zwischenschritt einfügen, bei dem ein Mitarbeiter diese digital erfassen würde.

Auf den ersten Blick sehe ich nur folgende zwingend manuell durch zuführende Schritte:

1. Ware heraussuchen
2. Ware verpacken
3. Packet vervollständigen

Das heißt hier können wir maximal unterstützend wirken und z.B mit Hilfe einer App dem Mitarbeiter zum Lagerplatz lotsen.

Alle anderne Schritte lassen sich zum Teil sogar automatisieren.

Ich greife hier mal den Zweig zu “Ware beim Lieferanten bestellen” auf.

Diese Aufgabe würde automatisch vom Framework ausgelöst, sobald der Dienst von “Prüfen von einzelnen Positionen ob Ware vorhanden ist”, sein Ergebnis “nein” zurückmeldet. Denn die erste Aufgabe in dem Prozess eignet sich hervorragend dazu volltändig über einen MicroService ab gebildet zu werden.

Das Framework ruft den Dienst auf, sobald der Prozessschritt erreicht wird.

Als nächstes stellen wir also fest, dass wir ein Produkt nicht mehr vorrätig haben und das Framework ruft den nächsten Schritt “Ware beim Lieferanten nachbestellen” auf.

Diese Aufgabe kann teil-automatisiert werden, denn am Ende soll immer noch ein Mitarbeiter verbindlich entscheiden ob der Lieferant der Richtige ist.

Jede Tätigkeits-Kette, die sich nicht automatisieren lässt, muss mit spätestens beim letzten Schritt der Kette mit einer Maske unterstützt werden.

Denn dann muss, in der Regel, ein Mitarbeiter einen Vorgang bestätigen oder an den gegebenen Daten etwas verändern, Informationen aus Drittsystemen beziehen oder ähnliches.

Sobald also das System einen Lieferanten raus gesucht hat, hat der Mitarbeiter noch die Möglichkeit einen anderen ( in z.B. einem angebundenen ERP) zu finden und muss am Ende die Bestellung manuell bestätigen.

Damit schließt die Prozesskette in diesem Zweig.

Schauen wir uns doch mal den anderen Zweig an.

Nachdem im aller ersten Schritt festgestellt wurde dass man alle Waren aus der Bestellung noch vorrätig hat, teilt sich der Fluss in den manuellen Schritt oben und einen automatisierten Schritt unten auf.

Die Rechnung kann vollständig automatisch vom einem Dienst erstellt und in Folge an den Kunden, z.B. per E-Mail versandt werden.

Das heraussuchen und verpacken der Ware muss weiterhin von einem Menschen erledigt werden. Der jeweilige Mitarbeiter muss dann nur in der Framework-App den erfolreichen Abschluss, d.h. fertig gepackte Paket bestätigen und es an den Fahrer übergeben.

Damit endet dieser Prozess.

3. Zusammenfassung

Durch die Analyse können wir folgende, mögliche Software-Optimierungen feststellen:

1. MicroService zum heraus finden und überprüfen von Warenbeständen
2. Eine Progressive Web App zum heraussuchen von Lieferanten, aufgeben von Nachbestellungen, und Kunden über Verzögerung informiert
3. Ein MicroService der Rechnungen erstellt und an Kunden versendet
4. Eine Progressive Web App, die das fertige Paket quitiert und ggfs. weitere Prozesse in externen System auslöst

Jede dieser Komponenten muss über einen Auslöser(Vorgangsdaten werden mit übergeben) verfügen und bei Fertigstellung der Aufgabe den Vorgang wieder an das Framework übergeben.

Software Komponenten

Alle gefundenen Applikationen werden von unserem Framework aggregiert, d.h. es gibt nach Außen hin nur ein Backend bzw. Framework-App.

Im Backend hat der Manager dann auch die Möglichkeit in den lauffenden Betrieb hinein zu gucken und Flaschenhälse zu identifizieren, die bisher als solche nicht klar waren.

Für Endkunden gäbe es die Möglichkeit z.B. direkt zu sehen wie Status seiner Bestellung ist. Diese Transparenz weckt mit Sicherheit Vertrauen und bindet vielleicht den Kunden auch für längere Zeit.

Der Prozess muss zu jeder Zeit geändert oder erweitert werden können, ohne das der lauffende Betrieb gestört wird.

Technische Anforderungen an das Framework

Jeder Dienst und App arbeitet autark, zustandslos und nur mit den Daten, die im Vorgang selbst gehalten werden.

Dadurch stellen wir sicher, dass jeder einzelne Prozessschritt aus unserer Kette herausnehmen können ohne den Rest zu gefährden. Genauso einfach gestaltet sich dann die Erweiterung um weitere Schritte. Man fügt einen neuen Schritt hinzu und entwickelt die jeweilige Software-Komponente.

Wenn die Software dann soweit ist, aktiviert man den Prozess und für die Mitarbeiter ergibt sich in der Framework App eine neue Maske oder in Folge seiner Tätigkeit werden weitere Prozesse aus gelöst, in jedem Fall geschieht dies ohne großen Aufwand oder der Notwendigkeit neue Werkzeuge zu installieren. oder zu aktualisieren.

Fazit

Die oben Idee ist vielleicht in einigen Einzelteilen nicht gänzlich neu, aber so ausformuliert und in ein einheitliches Konzept gebracht habe ich es noch nirgens finden können.

Dadurch das man von der Prozessseite heran geht und nicht wie sonst üblich in “Features” denkt, ergeben sich, meiner Meinung nach, häufig viele neue Potentiale, die man vorher nicht gesehen hat.

Was uns die Erfahrung in der Wirtschaft gezeigt hat ist doch, dass es nicht die silbernen Kugeln unter den Monolithen gibt. Entweder man kauft sich eine große Standard-Software und passt sich deren Prozessen an, oder lässt sich einen teuren, individuellen Monolithen entwickeln, der nur auf einen selbst passt.

Das Framework sieht aber eben nicht eine große Software, sondern viele kleine vor. Das gibt uns die Chance auch Komponenten wieder zu verwenden. Es wird viele Schritte geben, die Branchen weit als auch womöglich übergreifend gleich sind. Das heißt langfristig gewinnt man mit dem Framework deutlich an Performance und gibt den Kunden zugleich die Möglichkeit Schritte neu an zu ordnen oder gänzlich um zu werfen.

Man könnte jetzt annehmen das das Framework dann irgendwann zum Monolithen wird. Dem ist aber meiner Meinung nicht so. Denn das Einzige was es tut, ist Prozess-Definitionen aus zu führen und dazu gehörige Software-Komponenten zu verbinden. Es kümmert sich nicht darum wer, wo, welche Komponente betreibt, oder mit welche Programmiersprache es geschrieben ist. Jede Komponente muss nur die Schnittstelle zu dem Framework, zum Erhalt von aktuellen Vorgangsdaten und zum benachrichtigen über die Fertigstellung einer Aufgabe, implementieren.