Was ist der Wert von Workflow-Tools? [geschlossen]

Ich bin neu in der Workflow-Entwicklung und glaube nicht, dass ich wirklich den Überblick habe. Oder anders ausgedrückt: Diese Tools "klicken" momentan nicht in meinem Kopf.

Es scheint also, als würden Unternehmen gerne Geschäftszeichnungen erstellen, um Prozesse zu beschreiben, und irgendwann entschied sich jemand, ein State-Machine-ähnliches Programm zu verwenden, um Prozesse tatsächlich von einer Linie und einem Kästchen wie einem Diagramm aus zu steuern. Zehn Jahre später sind diese Tools riesig, extrem kompliziert (meine Firma spielt derzeit mit WebSphere herum und ich habe an einigen Schulungen teilgenommen, es ist ein Monster, selbst die sogenannten "minimalistischen" Versionen dieser Workflow-Tools wie Activiti riesig und kompliziert, wenn auch nicht annähernd so kompliziert wie das Tier, das von WebSphere befallen ist).

Was ist der große Vorteil dabei? Ich kann verstehen, dass die einfachen Linien und Kästchen nützlich sind, aber diese Dinge sind, soweit ich das beurteilen kann, visuelle Programmiersprachen mit Bedingungen und Schleifen. Die Programmierer hier scheinen eine erhebliche Menge an Arbeit in der Ebene der Linien und Kästchen zu leisten, was für mich nur nach einer wirklich beschissenen, wirklich einfachen visuellen Programmiersprache aussieht.

Wenn Sie so weit gehen wollen, warum nicht einfach irgendeine Skriptsprache verwenden? Haben die Leute das Baby mit dem Badewasser rausgeworfen? Wurden die Linien und Kästchen auf ein absurdes Niveau gebracht, oder verstehe ich den Wert in all dem einfach nicht?

Ich würde gerne Argumente sehen, um dies zu verteidigen, von Leuten, die mit dieser Technologie gearbeitet haben und verstehen, warum sie nützlich ist. Ich sehe den Wert darin nicht, aber ich erkenne, dass ich auch neu darin bin und es vielleicht noch nicht ganz verstehe.

Aus der Sicht eines Entwicklers haben Sie Recht, wenn Sie sagen, dass es sehr schwierig ist, mit diesen "visuellen" Umgebungen zu arbeiten. In den von mir verwendeten SharePoint 2010-Workflows werden alle bewährten Methoden zur Erstellung guter Unternehmenssoftware beschrieben - keine automatisierten Tests, keine Wiederverwendung von Code, nicht lesbare Software ... Alles, was komplexer ist als eine sofort einsatzbereite Vorlage, kann schwierig zu warten sein , wie du erlebst.

Aus geschäftlicher Sicht haben Workflows jedoch enorme Vorteile - zumindest theoretisch. Aus diesem Whitepaper geht hervor , dass die Effizienz, Rechenschaftspflicht, Kontrolle und Benutzerfreundlichkeit eines automatisierten Workflows enorme Produktivitätssteigerungen mit sich bringen. Stellen Sie sich vor, wie ineffizient ein einfacher Genehmigungs- oder On-Boarding-Prozess ohne diese Automatisierung wäre. Das Definieren eines Workflows ist für ein Unternehmen, das versucht, die Kontrolle über seine Geschäftsprozesse zu erlangen, von großem Wert.

Der aktuelle Stand der Workflow-Software ist nicht die Schuld des Unternehmens. Sie wollen einfach nur ihr Leben leichter machen, und dafür sind Workflows großartig. Ich würde uns vor allem die IT-Abteilung vorwerfen:

1. Um nicht transparenter mit dem Geschäft darüber umzugehen, wie komplex und zerbrechlich das System wirklich ist. Wir verstecken die ganze Komplexität.
2. Damit Sie mit intuitiven, einfachen Workflow-Lösungen nicht "kratzen" können. Dies ist wahrscheinlich eher ein Vorwurf gegen große Unternehmenspakete wie SharePoint und SAP, aber sie sind besser als die kundenspezifischen Lösungen, die es gibt

Es gibt nur einen wirklichen Vorteil, aber der ist riesig: Trennung von Bedenken .

Anstatt dass die Prozess-Orchestrierungslogik in unser System eingebettet ist, wird sie zu einer externen Konfiguration. Im Grunde genommen eine Karte. Sie können es (viel mehr) unabhängig voneinander ändern, Sie können mehrere Prozesse, mehrere Versionen von Prozessen, mehrere Versionen von mehreren Prozessen gleichzeitig ausführen lassen, und das ist in jeder anständigen Lösung eine Selbstverständlichkeit.

In der Vergangenheit hat sich das Konzept von SoC vielfach durchgesetzt - angefangen beim Unix-Prinzip "Mach eins, aber mach es gut" und werde immer wieder angewendet - wie dedizierte Serverkomponenten wie ESB, verschiedene Persistenzsysteme, Caching und Load Balancing , Überwachung, wie das Aufteilen von CSS aus HTML usw.

Ihr Geschäftsprozess und seine Ablaufregeln sind häufig orthogonal zu Ihren Daten, Benutzeroberflächen- "Bildschirmen" oder Benutzer- "Hierarchien". Es ist also durchaus sinnvoll, es getrennt von den anderen Aspekten des Systems zu entwickeln und zu ändern. Dies war die Prämisse, auf der BPM Anfang der neunziger Jahre aufgetaucht ist.

Seitdem wurden viele Tools und Sprachen entwickelt, um dieses Konzept zu unterstützen. Am bekanntesten ist BPMN - eine grafische Sprache zum Erstellen von "Flussdiagrammen", die direkt auf Prozesse abgebildet werden. Während die Leute sich darüber beschweren, dass es groß und unhandlich ist (mit über 100 Symbolen im Wortschatz) und moderne Ansätze wie S-BPM befürwortet (mit nur 5 Basissymbolen), besteht die derzeitige Praxis in der Einhaltung der BPMN oder ihrer Derivate, Untergruppen oder Geschwister.

Sie sehen mit BPMN nicht zufrieden aus:

Die Programmierer hier scheinen eine erhebliche Menge an Arbeit in der Ebene der Linien und Kästchen zu leisten, was für mich nur nach einer wirklich beschissenen, wirklich einfachen visuellen Programmiersprache aussieht.

Aber es ist nicht so schlimm.) Dahinter steckt eine Theorie. Und Version 2.0 hat einige gute Erkenntnisse aus den Mängeln von 1.0 gewonnen.

Wenn Sie so weit gehen wollen, warum nicht einfach irgendeine Skriptsprache verwenden?

Imperative Paradigmen und Skriptsprachen sind nicht immer die beste Antwort. Wie Sie wahrscheinlich in deklarativen Sprachen gesehen haben (wie HTML, CSS, SQL, Drools oder internen von Nginx, Graddle und Maven, Puppet usw.), kann der resultierende Code viel kleiner und sauberer sein als eine Version, die in " anständiger Sprache " geschrieben ist. wie Java oder C ++ ".

Wie für Ihren anderen Punkt:

Soweit ich das beurteilen kann, handelt es sich an dieser Stelle um visuelle Programmiersprachen mit Bedingungen und Schleifen.

Haben Sie sich die Ereignisse und Auslöser angesehen ? BPMN ist eine Sprache, die Sie lernen müssen, bevor Sie sie verwenden oder zumindest kennenlernen.

Unter der Haube ist BPMN XML, so dass Sie es von Hand bearbeiten oder generieren können. Und Sie können sie versionieren, da XML textbasiert ist. Nur ein XML-Dokument zu haben, das in Flussdiagramme übersetzt werden kann, klingt jedoch nicht nach Goona, und das ist auch richtig so. Es ist eine schwierige und teure Aufgabe mit fragwürdigen Vorteilen, einen eigenen Parser oder Editor zu schreiben.

Zum Glück gibt es bereits Werkzeuge auf dem Markt, die genau das tun.

Activiti ist kostenlos und sowohl bei Entwicklern als auch bei Geschäftsinhabern sehr beliebt. Grund dafür ist der anfängliche Preis ( Null ), die Verfügbarkeit von Informationen und die Bescheidenheit. Der letzte Punkt ist wirklich einzigartig, da Activi sich nur auf die Verwaltung Ihrer Geschäftsprozesse konzentriert, ohne zu versuchen, Sie an Gesamtlösungen zu binden. Außerdem ist es offen - Sie müssen nur Java und REST kennen, um es zum Laufen zu bringen. Der Nachteil ist, dass Client-Seite, Integration und Anwendungs- / Geschäftslogik sowie die gesamte Architektur dem Entwickler überlassen bleiben. Wenn Ihr Entwicklungsteam also schwach ist, bereiten Sie sich auf den Ausfall vor. Die Gesamtbetriebskosten können für ein kostenloses Tool überraschend hoch sein ;)

Auf der anderen Seite des Spektrums steht Pega (Pega PRPC), der amtierende König der BPM-Systeme (laut Gartner und Forester), der für sein Alter überraschend gut aussieht. Dieser Gigant ist sogar in der Lage, CRM, OCR und (wenn ich mich nicht irre) Spracherkennungsfunktionen, Predictive Analytics, Verwaltung von Geschäftsregeln und WYSIWYG UI Editor zu nutzen. Es kommt jedoch mit einem ernsthaften Preisschild. Das kostet nicht nur ein Vermögen, sondern die gesamte Entwicklung wird in einer Web-App durchgeführt, was bedeutet, dass Sie einen Browser verwenden müssen, der IE8 ist (plus einige Plugins plus hässliche Hacks, wie die Verwendung von Excel zum Bearbeiten von Datentabellen). Auch die Bearbeitung von Java, Javascript oder HTML / CSS erfolgt über den Webbrowser. Verabschieden Sie sich also von Unit-Tests, Hervorheben von IDE-Code, Refactoring und all Ihrem Programmierspielzeug, das Sie schon immer geliebt haben.

Gute Seite? Sie können ein komplexes System INNERHALB VON WOCHEN implementieren [ PDF , siehe Seite 22]. Und ja, das Ergebnis ist nicht garantiert.

IBM hat vor einiger Zeit (entsprechend dem Zeittempo des Unternehmens) Lombardi gekauft und bietet jetzt eine sehr wettbewerbsfähige Lösung an (aber dann müssen Sie alles kaufen , wie Sie wissen). Appian ist ein junger Anbieter, der interessante Einblicke und positives Feedback hat, aber die Art und Weise, wie sie geschrieben sind (zwei zusätzliche DSL-Sprachen zusätzlich zu einer visuellen), spricht mich einfach nicht an.

Es gibt andere Akteure und ihre Lösungen. Die meisten von ihnen sind einfach schrecklich. Wie - Ihre Augen, Gehirn und Herz würden buchstäblich bluten, wenn Sie sie einfach ansehen. Vertraue also deinem Mut und lass dich nicht von deinen Entwicklern und Nutzern hassen.

Schlussbemerkung:

Das BPM-System ist für Prozesse dasselbe wie für Photoshop für Bilder. Haben Sie keine Angst, dass es visuell ist. Lassen Sie es nicht den Job machen, der nicht dafür geeignet ist (erinnern Sie sich an Websites, die vollständig in Photoshop erstellt wurden und die so gut wie unmöglich zu bearbeiten waren?). Halte es einfach und mach keine Fehler;)

Vor Jahren, bevor die meisten von uns geboren wurden, mussten Softwareentwickler ihren eigenen Code schreiben, um Daten zu speichern. Wenn Sie den Programmstatus speichern mussten, wurde dies als Teil der Funktion des Codes angesehen. Viele Softwareentwickler schrieben schließlich Code, um Daten zu organisieren, zu speichern und zu lesen und so weiter.

Und dann wurde jemandem klar, dass dies häufig vorkam - dass die Logik zum Speichern, Organisieren, Lesen und Durchsuchen von Daten tatsächlich eine Komponente war, die so häufig verwendet wurde, dass es sich um eine eigene Komponente handeln sollte. Und wir haben Datenbanken.

In den letzten 10 bis 15 Jahren haben IT-Abteilungen erkannt, dass die Logik zum Choreografieren und / oder Orchestrieren von Geschäftsprozessen so verbreitet ist, dass sie auch eine eigene Komponente sein sollte, was zu den unterschiedlichsten Workflow-Tools geführt hat.

Ein Workflow-Tool bietet drei Hauptvorteile:

1. Erforderliche Zeit zum Vornehmen und Bereitstellen von Änderungen : Sie können die Logik eines Workflows entwickeln und ändern, ohne die gleichen technischen Risiken wie beim Ändern eines Codeteils einzugehen.
2. Transparenz : Die Geschäftslogik in einem BPM-basierten System ist sofort verfügbar und für den Geschäftsanalysten lesbar, wohingegen nur Entwickler die Geschäftslogik in "Code-basierten" Systemen lesen können.
3. Wiederverwendung technischer Komponenten : BPM-Tools werden häufig in Verbindung mit Systemen mit einer serviceorientierten Architektur verwendet. Durch die Trennung der Geschäftslogik von den technischen Komponenten - insbesondere für Unternehmenssysteme, in denen Hunderte oder Tausende verschiedener Geschäftsprozesse implementiert werden müssen - können Sie die technischen Komponenten wiederverwenden und dabei relativ wenig Zeit für die Entwicklung der Geschäftslogik (mit einem Workflow) aufwenden Werkzeug).

Eines der häufigsten Probleme bei der Verwendung von Workflow- und BPM-Tools ist jedoch, dass Entwickler immer noch versuchen, Geschäftslogik in nicht transparentem Code zu "vergraben".

Was ich die ganze Zeit sehe , dass Entwickler immer noch versuchen, die Geschäftslogik auf die technischste Art und Weise hinzuzufügen, anstatt auf die transparenteste Art und Weise. Dies ist natürlich, da Entwickler von Natur aus viel besser mit Code umgehen können als mit einem Workflow-Tool. Je mehr Logik Sie technisch beherrschen, desto mehr werden Sie als Entwickler benötigt. Leider ist dies das Schlimmste, was ein Entwickler an einem BPM-System tun kann, da er die Hauptvorteile der Verwendung von BPM unterbietet.

Schließlich sind die meisten BPM-Tools nicht weit genug, um die Workflows von Geschäftsanalysten selbst zu entwickeln. Das ist jedoch das Ziel. Im Idealfall würden Business Analysten die Workflows / Geschäftsprozessdiagramme entwickeln und Entwickler würden nur an den technischen Komponenten arbeiten, die von der Workflow-Engine aufgerufen werden.

Die folgenden Aussagen sind meine persönlichen Erfahrungen mit Workflow-Tools, insbesondere Oracle BPM Suite (10.3G & 11G). Ihre Frage konzentriert sich zunächst auf Workflow-Tools, die die Modellierung ausführbarer Prozessmodelle ermöglichen. Diese Tools sind Teil von Business Process Management Systems (BPMS). Diese spezifische Prozessmodellierung entwickelt sich definitiv und Sie können sie als visuelle Programmiersprache bezeichnen.

Der Hauptvorteil ist die Beweglichkeit, die Prozesslogik zu verstehen und zu ändern

Mit Geschäftsprozessmodellen decken Sie eine visuelle Erklärung der Prozesslogik und gleichzeitig eine ausführbare integrative Komponente ab. Dies ermöglicht ein schnelleres On- und Offboarding von Programmierern, da weniger Dokumentation zu Übergängen, Bedingungen (Gateways oder Geschäftsregeln) und Prozessabläufen im Allgemeinen dokumentiert werden muss, da dies Teil der Entwicklung ist.

Zusätzlich haben Sie Berichts- / Überwachungsfunktionen beigefügt, die Sie für jede Anwendung einzeln entwickeln müssten. Dies wird von den meisten BPMS abgedeckt.

Darüber hinaus sind in den meisten BPM-Entwicklungsumgebungen Service-Adapter (z. B. JMS, Web Services, JDBCs usw.) vorkonfiguriert, mit denen Middleware-Lösungen schrittweise und interaktiv schneller entwickelt werden können , wodurch menschliche Codierungsfehler reduziert werden.

Die Verfolgung der Workflow-Plattform bietet eine Reihe der oben genannten Vorteile - Plattformbasierter Ansatz für die Automatisierung von Workflows

Der Wert

Der Vorteil ist, dass Workflows schnell und einfach erstellt oder geändert werden können, um der sich ändernden Natur eines Unternehmens zu entsprechen. Ein wichtiger Aspekt bei der Realisierung dieses Wertversprechens ist, dass Geschäftsprozesse selbst Ressourceneinheiten im System sind.

Workflows als Ressourceneinheiten bedeuten, dass ein Geschäftsprozess als eine einzelne „Einheit“ definiert wird. Um zu verstehen, was ich damit meine, betrachten Sie jedes Computerprogramm, das für ein Unternehmen geschrieben wurde. Es implementiert zwar einen Geschäftsprozess, aber die Logik für diesen Prozess wird wahrscheinlich bis zu einem gewissen Grad im Quellcode verteilt sein. Ein Workflow-Tool sollte es ermöglichen, den Prozess an einer zentralen Stelle zu definieren. Es könnte sich in einer einzigen Konfigurationsdatei befinden oder aus einem visuellen Diagramm extrahiert werden, oder es könnte bedeuten, dass sich der Workflow in einem einzigen Codemodul befindet, das eingebunden, möglicherweise sogar im laufenden Betrieb ausgetauscht oder konfiguriert werden kann.

Warum kann der Wert nicht realisiert werden

Dieses Wertversprechen kann durch die Schwierigkeiten untergraben werden, Nicht-Vanille-Fälle abzudecken, sich in die UI-Technologie zu integrieren, die sich sehr schnell ändert, schlechte Praktiken wie die Verwendung des Workflow-Tools nur als Wrapper und das ohnehin Einfügen der echten Logik in den Code.

Eine schlechte Konstruktion der Werkzeuge selbst kann ein begrenzender Faktor sein. Ein Beispiel wäre ein Tool, bei dem alle zwischen Prozessen übergebenen Parameter in einer Java Map gespeichert sein müssen, wobei beschränkt ist, welche Werte Sie tatsächlich in die Map einfügen können, anstatt nur alte Methodenparameter (ich denke an einen der mehr) vor allem beliebte Tools, die dies tun).

Ich denke, es ist wahrscheinlich fair zu sagen, dass IBM als Big Player mit einem großen Technologie-Ökosystem besser abschneidet als die anderen. Wenn sie auch die Benutzeroberflächentechnologie sowie die Datenbank- und SOA-Technologie steuern, die in Verbindung mit dem Workflow-Tool verwendet wird, haben sie eine bessere Chance, ein Ökosystem zu entwickeln, das sich gut zusammenfügt und eine Gelegenheit bietet, dies wirklich zu nutzen diese Idee.

Es ist definitiv richtig, dass der Aufwand, die Schnittstelle zwischen einem Workflow-Tool und den anderen Teilen eines Systems zu schreiben, das gesamte Wertversprechen vollständig negieren kann. Es lohnt sich immer zu überlegen, ob es eine bessere Art gibt, Dinge zu tun.

Programmierung ist Workflow

Die Wahrheit ist, dass die Programmierung (zumindest in imperativen Sprachen) bereits WORKFLOW ist. Möglicherweise haben Sie Code, der den Workflow implementiert, der mit der Handhabung der Systemtechnologie zu tun hat. Zugreifen auf Dateien und Ausführen von SQL-Abfragen usw. Möglicherweise verfügen Sie über Code, der den Geschäftsworkflow implementiert. Festlegen des Status eines Dokuments und Weiterleiten an einen Prüfer.

Dies zu erkennen und Ihren Code so zu gestalten, dass diese einzelnen Probleme sauber getrennt werden, ist schwierig, aber Sie können mit Sicherheit einen langen Weg zurücklegen, wenn Sie genau das tun.

Ich stimme Ihnen zu, manchmal verwenden wir diese Tools, weil jemand anderes entschieden hat, dass dies eine gute Idee ist. Sie sind einfach zu komplex und erschweren unsere Arbeit. Ich denke nicht, dass dies immer der Fall ist, es bedarf einiger sorgfältiger Überlegungen, um zu entscheiden, ob es sich lohnt oder nicht.

Es ist nicht sehr klar, welches Tool Sie verwenden. Vermutlich verweisen Sie auf die allgemeinen Tools, die als Business Process Modeling-Tools bezeichnet werden. Es gibt einen guten Grund, solche Werkzeuge einzusetzen. Jedes Qualitätsunternehmen definiert seine Funktionen in Bezug auf Prozesse, und Analysten sowie Geschäftsexperten können solche Prozesse komfortabel zeichnen (bis Sie sie mit Standards verknüpfen ...). Sie können solche Prozesse auf konzeptioneller Ebene erstellen, ohne über Kenntnisse der Webprogrammierung zu verfügen. Wenn Sie über das richtige Tool verfügen, können Sie den Prozess möglicherweise auch in eine funktionierende Anwendung umwandeln (erfahrene Mitarbeiter müssen an Bord sein, damit diese Magie in die Produktion einfließt Na sicher). Die Idee ist also gut.

Das Ziel der visuellen Tools ist nicht nur die Dokumentation der Prozesse. Der Einsatz der Tools soll die professionelle Neuentwicklung von Prozessen unterstützen und in manchen Fällen Simulationen durchführen, um Punkte zu ermitteln, an denen die Prozesse weniger effizient als gewünscht sind, damit Pläne zur Beseitigung von Engpässen erstellt werden können.

Es gibt eine Standardmethode, die heutzutage von vielen Unternehmen verwendet wird: BPMN 2.0 (Business Process Modeling Notation). Ich empfehle Ihnen, diese Notation zu verstehen, wenn Ihr Tool sie verwendet.

Der Wissensbestand von Business Process Management ist eine berühmte Ressource, die Sie ebenfalls in Betracht ziehen sollten.

Das Obige deckt die Geschäftsseite ab. Die technische Seite erfordert SOA und BPEL, aber ich bin nicht sicher, ob ich hier und jetzt Ratschläge geben kann.

In einfachem Beispiel aus der Geschichte.

Steinzeit

Zuerst gab es kleine Menhire, in denen die Leute sagten, was zu tun sei, und sie taten es. Manchmal laufen die Dinge falsch und Person X oder Y wird beschuldigt (nie sicher, wer es wirklich getan hat).

Als nächstes wurde Internet und Email erfunden.

Die Leute haben jetzt anderen geschrieben, was zu tun ist, und diese Leute hatten oft Probleme mit ihrer E-Mail, lasen sie falsch oder löschten einfach eine E-Mail, ohne sie jemals zu lesen. so oft gibt man schlechten E-Mails nicht die Schuld

Workflow aus der Administration heraus entwickelt Durch die Standardisierung der Aktionen konnten die Benutzer endlich sehen, in welcher Phase der Prozess gestoppt wurde, und gleichzeitig einen digitalen Überblick darüber erhalten, was tatsächlich getan wurde. Dies funktionierte gut, bis die Leute Standardprozesse ändern wollten oder bis eine unbekannte XY-Person eine falsche Datenbankanforderung verursachte, die zu einer Beschädigung der Datenbank führte und die Produktion in die Steinzeit zurückschickte.