ワークフローとは何か

ワークフローは、マイクロフローに比べて高い抽象レベルでプロセスを定義する方法です。組織内で定期的に実行される一般的なビジネス プロセスを管理および拡張する方法です。Studio Pro 内のマイクロフローと見た目は似ていますが、通常は数時間から、まれに数年にわたる期間にわたってユーザーまたはシステムによって実行されるタスクに重点を置いています。タスクに重点を置いているため、各タスクとワークフローの全体的な状態を細かく制御できます。

ツールボックス内のさまざまなツールを使用してこれを実現します。これらのツールを使用すると、手順をスキップしたり、他の人が実行を完了したことを確認してから次のステップに進むことができます。

また、通常とは異なる状況が発生した場合は、独自のマイクロフローを使用してツールボックスを拡張し、新しいワークフローをトリガーして、変化するシナリオに迅速に適応することもできます。

これらすべてはマイクロフローで可能ではないでしょうか?

はい。これが長い間私を困惑させた原因です。マイクロフローですべてを実現できる一方で、ワークフローは関係者全員にとってプロセスをより良くするだけという場合もあります。

ワークフローを使用せずにプロセスを構築することは可能ですが、すべてを手動で構築するには、プロセスが効果的に管理されるようにするための慎重な計画と追加の労力が必要です。マイクロフローのみを使用して状態の管理、通知の送信、セキュリティの処理、ナビゲーションなどを行うと、同様の結果を達成できますが、ワークフローを使用する場合よりも複雑さが増し、すぐに使用できるサポートが少なくなります。

この複雑さにより、混乱した状態が生まれ、プロジェクトで一緒に作業する他の人や、将来アプリケーションを保守する必要がある人にとっては理解しにくくなります。ワークフローはプロセスを順番に明確にレイアウトするため、自己文書化のようなもので、多くのステップにまたがるプロセスを明確に文書化する簡単な方法です。ワークフローによって開発時間を節約できるかもしれませんが、最も大きなメリットの 1 つは、ワークフローを使用して構築されたアプリの保守にかかる時間を節約できることです。

ワークフローが適切な場合

ワークフローが必要なとき、または役立つときについては、他にも考慮すべき点がいくつかあります。

ワークフローは、長期間にわたって実行され、通常は多くのステップがある大規模なプロセスを定義して概要を示す場合に最適です。良い例としては、保険やその他の種類の契約の見積もりを取得することが挙げられます。最初の連絡、情報収集、見積もりの​​作成があり、その後、顧客は申し込みを完了する前にオファーを承諾または拒否する必要があります。これは、人間のタスクとシステムのタスクの両方を含む、明確に定義されたプロセスです。

また、このプロセスは頻繁に変更されることはありません。時間が経つにつれて、会社がさまざまなオプションや新製品を提供する場合もありますが、見積もりを取得してそれを受け入れるプロセスは劇的に変わることはありません。

システム タスクとユーザー タスクが混在する場合も、ワークフローの使用を検討する必要があります。保険契約の例では、顧客は特定の免責事項とコンプライアンス ドキュメントに同意する必要がありますが、これらは通常、電子メールで送信されます。ユーザーまたは顧客からのアクションを待機するシステムからの電子メールのトリガーは、ワークフローに組み込まれた並列分割および待機機能を使用して簡素化されます。

また、プロセスを自己文書化することで、プロジェクトを開いた人なら誰でも簡単に理解できる明確な意思決定ツリーを作成するという利点もあります。

ワークフローを使用しない場合

上記の基準に準拠していないからといって、ワークフローの使用が直ちに不適格になるわけではありませんが、警戒すべき点がいくつかあります。ただし、ワークフローを使用すべきではないことを示す明確な指標がいくつかあります。

• 将来プロセスが変わる可能性がある場合。予期しない結果をもたらす予測不可能な作業の性質は、ワークフローの枠にうまく当てはまりません。
• プロセスが予測不可能で、正しい結果を達成することに重点が置かれている場合、ワークフローの硬直性により、さまざまな結果に対応できなくなります。明確な目標または目的地を設定することが望ましいです。
• ユーザーが最適なパスを決定するために高い自由度を必要とするプロセスは、ワークフローの厳しい制約にうまく適合しない可能性があります。

要約すると、頻繁に繰り返され、ワー​​クフローで概説されている標準プロセスから逸脱しない予測可能なプロセスには、ワークフローを使用するのが最適です。

排他的ではない

ワークフローに対する私の考えが変わった最大の理由は、ワークフローはどちらか一方ではないと気づいたことです。アプリケーションには両方を含めることができ、また含めるべきです。自分のアプリはニッチで、枠にはまらないと思うかもしれませんが、すべてのアプリには一般的なプロセスがあり、ワークフローで簡単に定義できます。より複雑な部分については、マイクロフローが常に選択肢となります。

再び保険見積もりの​​例を挙げると、保険に加入している人なら誰でも、そのプロセスがどのようなものかは知っています。エージェントは時間をかけてお客様の詳細を収集し、ライフスタイルやリスクについて質問し、お客様の詳細を提出して引き受け、提示された見積もりを承認または拒否してから、取引全体を確認および文書化するメールを送信します。これらは、ユーザーベースのタスクとシステムベースのタスクが明確に混在する、変更されない明確な手順です。このプロセスは通常、完了するまでに数分から最大 1 時間かかり、ユーザーがシステム外でタスク (アカウントを確認するためにメールを開く) を実行するためにアプリケーションをしばらく離れる必要がある場合があります。

完全にカスタム化されたソリューションを構築することもできますが、プロジェクト内にすぐに数百のドキュメントが生成されます。これは、いくつかの慎重に作成されたマイクロフローを散りばめた単一のワークフローに簡単に置き換えることができます。ワークフローのみを使用してアプリ全体を作成する必要はありませんが、ワークフローに置き換えることができる明確なプロセスを見つけることで、自分自身や他のユーザーがプロジェクトを管理しやすくなります。開発中と開発終了後の両方で時間を節約できます。この場合、マイクロフローとワークフローの両方に用途と利点があり、両方を含めないと、より優れたアプリケーションを作成する機会を逃すことになります。

私が変化に抵抗した理由

私がワークフローを避けた理由は、ワークフローが何であるかを誤解していたからだと思います。ワークフローはマイクロフローを直接置き換えるものではなく、複雑なプロセスを大規模に整理するためのより効率的な方法です。ワークフローはマイクロフローを置き換えるものではなく、ビジネス プロセスをサポートするためにマイクロフローを使用する方法のフレームワークと構造を提供し、プロジェクトの将来の保守と変更を容易にします。ワークフローは効率性を向上させることを目的としていますが、最も効率性が向上するのはプロジェクトの初期開発後であり、主にプロセスを合理化し、後続の開発者にとって読みやすくすることです。

私が構築したアプリのいくつかを振り返ってみると、ワークフローを使用することを選択していたら、自分と他の人の時間を大幅に節約できたはずです。いつもと同じ方法で突き進むのではなく、何か新しいことを理解するために時間を費やす方が理にかなっている場合もあります。