ワークフローツールの価値は何ですか？[閉まっている]

私はワークフロー開発に不慣れであり、「全体像」を実際に得ているとは思わない。あるいは、別の言い方をすれば、これらのツールは現在私の頭の中で「クリック」していません。

そのため、企業はプロセスを説明するビジネス図面を作成するのが好きで、ある時点で誰かがプログラムのようなステートマシンを使用して、図のような線やボックスからプロセスを実際に制御できると決めたようです。10年後、これらのツールは巨大で非常に複雑になりました（私の会社は現在WebSphereで遊んでいます。私はトレーニングに参加しました。巨大で複雑ですが、WebSphereである獣ほど複雑ではありません）。

この方法で行うことの大きな利点は何ですか？単純な線図とボックス図が有用であることはある程度理解できますが、これらのことは、私が知る限り、この時点では条件とループを備えた視覚的なプログラミング言語です。ここのプログラマーは、ラインとボックスのレイヤーでかなりの量の作業を行っているように見えますが、私にとっては、本当にくだらない、本当に基本的な視覚プログラミング言語のように見えます。

そこまで行くなら、なんらかのスクリプト言語を使用してみませんか？人々はこれでお風呂の水で赤ちゃんを投げ出しましたか？線と箱のことはばかげたレベルになっていますか、それとも私はこのすべての価値を理解していないのですか？

この技術を使って働いた人々がこれを擁護する議論を見て、なぜそれが役に立つのかを理解したいと思います。私はそれに価値を見ませんが、私もこれに慣れていないことを認識しており、まだ十分に理解できないかもしれません。

開発者の観点からは、これらの「視覚的」環境を扱うのは本当に難しいと言うのは正しいことです。私が使用しているSharePoint 2010ワークフローは、優れたエンタープライズソフトウェアの作成に関するベストプラクティスをすべて捨てています。自動化されたテスト、コードの再利用、読み取り不可能なソフトウェアはありません。 、あなたが経験しているように。

しかし、ビジネスの観点から見ると、ワークフローには、少なくとも理論的には大きなメリットがあります。このホワイトペーパーから引用すると、自動化されたワークフローの効率、説明責任、管理、および使いやすさにより、生産性が大幅に向上します。この自動化がなければ、単純な承認またはオンボーディングプロセスがどれほど非効率になるか想像してみてください。また、ワークフローを定義するまさにその行為は、ビジネスプロセスを制御しようとしている組織にとって価値があります。

ワークフローソフトウェアの現在の状態は、ビジネスのせいではありません。彼らは単に生活を楽にしたいだけで、そのためにはワークフローが最適です。私は主にIT部門を非難します。

1. システムが実際にどれほど複雑で壊れやすいかについて、ビジネスに対してより透明性を持たないため。すべての複雑さを隠しています。
2. 直感的でシンプルなワークフローソリューションで「かゆみを掻く」ことができないため。これはおそらく、SharePointやSAPのような大規模なエンタープライズパッケージに対する暴言のようですが、カスタムソリューションよりも優れています。

本当のメリットは1つだけですが、その大きなメリット は「懸念の分離」です。

したがって、システムにプロセスオーケストレーションロジックが埋め込まれる代わりに、外部構成になります。基本的に地図。それを（はるかに）独立して変更でき、複数のプロセス、複数のバージョンのプロセス、複数のプロセスの複数のバージョンを同時に実行することができ、それはまともなソリューションですぐに使用できます。

歴史的に、SoCの概念は何度も勝ちました-Unixの原則から始まって、「良いことをしてください」、何度も適用されます-ESBのような専用サーバーコンポーネント、異なる永続システム、キャッシング、負荷分散、監視、HTMLからCSSの分割など。

多くの場合、ビジネスプロセスとそのフロールールは、データ、UIの「画面」、またはユーザーの「階層」と直交しています。したがって、システムの他の側面とは別に開発および変更することは完全に理にかなっています。これが、1990年代初頭にBPMが登場した前提でした。

それ以来、この概念をサポートするために多くのツールと言語が作成されました。最もよく知られているのは、プロセスに直接マップする「フローチャート」を作成するためのグラフィカル言語であるBPMNです。大きくて扱いにくい（語彙に100を超える記号がある）ことや、S-BPM（基本記号が5つしかない）などの現代的なアプローチを支持していると人々は不満を述べていますが、現在の業界の慣行は、BPMNまたはその派生物、サブセット、兄弟に固執することです。

あなたはBPMNに満足していないようです：

ここのプログラマーは、ラインとボックスのレイヤーでかなりの量の作業を行っているように見えますが、私にとっては、本当にくだらない、本当に基本的な視覚プログラミング言語のように見えます。

しかし、それほど悪くはありません）その背後には理論があります。また、バージョン2.0は1.0の欠点からいくつかの優れた洞察を得ました。

そこまで行くなら、なんらかのスクリプト言語を使用してみませんか？

命令型パラダイムとスクリプト言語が常に最良の答えとは限りません。おそらく宣言型言語（HTML、CSS、SQL、Drools、またはNginx、Gradle、Maven、Puppetなどの内部言語）で見たように、結果のコードは、「まともな言語」で書かれたバージョンよりもはるかに小さく、きれいになります。 JavaやC ++など。

あなたの他の点に関して：

私が知る限り、この時点でのビジュアルプログラミング言語は、条件とループを備えています。

イベントとトリガーについて調べましたか？BPMNは言語であり、使用する前に習得するか、少なくともそれに慣れる必要があります。

内部では、BPMNはXMLであるため、手で編集したり、生成したりできます。また、XMLはテキストベースであるため、バージョン管理できます。ただし、フローチャートに変換できるXMLを持っているだけで、その助けになるとは思えません。それは正しいことです。独自のパーサーまたはエディターを作成することは、疑わしい利点を持つ困難で費用のかかる作業です。

幸いなことに、市場にはすでにそれを実現するツールがあります。

Activitiは無料で、初期価格（ゼロ）、情報の入手可能性、謙虚さから、開発者とビジネスオーナーの両方に非常に人気があります。最後の点は本当にユニークです。Activiは、パッケージ全体のソリューションに結び付けようとせずに、ビジネスプロセスの管理にのみ焦点を当てています。また、そのオープン性-そのため、JavaとRESTを知っていれば、Javaを起動して実行できます。欠点は、クライアント側、統合、アプリケーション/ビジネスロジック、およびアーキテクチャ全体が開発者に委ねられているため、開発チームが弱い場合は失敗に備えることです。無料ツールの場合、総所有コストは驚くほど高くなる可能性があります;）

スペクトルの反対側にあるペガ（ペガPRPC）は、BPMシステムの支配的な王（ガートナーとフォレスターによる）で、その年齢には驚くほど良さそうです。この巨大なキッチンシンクは、CRM、OCR、および音声認識機能、予測分析、ビジネスルール管理、WYSIWYG UIエディターの機能さえ備えています。ただし、深刻な値札が付いています。莫大な費用がかかるだけでなく、すべての開発はWebアプリ内で行われます。つまり、IE8（およびいくつかのプラグインに加えて、データテーブルの編集にExcelを使用するようなeditingいハック）を使用する必要があります。また、Java、Javascript、またはHTML / CSSの編集もWebブラウザーを使用して行われています。ユニットテスト、IDEコードの強調表示、リファクタリング、そして大好きなプログラミングおもちゃに別れを告げましょう。

それの良い面は？複雑なシステムをすぐに実装できます[ PDF、ページ22を参照]。そして、はい、結果は保証されません。

IBMは最近（企業のペースで）Lombardiを購入し、現在非常に競争力のあるソリューションを提供しています（しかし、すべてをibmで購入する必要があります）。Appianは若いベンダーであり、興味深い洞察と肯定的なフィードバックを持っていますが、それらの記述方法（視覚的な言語に加えて2つの追加のDSL言語）は、私にとって魅力的ではありません。

他のプレーヤーとそのソリューションがあります。それらのほとんどは明白です。たとえば、目、脳、心臓は、単に見ただけで文字通り出血します。だから、あなたの勇気を信頼し、あなたの開発者とユーザーがあなたを嫌わないようにしてください。

閉会メモ：

BPMシステムは、Photoshopが画像に使用するものと同じです。その視覚的なことを恐れないでください。それに適さない仕事をさせないでください（編集が不可能に近い、Photoshopで完全に作成されたWebサイトを思い出してください）。シンプルに保ち、バグを作らないでください;）

数年前、私たちのほとんどが生まれる前に、ソフトウェア開発者はデータを保存するために独自のコードを書く必要がありました。プログラムの状態を保存する必要がある場合、それはコードの機能の一部と見なされていたため、多くのソフトウェア開発者はデータを整理して保存および読み取りなどを行うコードを書くことになりました。

そして、誰かがこれが頻繁に起こることだと気づきました-データを保存、整理、読み取り、検索するロジックは、実際には非常に一般的に使用されるコンポーネントであり、それ自体のコンポーネントである必要があります。そして、データベースを入手しました。

過去10年から15年の間に、IT部門は、ビジネスプロセスの振り付けやオーケストレーションのロジックが非常に一般的であるため、それが独自のコンポーネントであることを認識しており、あらゆる種類の異なるワークフローツールにつながっています。

ワークフローツールには3つの主な利点があります。

1. 変更を加えて展開するのに必要な時間：コードを変更するのと同じ技術的リスクなしに、ワークフローのロジックを開発および変更できます。
2. 透明性：BPMベースのシステムのビジネスロジックは、ビジネスアナリストがすぐに利用でき、読み取ることができますが、開発者だけが「コードベース」システムのビジネスロジックを読むことができます。
3. 技術コンポーネントの再利用：BPMツールは、多くの場合、サービス指向アーキテクチャを備えたシステムと組み合わせて使用​​されます。特に数百または数千の異なるビジネスプロセスを実装する必要のあるエンタープライズシステムの場合、ビジネスロジックを技術コンポーネントから分離することにより、ビジネスロジックの開発に比較的少ない時間を費やしながら（ワークフローを使用して）技術コンポーネントを再利用できますツール）。

ただし、ワークフローとBPMツールの使用で遭遇する最も一般的な問題の1つは、開発者がビジネスロジックを非透過的なコードに「埋める」ことを試みていることです。

私がいつも目にするのは、開発者がビジネスロジックを可能な限り最も透過的な方法ではなく、可能な限り最も技術的な方法で追加しようとしていることです。開発者はその性質上、ワークフローツールよりもコードにはるかに慣れているため、これは自然なことです。さらに、技術的な方法で保持するロジックが多いほど、開発者として必要なものが増えます。残念ながら、これは開発者がBPMシステムに対して行うことができる最悪のことです。なぜなら、彼または彼女はBPMを使用することの主な利点を損なっているからです。

最後に、ほとんどのBPMツールは、ビジネスアナリストがワークフローを自分で開発できるほど十分ではありませんが、それが目標です。理想的には、ビジネスアナリストはワークフロー/ビジネスプロセス図を開発し、開発者はワークフローエンジンによって呼び出される技術的なコンポーネントでのみ作業します。

以下のステートメントは、ワークフローツール、特にOracle BPM Suite（10.3Gおよび11G）を使用した私の個人的な経験です。最初に指定するのは、実行可能なプロセスモデルのモデリングを可能にするワークフローツールです。これらのツールはビジネスプロセス管理システム（BPMS）の一部です。この特定のプロセスモデリングは間違いなく開発中であり、ビジュアルプログラミング言語と呼ぶことができます。

主な利点は、プロセスロジックの理解と変更の俊敏性です。

ビジネスプロセスモデルを使用すると、プロセスロジックの視覚的な説明と同時に、実行可能な統合コンポーネントをカバーできます。これにより、開発の一部であるため、移行、条件（ゲートウェイまたはビジネスルール）およびプロセスフロー全般に関するドキュメントの作成が少なくて済むため、プログラマのオンボードおよびオフボードを迅速に行うことができます。

さらに、アプリケーションごとに個別に開発する必要のあるレポート/監視機能を添付しています。これはほとんどのBPMSでカバーされています。

さらに、ほとんどのBPM開発環境では、サービスアダプターが事前に構築されており（たとえば、JMS、Webサービス、JDBCなど）、段階的な対話型統合でミドルウェアソリューションをより迅速に開発し、コーディングの人的エラーを減らします。

次のワークフロープラットフォームは、上記の多くの利点を実現します- ワークフローの自動化のためのプラットフォームベースのアプローチ

値

価値提案は、ビジネスの変化する性質に合わせて、ワークフローを迅速かつ簡単に作成または変更できることです。この価値命題を実現する重要な部分は、ビジネスプロセス自体がシステム内のリソースの単位であることです。

リソースの単位としてのワークフローは、ビジネスプロセスが単一の「単位」として定義されることを意味します。これが意味することを理解するために、ビジネス用に作成されたコンピュータープログラムを検討してください。確かにビジネスプロセスを実装しますが、そのプロセスのロジックは、ソースコード全体にある程度広がる可能性があります。ワークフローツールを使用すると、1つの適切な場所でプロセスを定義できます。単一の構成ファイルにある場合もあれば、1つの視覚的な図から抽出されている場合もありますが、ワークフローはプラグイン可能なコードの単一モジュールにあり、その場でスワップまたは構成することもできます。

価値が実現されない理由

この価値命題は、バニラ以外のケースをカバーすることの難しさ、非常に急速に変化するUIテクノロジー、ワークフローツールをラッパーとしてのみ使用する、コードを実際のロジックに配置するなどの悪い習慣と統合することの難しさによって損なわれます。

ツール自体の不十分な設計が制限要因になる場合があります。例としては、プロセス間で渡されるすべてのパラメーターがJavaマップにあることを必要とするツールがあり、単純な古いメソッドパラメーターの代わりに、実際にマップに置くことができる値に制限があります（私は、特にこれを行う一般的なツール）。

IBMは、大規模なテクノロジーエコシステムを備えた大企業であり、他の企業よりも優れていると言っても過言ではないでしょう。UIテクノロジ、およびワークフローツールと組み合わせて使用​​されるデータベースとSOAテクノロジも制御する場合、うまく統合され、実際に活用する機会を生み出すエコシステムを思い付く可能性が高くなります。このアイデア。

ワークフローツールとシステムの他の部分との間のインターフェイスを記述する努力は、価値提案全体を完全に無効にする可能性があることは間違いありません。物事を行うより良い方法があるかどうかを常に検討する価値があります。

プログラミングはワークフローです

真実は、プログラミング（少なくとも命令型言語での）は既にワークフローです。システムテクノロジの処理に関連するワークフローを実装するコードがある場合があります。ファイルへのアクセスとSQLクエリの実行など。ビジネスワークフローを実装するコードがある場合があります。たとえば、ドキュメントの状態を設定してレビューアに渡す。

これを認識し、これらの個別の懸念事項をきれいに分割するようにコードを設計することは、完全に解決するのは困難ですが、それを行うことで確かに長い道のりを得ることができます。

私はあなたに同意します。他の誰かがそれが良いアイデアだと判断したので、時々これらのツールを使うことになります。常にそうだとは思いません。価値があるかどうかを判断するために慎重に検討する必要があります。

使用しているツールは明確ではありません。ビジネスプロセスモデリングツールと呼ばれる一般的なツールセットを参照しているのではないかと思います。そのようなツールを使用する正当な理由があります。質の高いビジネスは、プロセスとアナリストの観点からその機能を定義し、ビジネスの専門家はそのようなプロセスを快適に引き出すことができます（標準と結びつけるまで）。このようなプロセスは、Webプログラミングの知識がなくても概念レベルで作成できます。適切なツールがあれば、プロセスを実際のアプリケーションに変換することもできます（この魔法が実稼働に入るには、経験のある人が参加する必要があります）もちろん）。だから、アイデアは良いです。

視覚ツールの目的は、プロセスの文書化だけではありません。ツールの使用は、プロのリエンジニアリングプロセスを支援することを目的としており、時にはシミュレーションを実行して、プロセスが必要以上に効率が悪いポイントを発見し、計画を立ててボトルネックを取り除くことができます。

BPMN 2.0（Business Process Modeling Notation）と呼ばれる、今日多くの企業が使用している標準的な方法があります。ツールで使用している場合は、この表記法を理解することをお勧めします。

知識のビジネスプロセス管理機関は、あなたが同様に検討する必要がありますことを、有名な資源です。

上記はビジネス側をカバーしています。技術的な面ではSOAとBPELが必要ですが、ここや今のところそれらについてアドバイスできるかどうかはわかりません。

履歴による簡単な例。

石器時代

最初は、小さなメンヒル会社があり、そこで人々はどこで何をすべきかを指示し、彼らはそれをしました。時には物事が間違ってしまい、XまたはYの人が非難された（実際に誰がそれをしたのかはわからない）。

次のインターネットとメールが発明されました。

人々は今、他に何をすべきかを書きました。そして、それらの人々はしばしばメールに問題があったり、間違って読んだり、単に読んだりせずにメールを削除したりしました。頻繁に悪いメールを非難しないこと

ワークフローは管理から進化しまし たアクションを標準化することで、最終的に、プロセスを停止したフェーズをユーザーが確認できると同時に、実際に行われたことのデジタル概要を把握できました。これは、人々が標準プロセスを変更するまで、または未知のXYの人物が不適切なデータベース要求を引き起こしてデータベースの破損を引き起こし、生産を石器時代に戻すまで、うまくいきました。