Wenige englische/US Workflow Lösungen? Was nutzt Ihr?

[JulianBuss]

Hi,

(um es vorweg zu nehmen: ich bin befangen, weil wir selbst eine Workflow Lösung herstellen.)

Im Zuge einer Recherche, welche Workflow Lösungen es außer Lotus Workflow (was ja nun praktisch tot ist), Pavone, Gedys und einigen OpenNTF Projekten im internationalen Markt so gibt, habe ich fast nichts gefunden.

An ernstzunehmenden Kandidaten hab ich gefunden:
http://www.teamsol.com/
http://www.ionetsoftware.com/

Kann das stimmen, dass es wirklich nicht mehr Lösungen gibt? Oder bin ich zu doof, die zu finden?

Wenn dem so ist: arbeiten Amerikaner, Engländer etc. so unterschiedlich, dass sie keine Workflow Lösungen brauchen?

Wer von Euch in einem größeren, internationalen Konzern arbeitet: was verwendet Ihr?

Hintergrund ist Neugier meinerseits, ob der internationale Markt ein weiteres Workflow System braucht.

[Thomas Schulte]

Der Punkt an dieser Stelle ist glaube ich das jeder einzelne auf "seine" Workflow Anwendung schwört.

Das heist man hat hier als Anbieter zum einen das Problem, das sich jeder ernst zu nehmende Entwickler schon selber mit dem Thema beschäftigt hat. Zum anderen sind die meisten Lösungen entweder eigentlich Frameworks die dazu genutzt werden müssen eigene Anwendungen zu bauen, oder nicht unbedingt einfach in selbst erstellte Anwendungen zu integrieren.
 
Auch Off Database Lösungen brauchen fast immer ein gerüttelt Maß an Einarbeitungszeit, bis sie wirklich beherrscht werden können. Und dann kommt noch dazu das Entwickler fast alle auch irgendwie Spielkinder sind. Der "Guck mal hab ich selbst gemacht" Faktor ist nicht zu unterschätzen.

Workflows werden meistens nicht von Anwendern gestaltet. (es gibt ganz wenige Tools die das können, Espresso Click & Flow, das Werner Götz geschrieben hat ist eines davon, das ich kenne), sondern von IT lern.

[eknori]

Ich sehe es auch so, wie Thomas. Jeder, der sich intensiver mit Lotus Notes beschäftigt, hat über kurz oder lang seinen "Baukasten" zusammengestellt. Und das Handling von Workflows gehört einfach dazu.
Wir hatten vor guit 10 Jahren für teures Geld Domino Workflow gekauft. Bei meinem alten AG habe ich damit eine recht anspruchsvolle Anwendung zur Online Bestellabwicklung und Warenbewegung vom Zentrallager zu Aussenlegern in ganz Deutschland entwickelt.
Bei meinem jetzigen AG reduzierte sich das Entwickeln von Workflows auf Anwendungen ala 1 Maske , 3 Views, sequentieller WF. Da brauche ich kein WF Framework, um das umzusetzen.

Ich beobachte auch immer mehr eine Verlagerung von Workflows in ERP Systeme wie SAP o.ä., wenn es um kritische Geschäftsprozesse geht.
Notes wird da lediglich als Mailsystem angesehen. Alloy könnte das ändern. Man wird sehen.

Ein paar Anwendungen habe ich mit Qenos Application Framework von OpenNTF realisiert. Dies aus der Motivation heraus, den Anwender in die Konfiguration des WF stärker mit einzubinden. Dies scheitert aber an der Motivation der Anwender ...

[JulianBuss]

danke für Euer Feedback. Ja, Lotus Workflow trifft man oft, aber das ist halt praktisch tot, wird seit Jahren nicht mehr weiterentwickelt, daher gucken sich schon einige Leute nach was anderem um.

Das mit dem eigenen Baukasten stimmt natürlich auch, für kleine Prozesse ist das sicher eine Lösung.
Bei komplexeren Aufgaben scheint es aber noch sinnvoll, die Workflow Funktionen zu standardisieren und in ein dafür spezialisiertes Tool auszulagern, oder?

However, was ich bisher gelernt habe ist, dass die meisten größeren Firmen Lotus Workflow haben und es deswegen bisher wenig Platz für Alternativ-Angebote gab.

In jedem Fall stimme ich zu, dass der Ansatz, dass Anwender WFs selbst gestalten, meistens nicht tragfähig ist. Anwender wollen fertige Lösungen, und nicht selber basteln.

[eknori]

However, was ich bisher gelernt habe ist, dass die meisten größeren Firmen Lotus Workflow haben und es deswegen bisher wenig Platz für Alternativ-Angebote gab

Ja und Nein. Wenn ich mich recht erinnere, haben wir damals so um die 80k DM auf den Tisch gelegt. Für ein Produkt, das nach ein paar Jahren nicht mehr weiterentwickelt wurde, ist das ein ganzer Haufen Geld. ROI? Denke nein. Zumindest nicht hier. Und da scheut man sich natürlich, sich nach einer Alternative umzusehen.
Und wie gesagt, die im Einsatz befindlichen WF rechtfertigen nicht die Kanone " Domino Workflow" o.ä. 

[flaite]

In großen Organisationen hat sich das stark in diese sogenannten SOA Engines verlagert. Oracle und IBM (Websphere Process Server) haben dafür angebotsportfolio-bedeutsame Lösungen. BPEL ist eine Sprache zur Beschreibung von Workflows und damit ein Standard. Diese Lösungen sind halt auch in der Administration sehr komplex und eignen sich deshalb weniger für den Mittelstand. Großer Vorteil ist, das Integration von Systemen dank messaging basierter Middleware einfach ist. Wieder: Sofern man eine entsprechende Admin-Abteilung hat. Das wird stark eingesetzt. Praktisch alle java-progger-nahen Consultants von IBM Global Services, die ich treffe, sind recht stark darauf fokussiert.

Am Ende des Tages besteht eine Workflowlösung aus Statusfeldern, authentification/authorization und zeit/event-gesteuerten Agenten. Das bieten heute allemöglichen Plattformen.

Die SOA Engines erzeugen nette Diagramme, die die Kommunikation mit den Fachabteilungen erleichtern.

Ich hab mal vor Jahren ein Workflow Notes-Framework für ein großes westdeutsches Chemie-Unternehmen geschrieben. Der Kunde und ich waren damit eigentlich recht zufrieden. Danach wurd die Organisation einmal kräftig durchgeschüttelt und die neue Kommando-Brücke hatte überhaupt keine Lust, sich mit dem bestehenden Workflow-Framework auseinanderzusetzen. Wir haben das da auch erst für 2 Lösungen implementiert. 

Domino Workflow wird nach meiner Beobachtung in etwa 20% aller Notes-Umgebungen eingesetzt. Und davon kenn ich nur 1 Unternehmen, das es im großen Stil einsetzt. Die haben allerdings ein Beratungshaus, das z.T. auf DWF spezialisiert ist... nachdem IBM Global Services das Projekt fast vor die Wand gefahren haben.

Wünschenswert wäre ein solches Framework, allerdings sollte es gut gescoped sein. Also weder zu allumfassend noch zu simpel. Dürfte schwierig sein, dafür Akzeptanz zu gewinnen, da es eine Menge an organisations- oder Consultant-gebundenen Frameworks gibt (wie Ulrich und Thomas bereits gesagt haben). 

[atbits]

Hallo Julian,

jetzt geb ich mal auch noch meinen Senf dazu.
Prinzipiell geb ich meinen Vorrednern soweit recht. Ergänzen würde ich vielleicht, das aus meiner Sicht die Modellierungs-Komponente sehr wichtig ist.

Es gibt zahlreiche WF-Engines, aber nur wenige, bei denen ich den Workflow grafisch modellieren kann und das ist denke ich sehr wichtig, einmal zur internen Doku, aber auch um mit dem Fachbereich reden zu können.

Die freien Java / BPEL Tools machen das ganz gut finde ich, Pavone Espresso auch, bei Gedys und Lotus-WF kann man über die Modellierung streiten.

Wenn sich aus der modellierung automatisch der Workflow ergibt hat man in jedem Fall den Vorteil nicht parallel entwickeln und modellieren zu müssen mit Visio oder Aris oder ....

Grüße David

[JulianBuss]

David, ich finde das mit der Modellierung völlig unwichtig für die eigentliche Engine.

Denn ich modelliere / plane meinen Prozess ja im Vorfeld, zusammen mit der Fachabteilung. Dafür nehme ich Visio oder ähnliche Tools.

Erst wenn der Prozess fertig geplant ist, setz ich mich doch an die Implementierung. Und dabei ist eine grafische UI m.E. nach eher hinderlich.

Aber hier haben sicher unterschiedliche Kunden unterschiedliche Meinungen :-)

[atbits]

Hallo Julian,

prinzipiell gebe ich Dir das Recht.
Aber es ist doch so, dass kein Workflow einmal modelliert wird und dann für alle Ewigkeiten so bleibt.

Und genau dann ist es praktisch, wenn ich nicht an 2 Stellen Änderungen machen muss, sondern eben "nur" das Workflow-Modell anpassen und das gnaze damit auch gleich dokumentiert habe.

Ich finde das äußerst praktisch, klar bei kleinen Workflows mit einer handvoll Stati ist das alles kein Problem.

Für komplexere Workflows ist das schon schick, auch wenn der Anwender dann in der Grafik sehen kann, wo er sich gerade befindet.

Dass es nicht grafisch evtl. schneller geht steht ja ausser Frage, am schnellsten wäre wahrscheinlich ein Konfig-File, aber dahin will ja keiner ;-)

Grüße David

[Thomas Schulte]

Julians Sichtweise ist so ähnlich wie das was ich immer wieder sehe. Bei der Auswahl eines solchen Tools ist die Integration einer graphischen Modellierung des Workflows ein KO Kriterium.

Benutzt, also ich meine wirklich richtig konsequent verwendet, wird es dann seltenst bis nie.
90% des Workflow Designs finden immer noch in den Köpfen der Leute statt. Wenn man wirlich mal mit jemand zusammenkommt, der soweit denken kann, das man mit ihm ein UML Modell oder auch nur ein Ablaufdiagram zeichnen kann und derjenige das dann auch noch versteht, dann ist das an und für Sich schon ein Erfolgserlebnis. Spätestens nach der fünften Kante ist für die Meisten sowieso Schluß. Da hören die dann auf mitzudenken. Und da nützt dann auch kein graphisches Tool mehr.

Was David sagt hat Gültigkeit für die Anzeige des Prozesses. Und da stimme ich ihm zu. Um dem Anwender zu zeigen, wo er gerade ist, macht eine Graphische Aufbereitung tatsächlich bei komplexeren Workflows Sinn.

[atbits]

Ja - aber es geht ja nicht nur darum den WF mit dem Fachbereich durchzugehen, sondern auch, dass es dem Entwickler als Erinnerungs-Stütze dienen kann.

Klar kann ich mich durch eine meterlange Konfiguration quälen, oder darauf hoffen, dass der Kollege das Visio-Diagramm immer schön auf Stand gehalten hat. Aber bei mehr als ein paar Workflows ist es schon hilfreich, wenn ich sicher sein kann, dass das Modell = der Implementierung ist.

Und mich da zumindest wieder grob in den WF eindenken kann.

Grüße David

[eknori]

Ich fand den Designer in DWF schon ganz schick und habe damit auch gearbeitet. Irgendwann gab es dann aber mal ein Update von 2 auf 3 glaube ich und da ist dann irgendwas fürchterlich schief gelaufen.
Da ging dann gar nichts mehr und es hat mich einen Haufen Zeit gekostet, das wieder gerade zu biegen.
Aus dem Blickpunkt Visualisierung ist so ein designer sinnvoll; auch kann er die Codegenerierung unterstützen. Wenn er aber das einzige Mittel ist, auf den erzeugten Code zuzugreifen und zu ändern, dann verzichte ich lieber darauf.
 

[atbits]

Ja das stimmt,
die grafische Modellierung darf nicht der einzige Weg sein - so wie das früher bei den UML-Tools war. Mittlerweile klappt das bei Klassendiagrammen etc. ja ganz gut, dass man sowohl im Code als auch im Diagramm was ändern kann. Das wäre natürlich dann der Stein der Weisen ;-)

David

[MadMetzger]

Hallo,

ich habe mich mal sehr intensiv mit dem Thema auseinander gesetzt und daher relativ konkrete Vorstellungen, was ich von einem "guten" Workflow-System erwarte. Bisher kenne ich aber nur Systeme aus der Java-Welt, von denen jedes irgendwo seine Schwächen hat. Bisher habe ich erst ein System kennengelernt, dass "meinen" Vorstellungen relativ nahe kam. Und das war eben ein kommerzielles System, mit dem ich auch aktuell im Beruf zu tun habe.

Für mich gehören zu einer guten Workflow-Management-Lösung verschiedene Dinge außer grafischem Editor und Prozessvisualisierung. Wobei aber eben gerade der grafische Editor vermutlich unerlässlich ist, wenn man damit näher an die Fachabteilung rücken möchte mit der IT. Eine Alternative würde ich hier nur in einer handlichen DSL sehen, die Prozessmodelle beschreibt, was aber evtl von der Fachabteilung evtl zu sehr als "Programmieren" angesehen werden könnte und dann eher weniger Akzeptanz finden würde.

Ebenso wichtig ist aber in meinen Augen auch, dass man laufende Prozessinstanzen zu einem Prozessmodell zur Laufzeit verändern kann. Das kann eine Änderung auf Prozessmodellebene, aber auch das "Weitergeben" einer Aktivität sein. Genau für diesen Zweck ist gerade eine gute Visualisierung sehr sinnvoll, da, wie schon oben gesagt, eine laufende Instanz grafisch besser zu beurteilen ist, als wenn man etwa eine textuelle Repräsentation wählt.

Abseits dieser Komponente halte ich es für ebenso wichtig, dass das System in der Lage ist, sich mit einer bestehenden Oberfläche zu integrieren. Das bedeutet, dass die Engine für eine bestimmte Aufgabe in der Lage ist, dem Benutzer die vermeintlich adäquateste Benutzeroberfläche mit den "richtigen" Daten zu präsentieren. Beispielsweise ist es sinnvoll, wenn ein Vorgesetzter eine Aufgabe "Urlaubsantrag von X Y bearbeiten" auf seiner Agenda hat, dann sollte er bei Beginn dieser Aufgabe genau den Urlaubsantrag in einer angemessenen Ansicht angezeigt bekommen.