kiwiw: BPM und Case Management gehen auch ganz einfach

Herkömmliche Business Process Management-Systeme (BPMS) sind insbesondere für stark standardisierte Prozesse geeignet, die sehr oft wiederholt werden. Problematisch wird es, wenn es sehr viele unterschiedliche Varianten gibt, und wenn die Mitarbeiter die Prozesse erst während der Durchführung situationsbezogen variieren. Aus diesem Grund entstanden in jüngerer Zeit Systeme für das Adaptive Case Management (ACM), bei denen im Gegensatz zu herkömmlichen BPMS nicht der modellierte Ablauf im Vordergrund steht, sondern die zu einem Fall gehörenden Daten und Informationen.

Der Bearbeiter kann über die durchzuführenden Schritte weitgehend frei entscheiden, ggf. eingeschränkt durch gewisse Geschäftsregeln oder gesteuert durch kleinere Prozessfragmente für strukturiertere Arbeitsanteile. Bislang haben sich ACM-Systeme noch nicht auf breiter Front durchgesetzt. Mit ein Grund dafür könnte die Komplexität sein, die die Verbindung der zumeist einzeln vorliegenden Komponenten erfordert, wie z. B. ACM-System, Process Engine, Rules Engine und Dokumentenmanagementsystem. Eine komplette Prozessanwendung benötigt darüber hinaus noch die Anbindung von Fachanwendungen, Datenbanken usw.

Kein Unterschied zwischen Prozess und Fall

Sehr spannend ist vor diesem Hintergrund der Ansatz des kürzlich vorgestellten Systems „kiwiw“. In diesem System werden Prozesse, Fälle, Regeln, Dokumente, Geschäftsobjekte usw. nicht von mehr oder weniger gut miteinander gekoppelten Einzelkomponenten verwaltet. Stattdessen sind sie in einem umfassenden Ansatz nahtlos integriert. So gibt es beispielsweise architektonisch kaum einen Unterschied zwischen einem stark strukturierten „Prozess“ und einem weitgehend frei gestaltbaren „Fall“. Beide bestehen aus Aktivitäten, zwischen denen es Abhängigkeiten in Form von Regeln gibt. Die Regeln des stark strukturierten Prozesses erlauben bei den meisten Aktivitäten vielleicht nur genau eine Folgeaktivität, wohingegen es bei der freieren Fallbearbeitung vielleicht einige empfohlene, viele mögliche und nur wenig verbotene Folgeaktivitäten gibt – und bei Bedarf noch ad-hoc ganz andere Aktivitäten durchgeführt werden können.

Die Regeln beziehen sich dabei auf die jeweils aktuellen Zustände, wobei es nicht einen einzigen Vorgangszustand gibt, sondern ggf. eine ganze Reihe von Zuständen. So kann es in einem Vorgang mehrere Dokumente und Geschäftsobjekte geben, die jeweils ihre eigenen Zustände haben. Der Bearbeiter entscheidet – außer bei automatischen Aktionen – jeweils, welche Aktion er durchführt. Hierbei sorgen definierte Setz-Regeln dafür, dass die mit dem Vorgang verbundenen Zustände anschließend geändert werden. Aus den neuen Zuständen bestimmt das System wieder, welche nächsten Schritte möglich und empfohlen sind.

Aktionen, Zustände und Regeln statt Prozessmodellen

Betrachtet man beispielsweise einen Vertriebsprozess, dann gibt es nicht nur den typischen Ausführungspfad mit wenigen Abweichungen. Stattdessen gibt es fast unendlich viele Kombinationsmöglichkeiten verschiedenster Aktivitäten, wie z. B. Angebotsänderungen, Letters of Intent, Kundenbesuche, Pilotinstallationen usw. Diese Variantenvielfalt in einem ablauforientierten Prozessmodell abzubilden ist nicht möglich. Würde man versuchen, den Vertriebsprozess mit einem herkömmlichen BPMS abzubilden, dann würden sich die Vertriebsmitarbeiter durch die zwangsläufig recht starre Ablaufdefinition zu Recht gegängelt fühlen. Verzichtet man andererseits auf eine systemgestützte Abwicklung des Vertriebsprozesses, wie dies ja herkömmlich der Fall ist, müssen die Mitarbeiter ihre Informationen meist aus verschiedenen Anwendungen heraussuchen, und es ist nicht sichergestellt, dass wichtige Regeln eingehalten werden.

Für die Entwicklung einer Anwendung auf Basis von kiwiw kommen daher auch keine Prozessmodelle zum Einsatz. Stattdessen definiert man im System die einzelnen Aktivitätstypen, die möglichen Zustände, die Regeln zum Setzen der Zustände, die Bedingungen zur Auswahl von Aktivitäten, und die zur Verfügung stehenden Ad-hoc-Möglichkeiten. Dies mag am Anfang vielleicht etwas kompliziert klingen, erweist sich in der Praxis aber als unproblematisch. Für Vertreter der Fachabteilung ist es recht einfach, im Dialog Fragen zu beantworten, wie „Was kann man noch machen?“, „Welche Voraussetzungen müssen dafür erfüllt werden?“, usw. Da die Erfassung direkt am System erfolgt, kann die Anwendung sofort ausprobiert und iterativ weiterentwickelt werden.

Entwicklung einer Anwendung in zwei Tagen

Beispielsweise hat die Firma kiwiw die komplette Anwendung zur Unterstützung ihres eigenen Vertriebs- und Projektabwicklungsprozesses in insgesamt 18 Stunden erstellt – vom Entwurf bis zur Produktivsetzung. Hierbei musste keine einzige Zeile Code erstellt werden. Die erstellte Anwendung enthält insgesamt 19 Aktivitätstypen mit 98 Datenfeldern. Theoretisch sind darin über 10 Milliarden verschiedene Ablauf-Varianten möglich, die alle regelkonform sind.

Selbstverständlich wird zur Erfüllung von Compliance-Anforderungen eine komplette Fallhistorie erstellt. Dokumentenmanagement und grundlegende CRM-Funktionalitäten sind im Standardsystem bereits enthalten. Daneben gibt es einige fertige Fachapplikationen auf kiwiw-Basis, die direkt verwendet und leicht an individuelle Anforderungen angepasst werden können. Weitere Fachapplikationen werden in Zusammenarbeit mit Kunden entwickelt. Als typische Einsatzbereiche des Systems werden z. B. Anforderungs- und Angebotsmanagement, Auftragsabwicklung, Technischer Support, Projektabwicklung und das Qualitätsmanagement genannt.

Die Software kann von den Kunden sowohl selbst betrieben als auch in Form einer Cloud-Lösung genutzt werden. Der Einstiegspreis beginnt bei 25 Euro pro User und Monat. Damit wird ein kostengünstiger Einstieg ermöglicht, zumal eine umfassende Pilotanwendung in ein bis zwei Tagen erstellt werden kann.