Die kurze Antwort
Die Zahl der Prozesse können Sie nicht selbst wählen. Ein Prozess besteht aus einem Trigger, dann einem einzigen Filterknoten, dann Aktionen – und ein Filter darf nie Kind einer Aktion sein. Einem Prozess, der bereits eine unabhängige Bedingung hat, lässt sich also keine zweite hinzufügen. Sie muss an einen anderen Prozess übergeben werden, der seinen eigenen Filter trägt.
Der aufgerufene Prozess läuft entweder bei einer Datensatzänderung oder manuell, und der manuelle Trigger ist die Wahl, die verhindert, dass er von selbst auslöst. Manuell heißt nicht „vom Benutzer ausgelöst“, sondern löst nicht von selbst aus – ein manueller Prozess kann also von einem anderen Prozess aufgerufen und von einer Person ausgeführt werden. Derselbe Prozess ist Unterprogramm in einer Kette und Reparaturwerkzeug, das jemand von Hand auslöst.
Was Sie steuern, ist also nicht, wie viele Prozesse Sie haben, sondern ob sie lesbar bleiben: Versehen Sie jeden Prozess mit einem Tag und seinen Namen mit einem Domänenpräfix, denn die Plattform zeigt, wann ein Prozess gelaufen ist, hat aber keine dokumentierte Ansicht dessen, was ihn aufruft.
Das Geschäftsproblem
Ein Geschäftsereignis erfordert meist, dass mehrere voneinander unabhängige Dinge geprüft werden. Nehmen Sie einen Account, der vom Interessenten zum Kunden wird:
- Wenn die Daten des Hauptkontakts fehlen, benachrichtigen Sie den Eigentümer – sonst geht jede spätere automatisierte E-Mail an niemanden.
- Wenn die Region als zweibuchstabiges Kürzel eingegeben wurde, erweitern Sie es, weil das Reporting nach Ländern sonst unbemerkt in Duplikate zerfällt.
- Befüllen Sie die Verlängerungsdaten aus der Vertragslaufzeit, die entweder zwölf oder vierundzwanzig Monate beträgt.
Das sind keine Alternativen. Ein einzelner Account kann alle drei brauchen, und sie haben nichts miteinander zu tun. Der Reflex ist, einen einzigen Prozess für „Account wird Kunde“ zu schreiben, der alles erledigt – und um genau diesen Reflex geht es in §2.
Der Bestand, aus dem dieses Beispiel stammt, umfasst 265 Prozesse über sieben Entitäten, davon 113 allein auf einer Entität. Diese Zahl ist weder Wildwuchs noch ein Warnsignal. Sie ist das, was die Form der Engine ergibt, wenn ein Unternehmen so viele Regeln hat, und die interessante Frage ist nicht, wie man weniger hat, sondern wie Hunderte lesbar bleiben.
Warum der naheliegende Ansatz scheitert
Alle drei Prüfungen in einen Prozess packen
Ein Prozess bekommt einen Filter, und der Filter ist ein einzelnes Tor. Seine Zweige lauten wenn / dann / sonst – der erste passende Zweig gewinnt, und die übrigen werden nie ausgewertet.
Die drei Prüfungen oben, geschrieben als drei Zweige eines Prozesses, bedeuten also: Ein Account, der alle drei braucht, bekommt nur die erste. Kein Fehler, keine Warnung, keine Meldung über einen Teilerfolg. Zwei Korrekturen finden einfach nicht statt, und der Prozess sieht aus, als sei er gelaufen.
Das ist das mit Abstand teuerste Missverständnis, das die Prozess-Engine zu bieten hat, denn der Entwurf sieht aufgeräumter aus und das Scheitern ist unsichtbar. Mit dem Erfolg wird es sogar schlimmer: Je mehr Fälle der Prozess abdeckt, desto wahrscheinlicher passt ein Datensatz auf mehrere und bekommt nur einen.
Mitten in der Kette neu zu filtern, um das zu umgehen, geht ebenfalls nicht. Ein Filter darf nie Kind einer Aktion sein – die kanonische Form ist Trigger, dann Filter, dann Aktionen, und die Engine akzeptiert kein zweites Tor, das am Ende der Arbeit des ersten hängt. Unabhängige Bedingungen lassen sich daher innerhalb eines einzigen Prozesses überhaupt nicht ausdrücken. Das ist eine strukturelle Tatsache, keine Stilfrage.
Beschreibende Namen
Einen Prozess nach dem zu benennen, was er tut – Willkommens-E-Mail senden, Verlängerungsdatum aktualisieren –, ist am ersten Tag klar und in einer Liste von zweihundert nutzlos, weil die Liste dann nach Verb sortiert. Alles, was mit Aktualisieren… beginnt, landet beieinander, egal was es berührt, und die sechs Prozesse zu einer Domäne verteilen sich über das ganze Alphabet. Sie lesen die Liste weit öfter als jeden einzelnen Namen.
Es in einer Tabelle dokumentieren
Am Tag der Erstellung korrekt, innerhalb eines Monats falsch, weil sich der Bestand in der Administrationsoberfläche ändert und das Dokument nicht. Alles, was parallel zu dem gepflegt wird, was es beschreibt, driftet ab. Was überdauert, ist das, was im Bestand lebt – deshalb trägt der Name so viel Gewicht.
Die Form eines Prozesses, und was daraus folgt
Alles in diesem Blueprint folgt aus einer strukturellen Tatsache:
trigger → filter → actions
↑
exactly one, at the root.
A filter may never be a child of an action.Das bedeutet: Ein Prozess kann eine unabhängige Bedingung anwenden. Eine zweite Bedingung braucht einen zweiten Prozess – und der Weg dorthin ist ein Trigger-Process-Knoten, der an einen anderen Prozess übergibt und seinen eigenen Filter trägt. Die nächste Bedingung lebt auf der Übergabe.
Quelle. Coevera-Hilfecenter, Automatizer — triggering a process from another process, das denselben Mechanismus als vorgesehene Bauweise darstellt: „more scaled-down processes … chained together into a unified workflow“. Der Process Manager, der sie auflistet, ist gesondert dokumentiert.
Das Beispiel vom Interessenten zum Kunden ist also nicht ein Prozess. Es ist ein Detektor plus drei Unterprozesse:
| Prozess | Trigger | Sein eigener Filter |
|---|---|---|
| Übergang erkennen | Datensatzaktualisierung auf dem Klassifizierungsfeld | Ist Kunde geworden |
| Prüfung der Kontaktdaten | Manual (aufgerufen) | Felder des Hauptkontakts leer |
| Korrektur der Region | Manual (aufgerufen) | Region ist ein zweibuchstabiger Code |
| Befüllung der Verlängerungsdaten | Manual (aufgerufen) | Laufzeit beträgt 12 oder 24 Monate |
Jeder Unterprozess wertet seine eigene Bedingung unabhängig aus, sodass ein Account, der alle drei Korrekturen braucht, auch alle drei bekommt. Das ist der ganze Grund, warum der Bestand so geformt ist.
Geben Sie jedem Unterprozess an der Wurzel einen großzügigen Filter, auch wenn der Aufrufer bereits entschieden hat. Das kostet nichts und bringt etwas Bestimmtes: Weil manuelle Prozesse auch von einer Person ausgeführt werden können, wird der Unterprozess womöglich in einem Kontext aufgerufen, den niemand geprüft hat. Sein eigener Wurzelfilter macht ihn in beide Richtungen sicher.
Der Trigger-Typ ist eine Tatsache ersten Ranges
Es gibt vier Trigger-Typen, und der Typ bestimmt sowohl, wie ein Prozess erreicht wird, als auch, wie er scheitert. Das gehört in Ihr Denken über den Bestand, nicht in etwas, das Sie erst beim Öffnen eines Prozesses entdecken.
| Typ | Erreicht durch | Wie er scheitert |
|---|---|---|
| Record | Eine Feldänderung | Still. Wenn sich das Feld nicht mehr ändert – eine Integration stockt, ein Import schreibt denselben Wert erneut –, löst nichts aus, und nichts meldet es. Nicht von einer ruhigen Woche zu unterscheiden. |
| Schedule | Eine Uhrzeit | Selbstsicher. Er läuft pünktlich, ob seine Eingaben aktuell sind oder nicht, und handelt daher auf veralteten Daten, statt nicht zu handeln. |
| Manual | Ein anderer Prozess, der ihn aufruft, oder eine Person, die ihn ausführt | Verwaist. Wird der Aufrufer so umgeschrieben, dass er ihn nicht mehr aufruft, wird der Unterprozess nicht mehr erreicht, und nichts sagt es. Seine Bedingung ist weiterhin korrekt; nichts fragt sie ab. |
| Online form | Eine Formularübermittlung | Mit dem Formular. Außerhalb des Rahmens dieses Blueprints. |
Die Zahl, die sich an Ihrem eigenen Bestand zu messen lohnt. Auf der meistgenutzten Entität hier – 113 Prozesse – lautet die Aufteilung 41 datensatzgetriggert, 16 geplant und 56 manuell.
Dass die Hälfte dieser Entität manuell ist, ist keine Schublade vergessener Hilfswerkzeuge. Es ist die Kompositionsschicht: die Unterprozesse, die existieren, weil unabhängige Bedingungen sich keinen Filter teilen können. Ein hoher Anteil manueller Prozesse in einem ausgereiften Bestand ist ein Zeichen, dass die Zerlegung richtig gemacht wurde.
Er erzeugt allerdings das eine Fehlerbild, das nur dieser Typ hat. Ein datensatzgetriggerter Prozess, der nicht mehr auslöst, ist wenigstens noch als Beobachter eines Felds aufgeführt; ein verwaister Unterprozess sieht genauso aus wie ein funktionierender. Deshalb verfolgt §7 Aufrufketten, statt nur die Liste zu lesen.
Muster, die einen großen Bestand lesbar halten
Mit Tags nach Domäne, und den Namen dazu mit Präfix
Prozesse können Tags tragen, und der Process Manager filtert nach Tag ebenso wie nach Eigentümer und Status (Automatizer — creating and running processes). Nutzen Sie sie. Die Suche der Liste durchsucht jedoch Namen, ein Tag erscheint nur in einer Spalte, die Sie eigens hinzufügen, und es gibt keinen Ordner und keine dokumentierte Abhängigkeitsansicht. Stellen Sie die Domäne deshalb auch in den Namen, in eckigen Klammern an den Anfang:
[Contracts] Create the renewal record
[Contracts] Watch the renewal date for changes
[Hygiene] Normalise country and region codes
[Hygiene] Flag records whose status contradicts their dates
[Outreach] Send the scheduled check-inEine flache Liste gruppiert sich dann selbst, wenn sie sortiert wird, eine Suche nach einer Domäne liefert alles, was sie berührt, und das Hinzufügen eines Prozesses erzwingt die Frage Zu welcher Domäne gehört das? – und genau das fängt ein Duplikat ab, bevor es entsteht.
Der untersuchte Bestand nutzt etwa ein Dutzend Präfixe; das größte umfasst fünfundzwanzig Prozesse, das kleinste zwei. Diese Verteilung ist selbst ein Prüfwerkzeug: Fünfundzwanzig Mitglieder sind eine Domäne, die es wert ist, als Ganzes gelesen zu werden, und zwei sind entweder ein echter Randfall oder ein Benennungsversehen.
Eine Konvention, die nicht durchgesetzt wird, driftet. Zwei der Präfixe in diesem Bestand sind Singular und Plural desselben Worts – zwölf Prozesse unter der einen Schreibweise, dreizehn unter der anderen, alle zur selben Entität. Keine davon ist falsch; zusammen bedeuten sie, dass die Gruppierung unbemerkt versagt, denn beim Sortieren stehen sie nebeneinander, während die Suche nach der einen die andere verfehlt.
Schreiben Sie die Präfixliste als feste Menge auf und prüfen Sie neue Prozesse dagegen. Die billigste denkbare Governance, und das Erste, was verfällt.
Die Kette benennen, nicht nur den Prozess
Weil Unterprozesse erreicht werden, indem sie aufgerufen werden, und nicht, indem sie etwas beobachten, ist der Name der einzige Hinweis darauf, wer wen aufruft. Ein gemeinsames Präfix plus ein einheitliches Verb für den Detektor – den Prozess, dem das Ereignis gehört – macht eine Kette allein aus der Liste lesbar. Ohne das heißt, ein Geschäftsereignis nachzuverfolgen, so lange Prozesse zu öffnen, bis Sie den Aufrufer finden.
Ein Unterprozess dient zugleich als Unterprogramm und als Reparaturwerkzeug
Weil manuell aufrufbar und ausführbar bedeutet, ist der Unterprozess, den Sie für die Kette gebaut haben, auch das, was Sie von Hand ausführen, wenn sich ein Datum verschiebt, ein Datensatz in der falschen Reihenfolge angelegt wird oder eine Automatisierung für einen Nachmittag deaktiviert war. Das ist derselbe Mechanismus wie der manuelle Zwilling in Blueprint 010 und die erneut ausführbare Ableitung in Blueprint 009 – kein eigenes Muster, sondern dasselbe aus einem anderen Blickwinkel. Einmal gebaut, erledigt er beides, sofern er seinen eigenen Wurzelfilter behält.
Ein letzter Auffangzweig, der etwas meldet
Jeder Filter, der einen Wert auf ein Ergebnis abbildet, sollte mit einem Zweig enden, der alles erfasst, was die vorherigen nicht erfasst haben, und dessen Aktion darin besteht, jemandem Bescheid zu geben. Bei der Semantik „der erste Treffer gewinnt“ nimmt ein unbekannter Wert sonst den Auffangpfad, der gerade existiert, und erzeugt überhaupt keinen Fehler. Die billigste Versicherung, die es in einem Bestand dieser Größe gibt.
Grenzen & Kompromisse
Die Zerlegung aus §3 ist zwingend. Die Folgen unten sind es nicht – sie ergeben sich aus einer zweiten Lücke: Die Plattform meldet, wann ein Prozess läuft, nicht, wie der Bestand zusammenhängt. Der Process Manager hat eine Spalte Activity (24 hours) und Laufstatistiken für bis zu 14 Tage, und jeder Prozess führt ein Activity Log seiner Ausführungen (Process Manager). Bei aktivierten Benachrichtigungen wird der Eigentümer gewarnt, wenn ein Prozess gelöscht oder deaktiviert wird, der noch mit einem anderen verbunden ist (triggering a process from another process). Keine dokumentierte Ansicht zeigt dagegen, was einen bestimmten Prozess aufruft oder was ohne ihn nicht mehr erreicht würde. Wo die Hälfte der Prozesse auf einer Entität nur durch Aufruf erreicht wird, ist dieser fehlende Aufrufgraph der teure Teil.
Nichts wird gelöscht, also wird umbenannt
In diesem Bestand beobachtet: Fünf Prozesse tragen die Wörter not used oder obsolete im eigenen Namen. Einer davon hängt an einem täglichen Zeitplan und läuft noch.
Das ist keine Nachlässigkeit – es ist die rationale Reaktion darauf, dass sich nicht beweisen lässt, dass eine Löschung sicher ist. Umbenennen ist umkehrbar und kostet nichts; Löschen könnte etwas kaputtmachen, das niemand benennen kann. So sammelt der Bestand eine Schicht von Prozessen an, die als tot dokumentiert und nicht abgeschaltet sind.
Die Abhilfe ist eine Konvention, kein Werkzeug: Ausmusterung heißt zuerst deaktivieren, dann umbenennen, und löschen an einem Datum, das Sie in den Namen schreiben. Ein Prozess, der als ungenutzt markiert ist und trotzdem auslöst, ist schlimmer als jeder der beiden Zustände für sich, denn der Name sagt der nächsten Person, etwas zu ignorieren, das aktiv Arbeit verrichtet.
Duplikate sammeln sich Jahr für Jahr an
Alles, was ein Jahr in seiner Logik hat, wird tendenziell jeden Januar kopiert statt erweitert, und die ältere Kopie wird nie ausgemustert. Dieser Bestand enthält mehrere solcher Familien, in denen zwei Prozesse weitgehend dieselbe Arbeit über unterschiedliche Jahresbereiche verrichten. Jede war zu ihrer Zeit die richtige minimale Änderung; zusammen sind sie zwei Stellen, die aktualisiert werden müssen, und ein Münzwurf darüber, welche tatsächlich gelaufen ist.
Geplante Prozesse kollidieren, und nichts warnt Sie
Geplante Uhrzeiten werden einzeln gewählt, ohne Überblick darüber, was bereits geplant ist. In diesem Bestand laufen drei voneinander unabhängige tägliche Prozesse in derselben Stunde, und andere liegen fünf und fünfundzwanzig Minuten auseinander.
Gleichzeitige Planung ist für sich genommen kein Fehler. Sie wird zu einem, wenn zwei davon dieselben Datensätze berühren, denn zwischen ihnen gibt es keine Reihenfolgegarantie und um keinen von beiden eine Transaktion – welcher gewinnt, lässt sich also nicht aus der Konfiguration ableiten. Führen Sie eine einzige Liste der geplanten Uhrzeiten und ihrer Verantwortlichen, und legen Sie alles zeitlich auseinander, was sich eine Datensatzmenge teilt.
Ein verwaister Unterprozess lässt sich nicht von einem funktionierenden unterscheiden
Das ist das Fehlerbild, das das Kompositionsmodell mit sich bringt. Ein Unterprozess wird nur erreicht, indem er aufgerufen wird. Deaktivieren Sie seinen Aufrufer, erhält der Eigentümer möglicherweise eine Warnung, sofern Benachrichtigungen aktiviert sind; schreiben Sie den Aufrufer so um, dass er ihn nicht mehr aufruft, meldet sich nichts. In beiden Fällen sieht der Unterprozess weiter aus wie jeder andere aktivierte Prozess in der Liste, seine Aktivität so still wie in einer ruhigen Woche. Sein Filter ist weiterhin korrekt. Nichts fragt ihn ab.
Es ist auch die einzige Form eines toten Prozesses, deren Tod Sie tatsächlich beweisen können, denn der Aufruf steht in der Definition des Aufrufers selbst. Das macht die Verfolgung von Aufrufketten zur wertvollsten Prüfung in §7 und zum einzigen Weg, einen Bestand mit Gewissheit statt mit Nervenstärke aufzuräumen.
Persönliche Prozesse sind eine echte Kategorie
Bestände dieser Größe enthalten Prozesse mit den Initialen einer Person als Präfix – persönliche Werkzeuge, gebaut für die Routine eines Einzelnen. Sie funktionieren, sie werden genutzt, und für alle anderen sind sie unsichtbar. Geben Sie ihnen ein gemeinsames Präfix und schreiben Sie in den Namen, was sie tun, denn die Alternative ist, dass sie an dem Tag herrenlos werden, an dem diese Person die Rolle wechselt.
Was wir nicht verifiziert haben
Die strukturellen Aussagen – ein Filter an der Wurzel, ein Filter nie Kind einer Aktion, die vier Trigger-Typen, der Übergabeknoten mit eigenem Filter – sind aus dem API-Schema und aus Prozessdefinitionen abgelesen, die aus der Administrationsoberfläche erfasst wurden. Das Verhalten „der erste Treffer gewinnt“ der Zweige eines Filters und die durchgehend genannten Zahlen zum Bestand stammen aus dem Betrieb dieser Installation.
Wir haben nicht getestet, ob sich Prozesse massenhaft nach Namensmuster aktivieren und deaktivieren lassen oder ob die Plattform eine Aufrufgraph-Ansicht bietet; die Dokumentation des Process Manager beschreibt keines von beiden. Die obigen Praktiken gehen davon aus, dass es beides nicht gibt, weil dieser Bestand in der Praxis so verwaltet wird – aber dass etwas nicht genutzt wird, beweist nicht, dass es fehlt. Wenn Sie Konventionen für einen neuen Space festlegen, prüfen Sie die aktuelle Administrationsoberfläche, bevor Sie sich darauf festlegen, das von Hand auszugleichen.
Verifizierung
Dies ist die Prüfung für einen Bestand, den Sie nicht selbst gebaut haben, und sie funktioniert von außen. Sie liest durchweg die Prozessliste, statt Prozesse einzeln zu öffnen.
- Nach Namenspräfix gruppieren und ansehen, was keines hat. Prozesse ohne Präfix sind meist die Versehen – in Eile hinzugefügt, nie wieder angesehen. Zählen Sie auch die verschiedenen Präfixe: Mehr als etwa fünfzehn heißt, dass das Schema kein Schema mehr ist.
- Auf Singular und Plural desselben Präfixes prüfen und auf dieselbe Domäne in zwei Schreibweisen. Das ist das häufigste stille Scheitern einer Namenskonvention, und es dauert dreißig Sekunden, es zu finden.
- Die geplanten Prozesse nach Uhrzeit gruppieren. Alles, was sich eine Stunde teilt, ist einen Blick wert; alles, was sich eine Stunde und eine Datensatzmenge teilt, ist es wert, behoben zu werden.
- Die Namen durchsuchen nach not used, obsolete, old, temp, copy und nach persönlichen Initialen. Dann prüfen, ob jeder davon tatsächlich deaktiviert ist. Die Lücke zwischen „als tot benannt“ und „abgeschaltet“ ist der Ort, an dem sich diese Prüfung bezahlt macht.
- Die Aufrufketten verfolgen. Finden Sie für jeden Prozess mit manuellem Trigger, was ihn aufruft. Die, die nichts aufruft, sind wirklich tot – und das ist die einzige Art toter Prozess, die Sie beweisen können, weil der Aufruf in der Definition des Aufrufers steht und nicht in einer Schlussfolgerung. Tun Sie das vor allem anderen, wenn Sie den Bestand geerbt haben.
- Manuelle gegen datensatzgetriggerte Prozesse zählen. Ein hoher manueller Anteil in einem ausgereiften Bestand ist zu erwarten und gesund – er ist die Kompositionsschicht. Entscheidend ist, ob jeder einen Aufrufer hat. Ein hoher manueller Anteil plus Waisen ist das Signal, dass eine Kette umgeschrieben und ihre Teile zurückgelassen wurden.
- Jeden Filter mit mehreren Zweigen auf Unabhängigkeit prüfen. Wo Zweige Alternativen darstellen – ein Status hat einen von vier Werten –, ist ein Prozess richtig. Wo sie Bedingungen darstellen, die alle gleichzeitig zutreffen können, bedeutet „der erste Treffer gewinnt“, dass immer nur einer greift, und die anderen müssen in Unterprozesse ausgelagert werden. Das ist die Prüfung, die den Fehler aus §2 in einem Bestand findet, den jemand anderes gebaut hat.
- Versuchen, den Zweck jedes Prozesses in einem Satz zu formulieren. Die, bei denen Ihnen das nicht gelingt, tragen mehr als ein Anliegen, und sie sind die Kandidaten zum Aufteilen – nicht weil sie kaputt sind, sondern weil sich später niemand trauen wird, sie zu ändern.
Was auf eine Regression hindeuten würde: ein neuer Prozess ohne Präfix oder mit einem Präfix, das nicht auf der vereinbarten Liste steht; ein Prozess mit manuellem Trigger ohne Aufrufer; ein Filter mit mehreren Zweigen, deren Zweige unabhängige Bedingungen statt Alternativen sind; ein als ausgemustert benannter Prozess, der noch aktiviert ist; zwei Prozesse, deren Namen sich nur durch eine Jahreszahl unterscheiden; ein geplanter Prozess, der einer Stunde hinzugefügt wird, in der bereits einer dieselben Datensätze berührt.
Häufige Fragen
Wie halten Sie einen großen Bestand an CRM-Automatisierungen wartbar?
Akzeptieren Sie zuerst, dass Sie die Anzahl nicht selbst wählen. Ein Coevera-Prozess besteht aus einem Trigger, dann einem einzigen Filterknoten, dann Aktionen – und ein Filter darf nie Kind einer Aktion sein, sodass sich einem Prozess, der bereits eine unabhängige Bedingung hat, keine zweite hinzufügen lässt. Sie muss an einen anderen Prozess mit eigenem Filter übergeben werden. Ein Geschäftsereignis, das drei voneinander unabhängige Korrekturen braucht, ergibt deshalb konstruktionsbedingt drei oder vier Prozesse. Was Sie tatsächlich steuern, ist die Lesbarkeit: Versehen Sie jeden Prozess mit einem Domänen-Tag und zusätzlich mit einem Domänenpräfix in eckigen Klammern, denn die Suche in der Prozessliste durchsucht die Namen; machen Sie den Trigger-Typ explizit, da jeder Typ auf eine andere Weise scheitert; und geben Sie jedem Unterprozess einen großzügigen Wurzelfilter, damit er sich selbst absichert, falls er je eigenständig ausgeführt wird.
Warum braucht ein Geschäftsereignis mehrere CRM-Prozesse statt eines einzigen?
Weil ein Prozess einen Filter bekommt und dieser Filter ein einzelnes WENN-DANN-SONST-Tor ist, bei dem der erste passende Zweig gewinnt. Nehmen Sie einen Account, der vom Interessenten zum Kunden wird und drei unabhängige Korrekturen braucht: den Eigentümer benachrichtigen, wenn die Daten des Hauptkontakts fehlen, ein zweibuchstabiges Regionskürzel zum vollen Namen erweitern, damit das Länderreporting nicht zerfällt, und die Verlängerungsdaten aus einer Laufzeit von zwölf oder vierundzwanzig Monaten befüllen. Das sind keine Alternativen, sondern drei Dinge, die alle gleichzeitig zutreffen können. Stehen sie in einem Prozess, läuft nur der erste passende Zweig, und ein Datensatz, der alle drei braucht, bekommt einen. Die Abhilfe ist ein Prozess pro unabhängiger Bedingung, aufgerufen von dem Prozess, der das Ereignis erkannt hat.
Was bedeutet ein „manueller“ Trigger in Coevera-Prozessen?
Beides zugleich, und genau darum geht es. Manual ist einer von vier Trigger-Typen neben Datensatz, Zeitplan und Onlineformular, und eigentlich bedeutet er, dass der Prozess nicht von selbst auslöst – er kann also von einer Person aus einem Datensatz heraus ausgeführt und von einem anderen Prozess über einen Trigger-Process-Knoten aufgerufen werden. Derselbe Prozess dient als Unterprogramm in einer automatisierten Kette und als Reparaturwerkzeug, das jemand von Hand ausführt, ohne zweimal gebaut zu werden. Deshalb hat im untersuchten Bestand etwa die Hälfte der Prozesse auf der meistgenutzten Entität (56 von 113) einen manuellen Trigger, und deshalb weist diese Zahl auf bewusste Zerlegung hin statt auf ungenutzte Hilfswerkzeuge. Es ist auch der Grund, warum jeder Unterprozess an der Wurzel einen eigenen großzügigen Filter behalten sollte: Der automatisierte Aufrufer hat den Kontext bereits geklärt, eine Person, die ihn eigenständig ausführt, aber nicht, und der Wurzelfilter macht denselben Prozess in beide Richtungen sicher.
Wie prüfen Sie CRM-Automatisierungen, die Sie nicht selbst gebaut haben?
Arbeiten Sie von der Form statt vom Inhalt aus. Gruppieren Sie jeden Prozess nach Namenspräfix und sehen Sie sich an, was keines hat, denn Prozesse ohne Präfix sind meist die, die in Eile hinzugefügt wurden. Prüfen Sie, ob dieselbe Domäne unter zwei Schreibweisen auftaucht – das häufigste stille Scheitern einer Namenskonvention. Gruppieren Sie die geplanten Prozesse nach Uhrzeit und suchen Sie nach mehreren in derselben Stunde, besonders nach solchen, die dieselben Datensätze berühren, denn zwischen ihnen gibt es keine Reihenfolgegarantie. Durchsuchen Sie die Namen nach not used, obsolete, old, temp und persönlichen Initialen und prüfen Sie dann, ob jeder davon tatsächlich deaktiviert und nicht nur so beschriftet ist. Und verfolgen Sie die Aufrufketten: Ein Unterprozess, den nichts aufruft, ist wirklich tot – die einzige Form eines toten Prozesses, die Sie beweisen können.