Jira hält fest, wie der Stand ist. Was zwischen den Vorgängen liegt, hält es nicht von selbst zusammen: Fristen im Blick behalten, Angaben übertragen, Folgeschritte anstoßen, Auswertungen und Dokumente daraus erzeugen. Diese Arbeit bleibt an Menschen hängen — oder endet dort, wo die mitgelieferte Automatisierung aufhört.
Die Arkcanis Automation Engine for Jira ist ein Regelwerk neben Ihrem Jira. Eine Regel besteht aus drei Angaben: welche Vorgänge gemeint sind, welche Bedingung gelten muss und was geschehen soll. Jira bleibt das führende System; die Engine arbeitet darauf.
Aus den vorhandenen Bedingungen und Aktionen entsteht ein neuer Ablauf als Konfiguration, ohne Programmänderung. Und wo eine Aufgabe mehr verlangt, kommt ein weiterer Baustein hinzu, der anschließend allen Regeln zur Verfügung steht. Das ist kein Sonderweg, sondern der Normalfall — auf diesem Weg ist auch die KI in die Engine gekommen: als Baustein, der vorschlägt, während die Regel entscheidet.
Welche Vorgänge eine Regel betrifft, beschreibt eine Jira-Suche — dieselbe Abfrage, mit der Sie in Jira filtern. Ein Projekt, ein Status, ein Feldwert oder eine Kombination daraus: Die Regel greift genau dort, wo Sie es festlegen, und nirgends sonst.
Vor der Ausführung prüft die Engine, was Jira selbst nicht beantwortet: wie viele Werktage seit einem Datum vergangen sind, ob ein Feld einen der zulässigen Werte trägt, wie alt der jüngste Eintrag einer Liste ist. Ihre Feiertage lassen sich dabei hinterlegen.
Was geschehen soll: Status wechseln, kommentieren, Markierungen setzen, Felder füllen — mehreres davon in einer Regel. In Kommentartexten und Feldwerten stehen Angaben aus dem Vorgang zur Verfügung. Ob eine Regel nur einmal greift oder erst nach einem Statuswechsel erneut, legen Sie mit fest.
Ein Vorgang, der zu lange unbearbeitet liegt, oder ein Termin, der näher rückt — und zwar nicht nur das Fälligkeitsdatum, sondern jedes Datumsfeld. So bekommt eine Frist ihre Vorfrist und ihren Fristablauf, jede mit eigener Erinnerung. Die Engine erkennt beides und eskaliert — mit Kommentar und Erwähnung des Bearbeiters sowie einer Markierung, die auswertbar bleibt.
Aus einem Vorgang entstehen die Folgevorgänge in den zuständigen Projekten, miteinander verknüpft; eine bereits erfasste Firma wird wiedererkannt statt neu angelegt. Welche Beziehung sich wo spiegelt, legen Sie fest — was an einer Firma hängt, wird von ihr aus sichtbar, auch über mehrere Projekte hinweg.
Angaben aus einem Webformular werden zu Vorgängen und den passenden Feldern zugeordnet. Jede Einsendung trägt eine Kennung, die am Vorgang mitgeschrieben wird; ein unterbrochener Lauf setzt daran wieder an, statt von vorn zu beginnen.
Was in einer Beschreibung steht, aber in keinem Feld, lässt sich auf Anforderung übernehmen — ein Sprachmodell erkennt die Angabe, die Leitplanken entscheiden über die Übernahme. Ohne wörtlichen Beleg im Text wird nichts geschrieben; Zahlen müssen aus dem Beleg folgen, Auswahlwerte aus Ihrer Liste stammen.
Fehlende Angaben zu einem Unternehmen können aus öffentlichen Quellen ergänzt werden — standardmäßig nur dort, wo das Feld leer ist. Widersprechen sich die Quellen, führt das Modell sie zusammen; Register- und Steuernummern müssen dennoch im Impressum stehen.
Aus gepflegten Vorgängen entsteht eine gegliederte Dokumentation in Confluence — ein Managementsystem-Handbuch etwa. Übernommen wird nur, was den Freigabestand trägt; die gepflegte Quelle bleibt Jira.
Das Modell schlägt vor, die Leitplanken entscheiden. Zwei Aufgaben übernimmt heute ein Sprachmodell: Es erkennt in einem Freitext die Angabe, die in ein Feld gehört, und es führt widersprüchliche Quellen zu einer Firma zusammen. In beiden Fällen schreibt nicht das Modell in Ihren Vorgang, sondern die Regel — und die prüft zuerst.
Geprüft wird ohne Modell. Ein wörtlicher Beleg im Text, eine Mindestsicherheit, ein leeres Zielfeld, Zahlen, die aus dem Beleg folgen und im vereinbarten Bereich liegen, Auswahlwerte aus Ihrer Liste. Register- und Steuernummern müssen im Impressum stehen, eine Umsatzsteuer-Identifikationsnummer wird zusätzlich bei der Datenbank der EU bestätigt. Was durchfällt, wird als Hinweis vermerkt statt geraten.
Was den Server verlässt, ist beschnitten und maskiert. An das Modell geht nur der Ausschnitt des Textes, der überhaupt einen gesuchten Wert enthalten kann. Name, E-Mail, Telefonnummer und Ort aus dem Vorgang werden vorher durch Platzhalter ersetzt, ebenso alles, was wie eine Mailadresse oder eine Rufnummer aussieht.
Ihr Zugang, Ihre Entscheidung. Der Schlüssel zum Modell ist Ihrer. Er liegt verschlüsselt, lässt sich im laufenden Betrieb wechseln, und ohne ihn läuft alles Übrige weiter: Die KI ist ein Baustein, keine Voraussetzung. Welches Modell zum Einsatz kommt, steht in der Konfiguration, nicht im Programm.
Und wo keine KI arbeitet: Auswahl, Bedingungen, Fristen, Statuswechsel, Verknüpfungen, die Übernahme aus Formularen und die Dokumentation aus Jira kommen ohne Modell aus. Das ist Absicht. Was sich mit einer Regel entscheiden lässt, wird mit einer Regel entschieden — das ist nachvollziehbar, wiederholbar und kostet nichts pro Vorgang.
Drei Wege, die sich ergänzen. Ein Ereignis in Jira ruft die Engine unmittelbar auf. Ein Zeittakt prüft in festem Abstand alles, was auf ein Datum oder eine Liegezeit wartet. Und ein Knopf im Vorgang stößt eine Regel von Hand an, wo eine Entscheidung dazwischengehört. Welche Wege ein Ablauf nutzt, legen wir mit fest.
Ereignis und Zeittakt laufen bewusst nebeneinander: Der Takt ist das Sicherheitsnetz, falls ein Ereignis einmal ausbleibt. Ein Aufruf von außen wird dabei nicht blind ausgeführt — die Engine fragt den Vorgang erneut gegen die Regel ab, und nur wenn er die Kriterien noch erfüllt, wird gehandelt.
Ein Trockenlauf zeigt vorab, welche Vorgänge eine Regel treffen würde, ohne etwas zu ändern.
Der Weg von einer Anfrage zum bearbeiteten Vorgang zeigt, wie mehrere Regeln ineinandergreifen: Die Anfrage wird zum Vorgang, erhält einen Bearbeiter und eine Fälligkeit, der Bearbeiter wird erwähnt. Bleibt der Vorgang liegen, greift die Fristenregel. Ist er qualifiziert, entstehen die Folgevorgänge.
Dieser Ablauf ist eine Konfiguration, kein fester Bestandteil. Ein Beteiligungscontrolling, das nur Fristen überwacht, nutzt dieselbe Engine mit anderen Regeln — und ohne eine einzige Zeile aus dem Vertriebsablauf.
Wiederkehrende Übertragungen, Erinnerungen und Zuordnungen laufen von selbst. Wo eine fachliche Entscheidung nötig ist, sehen wir sie im Ablauf ausdrücklich vor, statt sie der Automatik zu überlassen.
Jede Regel ist lesbar festgehalten: Auswahl, Bedingung, Aktion. Damit ist nachvollziehbar, warum etwas geschehen ist — und eine Änderung am Ablauf ist eine Änderung an der Regel, kein Projekt.
Mehrere Bereiche oder Gesellschaften laufen mit getrennter Konfiguration und getrennter Anbindung; ein Fehler in einem Bereich hält die übrigen nicht auf. Nach außen tritt die Engine unter Ihrem Namen auf, nicht unter unserem.
Die Engine wird als Produkt gepflegt und weiterentwickelt, nicht als einmalige Anpassung.
Namen unserer Kunden nennen wir nicht, solange uns dafür keine Freigabe vorliegt. Das halten wir bei jedem Kunden so — auch bei Ihnen. Den Ablauf gehen wir gern im Gespräch mit Ihnen durch.
Die genannten technischen Maßnahmen sind Teil der Umsetzung; die Anforderungen Ihres Betriebs werden zusätzlich für den konkreten Einsatz geprüft.
Die Engine arbeitet mit Jira Cloud; für Jira Data Center ist sie nicht ausgelegt.
Aus Auswahl, Bedingung und Aktion stellen wir einen neuen Ablauf zusammen, ohne Programmänderung: andere Vorgänge auswählen, Fristen anders bemessen, Felder anders füllen, Texte mit Angaben aus dem Vorgang bestücken, weitere Beziehungen zwischen Projekten spiegeln.
Eine neue Fähigkeit dagegen wird entwickelt und kommt als Baustein hinzu — eine Bedingung, die es so noch nicht gibt, die Anbindung an ein weiteres System, eine eigene Art von Dokument. Das ist der vorgesehene Weg und der Normalfall: Konvertierung, Anreicherung, Freitextübernahme, Formularübernahme und Dokumentation sind genau so entstanden, und jeder dieser Bausteine steht seither zur Verfügung.
Der Unterschied ist für Sie planbar — bei der Regel liegt der Aufwand in der Abstimmung, beim Baustein in der Umsetzung. Was ein Anliegen erfordert, sagen wir vorher.
Zu Beginn betrachten wir Ihre Jira- und gegebenenfalls Confluence-Umgebung, die beteiligten Datenquellen und den gewünschten Ablauf. Daraus ergeben sich die erforderlichen Anbindungen, Feldzuordnungen und Regeln.
Auch der Einsatz von KI wird konkret abgegrenzt: Welche Informationen dürfen verarbeitet werden, welche Ergebnisse benötigen eine fachliche Prüfung und welche Dienste dürfen beteiligt sein?
Einrichtung, Anpassungen und laufende Leistungen werden im Angebot ausgewiesen. Der Umfang richtet sich nach Ihrem Prozess und der vereinbarten Betriebsform.
Wenn neue Unternehmensadressen zunächst recherchiert und geprüft werden müssen, kann der Arkcanis Zielkunden-Scout den vorgelagerten Arbeitsschritt übernehmen.
Der Scout unterstützt die Recherche und Bearbeitung der Einträge. Qualifizierte Adressen werden anschließend an den Vertriebsprozess mit der Automation Engine übergeben.
Eine Regel ist nur so gut wie der Ablauf, den sie abbildet. Wo Zuständigkeiten, Felder und Stufen noch nicht entschieden sind, beginnt die Arbeit in der Atlassian-Beratung — dort wird der Prozess modelliert, bevor er automatisiert wird.
Schreiben Sie uns kurz, worum es geht – wir melden uns bei Ihnen.