Neue Version! FireStart 2019.4 ist da

Dominik Bachmair
Mittwoch, 06. November 2019

FireStart ist jetzt noch cooler :) Mit der neuen Version 2019.4 kann man noch einfacher, wesentlich mächtigere Workflows bauen. Es hat sich viel getan, seit der letzten Version (4.10) und das nicht nur unter der Haube, sondern auch an Stellen, die man als User sieht.

FireStart ist unser Partner im Bereich Business Process Management und bietet eine vollintegrierte Lösung zur Gestaltung und Abbildung von Unternehmensprozessen sowie der Gestaltung, Implementierung und Verlinkung zugehöriger Workflows für die Automatisierung dieser Prozesse an einem Ort. Ebenfalls kann damit auf Knopfdruck eine normgerechte Prozessdokumentation generiert werden.

Die drei wichtigsten Änderungen der neuen Version habe ich in diesem Beitrag kurz zusammengefasst.

Authentication

Die wohl größte Änderung hat im Bereich der Authentifizierung stattgefunden: Dank dem eigens entwickelten Identity Server ist es ab sofort möglich, sich zusätzlich zur bisherigen Windows-Authentifizierung (NTLM) auch mit anderen Diensten zu authentifizieren, wie etwa mit Azure Active Directory (AAD) oder SAMLv2. 

Was bringt das? Dies ermöglicht eine bessere Cloudanbindung. Man kann somit von jedem Ort, an dem man einen Internetzugang hat, mit dem System arbeiten und muss sich nicht mehr über VPN oder dergleichen vorher erst einwählen. Zusätzlich ist es auch möglich, User, die nicht dem eigenen Unternehmen angehören, zu integrieren. So kann zum Beispiel ein Mitarbeiter eines Kunden, Lieferanten oder Partners in das eigene Azure Active Directory eingeladen werden und in den Unternehmensprozessen eine aktive Rolle einnehmen.

Forms

Die Formulare sind ab der aktuellen Version mit sogenannten „Cascading Lookups“ ausgestattet. Dies bedeutet, dass in Formularen verwendete Tabellen, Listen oder DropDown-Menüs die Einträge nun auf Basis anderer Formulareingaben gefiltert werden können. Ein weiteres Highlight bei den Formularerweiterungen ist, wie ich finde, die externe Datensuche. Mit dieser kann eine Vielzahl von zusätzlichen Services im Netz genutzt werden, da man im Prinzip jede REST-API (Representational State Transfer Schnittstelle) einfach anzapfen kann. Das ermöglicht ganz neue Wege, die eigenen oder auch fremde Drittsysteme in Workflows einzubinden.

Zusätzlich gibt es noch eine neue Erweiterung für Personen in den Formularen. Diese können ebenfalls ihre Informationen über die zuvor erwähnte externe Datenquelle beziehen oder auch bei der Workflowmodellierung definiert werden. Somit können nun Personen nach unterschiedlichen Kriterien schneller gefunden und ausgewählt werden, ohne der Notwendigkeit, die genaue E-Mail-Adresse oder den Benutzernamen der Person kennen zu müssen. Besonders gefällt mir an diesem Punkt, die deutliche Verbesserung der Usability im Workflow, denn jetzt ist auch eine Mehrfachauswahl der Personen möglich. Bei der Erstellung des Workflows kommt es häufig vor, dass man mehrere Personen als Interessenten oder Gruppenmitglieder in Workflows auswählen möchte, zu Beginn aber noch nicht weiß, wieviele notwendig sind. In der bisherigen Version musste man je nach Bedarf, mehrere einzelne Personenauswahlfelder in ein Formular einbauen, um die Personen z.B. aus dem Active Directory auszuwählen. Was ist das Problem dabei? Zum einen ist es nicht sehr benutzerfreundlich und zum anderen baut man ein „starres“ Formular mit beispielsweise fünf Auswahlfelder. Muss eine sechste oder noch mehr Personen hinzugefügt werden, musste das ganze Formular wieder umgebaut werden.

Model meta data extension

Bei der Erstellung eines Workflows kann man nun am Modell selbst zusätzliche Informationen betreffend Personen oder Gruppen hinzufügen und diese benennen. Wozu? Wie bereits bei den Formularen erwähnt, kann eine Personenauswahl von einer externen Datenquelle mit Informationen versorgt werden oder eben auch vordefiniert sein. Dieses Erweiterungsfeld behandelt den vordefinierten Aspekt. So kann ich unter Anderem eine Gruppe von Personen am Workflow vordefinieren und diese etwa „Approver“ nennen. Darin können eine oder mehrere Personen enthalten sein. Auf diese vordefinierten Personen oder Gruppe kann man nun jederzeit im Workflow zugreifen und für unterschiedliche Zwecke verwenden, wie etwa für die Personenauswahl in einem Formular oder für anschließende Freigabeschritte in einer Aufgabe. Und das, ohne eigene potenziell aufwändige Schritte im Workflow, um diesen Personenkreis immer wieder erheben zu müssen.

Responsibility

Ebenfalls Personen betreffend, ist das von mir heiß ersehnte Feature, welches nun die Macht des Process Owners (PO) spaltet. Es gibt nun konfigurierbare Modellverantwortliche, denen die Verantwortung über den Prozessablauf, die Weiterentwicklung des Workflows aus organisatorischer Sicht und die personelle Verantwortung der involvierten Personen zu Teil wird, also der klassische PO. Zusätzlich dazu kann man nun auch technische verantwortliche Personen hinterlegen, welche zumeist aus der IT-Abteilung stammen und sich um die technischen Angelegenheiten kümmern.

Ich bin sehr froh über die Einführung dieser Funktionalität, weil sich jetzt nicht mehr die - in der Praxis oft schwierige - Frage nach dem Process Owner stellt. Vermutlich denken sich jetzt viele, dass das ohnehin klar ist. Organisatorisch gesehen gebe ich Ihnen vollkommen recht, da es nur einen Verantwortlichen geben kann. Bisher war es in FireStart aber so, dass dieser organisatorisch verantwortliche Mitarbeiter auch die alleinige Einsicht über Fehler im Prozess hatte. Sofern diese nur den Ablauf im Prozess betreffen, ist das auch gut so. Wenn jedoch nun technische Fehler auftreten, weil zum Beispiel ein Drittsystem nicht erreichbar war, hat eben nur dieser eine Mitarbeiter diesen Fehler bekommen und nicht der IT-Support. Mal ganz ehrlich, einen Prozessverantwortlichen mit technischen Fehlermeldungen zu quälen, ist nicht ganz der Sinn der Sache. Für einen PO ist es durchaus relevant, eine Information darüber zu erhalten, da sich dadurch der Ablauf des Prozesses möglicherweise verlängert, aber nicht welchen technischen Hintergrund dies hat. Letzere Information ist doch beim Support oder einem Entwickler wesentlich besser aufgehoben, damit der Fehler auch rasch behoben werden kann. Zuvor war dies alles in einer Rolle vereint und deswegen hat die eigentlich so simple Frage, welcher Mitarbeiter die Rolle bekommt, manchmal für Diskussion gesorgt.

Ich persönlich bin schwer begeistert von der neuen Version und habe bereits viele Ideen für die Einsatzmöglichkeiten der neuen Features. Und bin ich schon gespannt, was als nächstes kommt. Darüber halte ich Sie gerne am Laufenden. Falls Sie Fragen zur aktuellen Version, oder bereits von uns umgesetzten Projekten haben, freue ich mich auf Ihre Nachricht!

Weitere Blogbeiträge

zum Thema BPM & RPA

Updates for innovators: Abonnieren Sie unseren Blog