第 5 章: プロセス設計方法論 - マシンの奴隷になるか、破損を引き起こすか
文書概要
1. プロセスの性質
2. プロセスの要素
1.駆動力モード
2. タスクとステータス
3. ノード
(1) 検証の仕組み
(2) 拒否機構
4. 監視機構
3. プロセス設計パターン
1. ステータス重視（誰でもできる、物事に集中する）
H2. ノード指向 (誰もができるわけではない、人間中心)
3. 状態指向かノード指向か、これは問題です。
4. プロセスモデル
1. アローモデル
2. スタックモデル
(1) スタック モデルには 2 つのタイプがあります。
(2) フィードバックの仕組み
3. プールモデル
4. モデルの混合使用
5. 多層プロセスの設計
1. 単一タスク、多層ステータス
2. 単一のメインタスク、複数のサブタスク
3. 多層プロセス設計のどちらの方法にも、それぞれ独自の長所と短所があります。
ここ数年、私は中国の大手インターネット企業で働いていました。当時、同社では業務連携を実現するために業務命令システムを採用していた。当時は今と違って、コラボレーションツールがたくさんありました。したがって、私は作業命令システムについて注意深く研究しました。
私がプロセスの設計と管理に焦点を当て始めたのはその時でした。
その後数年間、私は多くのプロセス製品を作り、さらにはプロセス エンジンも作りました。
ここ数年、私はこれらのプロセスベースの製品を具体的にレビューし、最終的に独自のプロセス設計方法論を開発しました。
多くの方法論ほど抽象度は高くないかもしれませんが、シンプルで実用的であるよりは優れています。少なくともほとんどのプロセスの設計では、基本的にそのまま使用できます。
1. プロセスの性質
プロセスの本質は、物事の状態を順序付けることです。
特定の基準に従って、あらゆるものに一連の状態をマークできます。これらの状態の順序付けによりプロセスが形成されます。
2. プロセスの要素
1.駆動力モード
パッシブモードとアクティブモード。
どのプロセスの動作にも独自の推進力があります。
パッシブ モードの駆動力は前のプロセス ノードから得られます。つまり、前のノードが次のノードを駆動します。 (簡単に理解すると、タスクは前の実行者から次の実行者に転送され、次の実行者はそれを受動的に実行します。)
アクティブ モードの駆動力はプロセス ノード自体から得られ、これは自動駆動と呼ばれます。
さまざまな駆動力モデルによって、プロセス設計時にプロセス モデルを選択する方法が決まります。
プロセス設計では、プロセス全体の駆動力モデルを考慮する必要があります。そうしないと、設計したプロセスが「使い物にならない」、「無理がある」、「面倒すぎる」ものになってしまう可能性があります。 。 。 。 。 。
アクティブ モードとパッシブ モードは同じプロセス内で混在できます。それは主に、特定の状況やシナリオによって異なります。
2. タスクとステータス
プロセスの流れには、プロセス全体を調整するステートフルなものが必要であり、これがタスクです。タスクの状態が規則的に変化することでプロセスが形成されます。
タスクには、文書、チケット、注文書、作業指示書、カードなどが含まれます。
プロセスにはタスクを 1 つだけ含めることができます。または、メイン タスクが 1 つだけ存在し、プロセス内で実行するために複数のサブタスクに分割することもできます。
3. ノード
ノードはエグゼキュータです。
つまり、各タスクのステータスの特定の実行者です。それは人、プログラム、機械などです。
ノードは 1 つの状態のみを実行することも、複数の状態を実行することもできます。これは主にプロセスの設計パターンに依存します（詳細は後述の「3. プロセスの設計パターン」を参照）。
各ノードにおいて、状態の切り替えは必ずしもノードの切り替えを伴うものではないが、ノードの切り替えには必ず状態の切り替えが伴う。これはプロセス設計の原則と考えられます。
ノードの切り替えごとに、対応する検証メカニズムと、使用される可能性のある拒否メカニズムが必要になります。
(1) 検証の仕組み
ノードが変更されるたびに検証が実行されます。
- 事前検証:
ノードを切り替える前に現在のノードの実行結果を検証し、検証に合格したら次のノードに切り替えるものもあります。
- 検証後:
ノード切り替え後、前ノードの実行結果が検証され、検証を通過できない場合は拒否機構が実行されます。
(2) 拒否機構
プロセスの検証メカニズムが検証後である場合、拒否メカニズムが存在する必要があります。拒否機構とは、前ノードが投入したタスクが不適格であることを検証し、前ノードに返す機構である。プロセスを設計する際には、具体的な検証基準、仕様、返品方法、拒否の処理方法などをすべて考慮する必要があります。
4. 監視機構
すべてのプロセスには監視メカニズムが必要です。調節メカニズムには主に 2 つのタイプがあります。
- 記録管理の監督
最も単純かつ基本的な監視機構は、タスクの実行過程、つまりタスクの状態の変化や各状態の属性や実行結果を記録することである。何か問題が発生した場合、原因を追跡できます。
- リアルタイム監視
プロセスの各ステータスの実行をリアルタイムで監視し、違反が見つかった場合は直ちに介入します。
3. プロセス設計パターン
1. ステータス重視（誰でもできる、物事に集中する）
これは比較的一般的です。ステートに重点を置き、ノードに重点を置きます。私たちが見たり行ったりするプロセスのほとんどは、このようなデザインパターンです。
最初に何かを実行して特定の状態を取得し、次に何かをもう一度実行して特定の状態を取得し、次に画像認識を使用して特定の状態を取得し、次に再び何かを実行して特定の状態を取得します。 。 。 。 。 。
プロセス内のすべてのノード (人、プログラム、マシンなど) は 1 つのこと、つまり機械化されたステップを中心に展開し、固定されたルールに従って責任のあることを実行します。
それは「組立ライン」と考えることができます。
2. ノード指向 (誰もができるわけではない、人間中心)
これは比較的まれです。状態は軽く、ノードは重い。
最初に誰にタスクを与えて、どのような結果が得られ、次に誰に、どのような結果が得られ、次にどのマシンにタスクを与え、どのような結果が得られ、次に誰に、どのような結果が得られるか。取得できる。 。 。 。 。 。 。
一般に、ノードの出力結果が大きく異なる非標準化された状況、または緩い組織やプロセスでの使用のみが考慮されます。
インターネット商品の中では珍しいです。現在、主に一部のコラボレーションオフィス製品で使用されています。
3. 状態指向かノード指向か、これは問題です。
おそらく神が存在するのは、この世界が不完全だからだろう。
プロセスの設計は、状態指向であってもノード指向であっても、完全に完璧なプロセスを設計することはできません。
究極の状態に直面すると、人間は最終的にプログラムと機械の奴隷になるでしょう。
ノード指向であると、権力の集中と腐敗が起こりやすくなります。
したがって、最終的に、プロセスでどのようなデザイン パターンを使用する必要があるかは、特定のビジネス シナリオによって異なります。ふさわしいものが一番いい。