Ihr Backoffice, Ihre Wahl

Im Lauf der Jahre ist immer mehr davon, wie eine Organisation arbeitet, in ihren Systemen gelandet. Ein Prozess wurde zu einem Workflow im ERP. Eine Verantwortung wurde zu einem Berechtigungsprofil. Eine Geschäftsregel wurde zu Konfiguration oder zu individuellem Code. Eine Zusammenarbeit zwischen Abteilungen wurde zu einer Kette von Status und Schnittstellen.

Solange die Arbeit gleich bleibt, fällt das niemandem auf. Sie merken es, wenn Sie etwas ändern wollen. Eine neue Dienstleistung, ein Partner, mit dem Sie zusammenarbeiten möchten, eine andere Art zu planen: Plötzlich muss sich nicht nur die Organisation ändern, sondern auch das CRM, das ERP, die Schnittstellen und die Integrationen. Selbst wenn alle wissen, was anders werden muss, kann es Monate dauern, bis die Software folgt.

Wir haben Software gewählt, um die Organisation zu unterstützen, und am Ende die Organisation an die Software angepasst.

Das heißt nicht, dass Ihre Systeme weg müssen. Ein ERP ist hervorragend bei Finanztransaktionen. Ein CRM verwaltet Kundendaten. Ein Planungssystem berechnet Kapazität, ein Archiv bewahrt Dokumente auf. All das neu zu bauen wäre sinnlos, und teuer.

Was sich ändert, ist der Platz, den diese Systeme einnehmen. Sie sind nicht länger der Ort, an dem über Ihre Arbeitsweise entschieden wird, sondern werden zu dem, was sie gut können: Lieferanten von Daten und Diensten.

Die neue Dienstleistung, die Arbeit mit einem Partner, der Prozess, der sich ständig ändert: Das bauen Sie in CaseFlows, als Schicht über dem, was Sie haben. Der Caseflow beschreibt, wie die Arbeit abläuft, wer was tut und was jede Rolle sieht. Die Daten und Dienste, die er braucht, kommen aus den Systemen, die Sie bereits haben. Menschen und KI nutzen dieselben Dienste, innerhalb der Verantwortlichkeiten und Berechtigungen, die der Caseflow festlegt.

Der Caseflow organisiert die Arbeit. Das Backoffice unterstützt sie. Nicht umgekehrt.

Die naheliegende Alternative ist, zu bleiben, wo Sie sind: einen weiteren Workflow im ERP konfigurieren, ein Workflow-Tool daneben stellen oder von KI eine individuelle Anwendung für den neuen Prozess bauen lassen. Jede dieser Möglichkeiten kann funktionieren, und mit jeder ist der Anfang schneller gemacht.

Aber jede legt Ihre Arbeitsweise wieder in einer Anwendung fest. Die nächste Änderung stößt auf dieselbe Wand: Jemand muss herausfinden, wo die Regel steckt, sie dort ändern und testen, was sie berührt hat. Mit von KI gebautem individuellem Code geht das schneller, aber die Arbeitsweise landet in Code, den niemand liest, bevor er läuft.

In CaseFlows steht die Arbeitsweise in einer Spezifikation, die Ihnen gehört und die Sie lesen können und die die Runtime so ausführt, wie sie geschrieben ist; Ihre Systeme machen weiter, was sie gut können. Der Unterschied zeigt sich bei der zweiten und dritten Änderung, nicht bei der ersten.

Wir haben noch keine Zahlen, die zeigen, was das im Vergleich zum Erweitern einspart; genau das sollen die ersten Pilotprojekte messen.

Der Caseflow spricht nicht direkt mit Ihrem CRM. Er arbeitet mit eigenen Konzepten: einem Kunden, einer Verkaufschance, einem Angebot, jeweils mit fester Bedeutung. Und er fragt Dienste an: diesen Kunden nachschlagen, die Stunden zu diesem Projekt liefern.

Zwischen diesen und Ihren Systemen sitzt pro System ein Konnektor. Er übersetzt, wie das System die Dinge nennt, in die Konzepte, mit denen der Caseflow arbeitet. Aus dem Angebot in Gripp wird eine Verkaufschance mit einer Phase; ein anderes CRM bekäme einen eigenen Konnektor in dieselbe Verkaufschance.

Diese mittlere Schicht macht den Rest möglich. Der Prozess hängt von der Bedeutung eines Kunden ab, nicht von den Bildschirmen und Feldern eines bestimmten Produkts.

Zwei Systeme, die beide meinen, den Kundendatensatz zu besitzen: So gehen Integrationen schief. Deshalb legen Sie, bevor etwas gebaut wird, pro Konzept fest, welches System die Quelle ist.

In der Regel bleibt das Backoffice die Quelle dort, wo es am stärksten ist und wo Regeln gelten, etwa bei der Buchhaltung. CaseFlows hält die operative Arbeit fest: den Case, wer was getan hat und warum. Wo sich beide überschneiden, etwa bei einem Kunden oder einem Mitarbeiter, vereinbaren Sie, welche Seite führt, und der Konnektor hält die folgende Seite aktuell.

Romion Health führt seine Angebote, Projekte und Stunden in Gripp und seine Buchhaltung in Moneybird. Beide sind geblieben. Darüber läuft in CaseFlows die Vertriebsarbeit:

1. Eine Verkaufschance wird in Gripp erfasst oder in CaseFlows begonnen, wenn sie in Gripp noch nicht existiert.
2. Die Vertriebspipeline in CaseFlows organisiert die Nachverfolgung: die Phase, den nächsten Schritt, die Wahrscheinlichkeit, wer daran arbeitet.
3. Das Angebot, sein Betrag und sein Status kommen aus Gripp.
4. Wenn der Kunde das Angebot in Gripp annimmt oder ablehnt, wechselt die Verkaufschance von selbst auf gewonnen oder verloren.

Daneben bezieht die Finanzübersicht ihre Zahlen aus Moneybird. Angebote und Zahlen müssen nicht mehr von einem System ins andere abgetippt werden.

Und Romion hat beschlossen, einen Schritt weiterzugehen: Gripp wird mit der Zeit abgelöst, Teil für Teil. Die Pipeline läuft bereits in CaseFlows, und neue Verkaufschancen können dort beginnen. Angebote, Projekte und Stunden kommen vorerst noch aus Gripp; jeder dieser Teile wechselt, wenn er so weit ist, ohne dass der Vertriebsprozess neu entworfen werden muss. Die vollständige Ablösung ist noch nicht gezeigt; gezeigt ist die Pipeline.

Nicht jedes Backoffice-System muss ersetzt werden. Viele werden ihre Aufgabe noch jahrelang erfüllen, während CaseFlows die neue Arbeit um sie herum organisiert. So läuft es heute.

Andere erreichen das Ende ihrer Nutzungsdauer. Weil der Caseflow beschreibt, wie die Arbeit organisiert ist, bedeutet der Wechsel eines Backoffice-Systems dann nicht automatisch, dass der Prozess neu entworfen werden muss. Ein Ersatz muss weiterhin die Daten und Dienste liefern, von denen der Caseflow abhängt, und das macht Arbeit: einen neuen Konnektor und eine Übersetzung in dieselben Konzepte. Aber diese Arbeit lässt sich getrennt vom Prozess erledigen, und ein Konzept nach dem anderen.

Der erste Weg läuft heute in Produktion. Der zweite ist bei Romion Health im Gang, das Gripp Konzept für Konzept ablöst. Er ist noch nicht abgeschlossen; wir können also den Weg zeigen, noch nicht sein Ende.

Sie müssen Ihre Systeme nicht zuerst modellieren oder ersetzen. Sie beginnen mit einem Prozess:

1. Wählen Sie den Prozess, den Sie verbessern möchten.
2. Lesen Sie über einen Konnektor aus, welche Daten und Dienste Ihre Systeme dafür bereits haben.
3. Legen Sie fest, welche Konzepte der Caseflow braucht und welches System jeweils die Quelle ist.
4. Bauen Sie den Caseflow und verbinden Sie ihn mit diesen Systemen.
5. Spielen Sie echte Szenarien in der Entwicklungsumgebung durch, bevor etwas in Produktion geht.

Echte Daten in der Entwicklungsumgebung auszulesen zeigt, was wirklich in Ihren Systemen steht, nicht was die Dokumentation sagt. Diese Umgebung gehört Ihrer Organisation, hinter derselben Anmeldung und denselben Rollen: Wer dort was sehen darf, folgt denselben Regeln wie in Produktion.

Läuft heute

• Gripp und Moneybird bei Romion Health in Produktion angebunden, mit Pipeline, Angeboten und Finanzübersicht darauf aufgebaut.
• Weitere Systeme als Dienste angebunden, etwa eine Datenbankplattform und ein Learning-Management-System.
• Konnektoren, die ein System in die Konzepte übersetzen, mit denen der Caseflow arbeitet, mit einer vereinbarten Quelle pro Konzept.
• Neue Anbindungen, die in der Entwicklungsumgebung ausgelesen werden, bevor etwas darauf gebaut wird.

Wohin wir gehen

• Ein Backoffice-System Konzept für Konzept ablösen, ohne den Prozess neu zu entwerfen: im Gang bei Romion Health, wo Gripp abgelöst wird. Die Pipeline ist umgezogen; Angebote, Projekte und Stunden sind als Nächstes an der Reihe.
• Mehr Systeme, die sich ohne neue Arbeit für jedes einzelne anbinden lassen.