問題の声明
簡単にするために、企業が構造的に2つのレベルに分割されていると想像してください。 （一般的な場合、レベルは任意の数にすることができます）。
企業レベルでは、次の作業が実行されます。
- 企業全体の要件が策定され、外部条件によって課される制限が特定されます。
- 企業の生産能力が決定されます。
- 企業の戦略的目標と現在の計画（タスク）が策定されます。
- 企業のジョブは、部門のジョブに分解されます。 これには、個々のユニットの機能が考慮されます。
- タスクはユニットに転送されます。
ユニットレベルでは、次の作業が行われます。
- ユニットのタスクは、実行可能性が検証されます。
- 検証が成功した場合、ユニットのタスクはエグゼキューターのタスクに分解されます。
- 実行者はタスクを実行します。
- これらのタスクの進行状況が分析されます。
- ユニット全体のタスクの進捗状況が分析されます。
- 完了した操作は、実行者のレベルとユニット全体のレベルの両方で分析されます。
- 収集された事実に基づいて、各請負業者の生産能力が決定されます。
- 補強が必要なボトルネックがあります。
- ユニット全体の生産能力が分析され、これに関する情報が企業レベルに転送されます。
エンタープライズレベルでは、作業が継続されます。
- 実際の作業の進捗に関する情報が受け入れられ、分析されます。
- ユニットの実際の機能が調査されます。
- この情報は、ボトルネックとそれらを強化する可能性を識別するために使用されます。
- 同じ情報を使用して、企業全体の生産能力を判断します。
したがって、各構造単位では、次の作業を実行する必要があります。
- 上位構造レベルのタスクからの着信を検証します。
- 計画された作業の計画シナリオを作成します。これは、作成者の意図に従って、上位構造レベルからのタスクの実行につながるはずです。
- 計画を検証し、それに基づいて特定の実行者に割り当てられたタスクを作成します。
- タスクを完了します。
- 実行された作業の結果を分析するには;
- 得られたデータに基づいて、計画された作業を調整し、これらの変更を隣接するユニットと上部構造ユニットの両方と調整します。
- 各請負業者の生産能力に関する知識を維持します。
- 生産性を高めるために、ボトルネックを見つけて「拡大」します。
- 構造単位全体の総生産能力を計算します。 これに関する情報は、隣接するユニットと上位レベルの両方に送信されます。
IT部門にタスクを任せます。次の機能を自動化する必要があります。
- 典型的なスキームに基づいたモデリング操作とシナリオ。
- 結果と計画との比較。
- 計画の調整。
はじめに
通常のワークフローエンジンの使用がこのような問題の解決に適していない理由を説明したいと思います。 制限事項があります。
通常、作業計画は多くの「キャスト」を通じて行われます。各「キャスト」は将来の作業のシナリオです。 各シナリオには、時間軸上に配置され、次のような論理条件で相互接続された多数の計画された操作が含まれます。
- 操作3の完了後、操作5が開始されます。
- 操作5の結果は、操作6で補助ツールの役割を果たします。
個々のシナリオとサンプルシナリオには違いがあります。 それらの違いを説明するために、私は建設プロジェクトとの類推に頼ります。
事例紹介
あなたがあなた自身の家を建てることを計画していると想像してください。 そのような建設には、プロジェクトが必要です。 プロジェクトは設計組織によって行われます。 あなたは設計組織の将来の家のプロジェクトの開発を注文します。彼らはあなたに尋ねます：あなたは標準プロジェクトを開発しますか、それとも個人ですか？ 同時に、典型的なものは20,000ルーブル、個々のものは200,000、つまり桁違いに高価です！ この質問に答えるには、典型的なプロジェクトが個々のプロジェクトとどのように異なるかを知っておく必要があります。
違いは、標準プロジェクトが特定の条件に適合していないことです。 特定の条件は、（地質学と地形を含む）です。 たとえば、砂地の斜面で30度の斜面が洪水で浸水した。
標準設計に示されているように、ストリップの基礎にある家がそのような斜面に建てられていると想像してください。 彼が長い間アイドル状態にならないことは明らかです-彼は洗い流されます。 そのような家を長い間立てるためには、山の上に置く必要があります。それは、母親のベースに接するのに十分な深さで、砂の滑り層の負荷に耐えることができる頻度で叩かなければなりません。 個々のプロジェクトを注文した場合、設計組織がそのような基盤の計算を行います。 標準プロジェクトは典型的な条件に合わせて設計されているため、典型的なプロジェクトでは杭の基礎は見つかりません。
プロジェクトで、スラブを埋めるコンクリートの砕石部分として、フラクション20〜50の花崗岩砕石を使用する必要があることを示してください。 しかし、地元の生産者は石灰石だけを供給する準備ができています。 花崗岩の瓦bleの購入は信じられないほど高価です！ 質問：花崗岩の砕石を石灰岩に置き換えることは可能ですか？ 現地の状況を知っている設計組織は、許容荷重を読み直して材料を交換し、厚さ30 cmではなく、厚さ30 cmのコンクリートとの重なりを注ぐことを提案できます。 したがって、より安価な質問が発生します。花崗岩の砕石を持ってくるのですか、それとも基礎のコストが上がるのですか？ 個々のプロジェクトを注文する場合、これらの質問は請負業者によって尋ねられます。 彼も彼らに答えを与えます。 標準プロジェクトを購入する場合は、これらの質問を自分で尋ね、自分の危険とリスクで解決する必要があります。
あなたがかなり経験豊富なビルダーであり、典型的なプロジェクトの調査を実施し、特定の現地条件への適応の可能性を評価する準備ができている場合、典型的なプロジェクトで十分です。 必要な経験がない場合は、個々のプロジェクトを注文する価値があります。
事例紹介
個々のシナリオは、典型的なシナリオと同じように異なります。典型的なシナリオに基づいて、個々のシナリオが作成されます。 特定の条件（特定の日付と特定の出演者、素材など）に合わせて作成されます（典型的なシナリオ）。
典型的な建設プロジェクトには、「地面への着陸」が必要です。 これは、典型的なプロジェクトが個人の特徴を取得し始めるように、コーナーと標高マークの座標を示すのに十分であることを意味します。 典型的なシナリオでは、「所定の場所に着陸する」とは、特定の時間への参照、つまり開始時間の指示を意味します。 この「着陸」は、エンジンによって自動的に行われます。
典型的なプロジェクトでは、地元の建築材料、地質、地形への適応が必要です。 典型的なシナリオでは、これは特定の条件と特定のパフォーマーに適応させる必要があることを意味します。 この適応は、特定の実行者をロールに割り当てる、計画された操作の期間を調整する、一部の操作を他の操作に置き換える、または操作の順序を変更するなどのように見えます。
シナリオをモデル化する理由
それで、個人をモデル化する必要がありますか、典型的なシナリオをモデル化する必要がありますか？
自動化オブジェクトを選択するためのルールは次のとおりです。自動化の場合、自動化が有益な機能を選択する必要があります。 これは、頻繁なケースが自動化の対象となることを意味します（各ケースの自動化がわずかな経済効果をもたらす場合でも）が、まれなケースもありますが、各ケースの自動化は大きな経済効果をもたらします（たとえば、リスクを軽減するなど）。
典型的なシナリオでは、「ほとんどない」から「ほとんど常に」の頻度で実際の条件に適応する必要があります。
個々のシナリオをシミュレートする必要があるかどうか、典型的なシナリオをモデル化する必要があるかどうかは、このシミュレーションから得られる利点に依存します。
個々のシナリオをモデル化できないのはいつですか？
- 計画されたシナリオの標準からの逸脱がめったに発生せず、これらの逸脱の分析が具体的なメリットをもたらさない場合。
いつ個々のシナリオをモデル化する必要がありますか？
- 個々のシナリオの標準からの逸脱が頻繁に発生する場合;
- 逸脱がまれであるが、これらの逸脱の分析が具体的なメリットを提供する場合。
したがって、個々のシナリオのモデリングは、シナリオ（シナリオ）が通常のシナリオからしばしば逸脱する場合、または生産プロセスの継続的な改善がある場合に必要であると結論付けることができます。
典型的なシナリオをモデル化できないのはいつですか？
- 計画されたシナリオと典型的なシナリオの逸脱が非常に頻繁に発生する場合。
典型的なシナリオをいつモデル化する必要がありますか？
- 計画されたシナリオが典型的なシナリオから逸脱することがまれな場合。
言葉遣いの問題
さて、上記の問題を解決する理由という質問に戻って、通常のワークフローツールを使用することはできません。
問題の声明には次の点があります。
- 典型的なスキームに基づいたモデリング操作とシナリオ。
- 結果と計画との比較。
- 計画の調整。
計画されたシナリオのモデルが情報システムに保存されていない場合、これらの機能は自動化できません。
計画されたシナリオのモデルを作成できるガントチャートエディターがあります。
ただし、次の2つのタスクが発生する場合があります。
- 典型的なシナリオからの個々のシナリオからの逸脱はまれなので、典型的なシナリオが必要になる場合があります。 これは、サンプルのガントチャートを作成することで解決されます。
- 作業中の一般的な条件に応じて、計画されたシナリオの分岐をシミュレートする必要がある場合があります。 ガントチャートを使用したこのタスクは解決されていません。
BPMN表記があります。 この表記は典型的なシナリオのモデリングを目的としていますが、個々のシナリオモデルを作成することはできません。
おわりに
これまでのところ、分岐を考慮した標準シナリオと個別シナリオの両方のモデリングを提供する情報システムまたは表記法は見つかりませんでした。 おそらく、私は少し検索しました。 誰かがそのようなシステムを知っているなら、私に知らせてください！
ご清聴ありがとうございました！