まず、プロセスと呼ばれるものを思い出しましょう。 プロセスには多くの定義がありますが、最も有名で正式なものについて説明します。プロセスは、目的とする最終結果を得るために役人や組織単位によって実行される論理的に順序付けられた相互接続された一連のアクション（作業、操作）です（目標の達成、問題の解決、プログラムの実装、サービスの提供） ）
eEPC表記法でのモデリングは、従業員（部門、部門）によって実行される単一のビジネスプロセス内の機能ステップ（アクション）のシーケンスの説明であり、組織モデルと機能モデル間の関係を可能にするため、この表記法はシナリオと手順の説明に最適です。
モデルで使用できるオブジェクトは多数ありますが、多くの場合、プロセスインターフェイス、イベント、論理ルール、機能、および組織図オブジェクト（役職、従業員、部門）のみが使用されます。
モデリングでイベントや関数に名前を付ける方法をよく聞かれます。 この質問に答えるには、イベントとは何かを理解する必要があります。 イベントは特定の状態であり、関数の開始と終了に必要な条件です。 モデリングの基本的なルールは、プロセスは別のプロセスのイベントまたはインターフェイスで開始および終了し、関数はイベントまたは論理演算子であるということです。 イベントを定義するとき、イベントは時間内に瞬時に発生することを覚えておくことが重要です。つまり、「保留中の合意」というタイプのイベントはあり得ないため、「合意が合意されました」と「合意が合意されなかった」という2つのイベントに置き換える必要があります。 最も一般的なイベントの例：
- 計画された日付、時刻の開始、たとえば、「プロジェクトを開始することが決定された」
- 従業員による申請、注文、フォーム、情報の受領または送信。たとえば、「申請はクライアントから受領されました」
機能に関しては、ここで、機能はプロセス内の1つの（通常は最小限の）論理段階を形成する作業要素の説明であることに留意する必要があります。したがって、「アイテムの確認と購入」、「契約の締結」など、機能名にいくつかのアクションをリストすることは望ましくありませんおよび請求」などの場合、このようなケースを2つの独立した機能に分割する必要があります。
モデルのほとんどのエラーは、論理演算子とそれらの組み合わせの誤用が原因です。 そのうちの3つだけがあります：and、or、exclusive or。 単純なモデルの例での使用例をいくつか示します。
最も一般的なエラーは、イベント後のOR演算子と排他的ORの使用です。次に例を示します。
イベントが決定を下すことができないため、これらの状況は両方とも禁止されています。 この場合、唯一のオプションはAND演算子を使用することです。
または、2つの状態を追加します。
もう1つの間違いは、イベントに2つの発信通信がある場合、または関数に2つの着信通信がある場合に論理演算子をスキップすることです。
最も一般的な間違いは、次のようなフィードバックの誤った使用です。
この場合、論理演算子はスキップされます。つまり、関数が受信接続を1つしか持つことができないという規則に違反します。 AND演算子が論理演算子として使用されている場合もエラーになります。 この場合の唯一の正しい解決策は、論理演算子「排他的OR」を使用することです。
結論として、ビジネスプロセスの完全な説明を成功させるには、モデリングの規則だけでなく、説明を始める前に知っておく必要があることに注意してください。
- 誰
- 何の仕事
- いつ
- どのツール
- そして、どのデータ（どのドキュメントが入り、どれが行くか）
- 成功または失敗の責任者（プロセス所有者）
- 成功または失敗の測定方法（主要業績評価指標）