すべてのものは無限の多様性の現れの形です。

コズマロッド

eEPC表記の概要

現在、ビジネスプロセスのグラフィカルな表現には、表記法と呼ばれるさまざまな原則があります。 なぜそんなにたくさんあるの？ この質問は、ビジネスプロセスを説明する必要性に直面している人から何十年も尋ねられてきました。 その理由に対処しましょう。 それらの3つがあります（私の意見では）。

• さまざまなタスク。 すべての表記法がさまざまな問題を解決するのに等しく便利であるとは限りません。 たとえば、表記はトップレベルのビジネスプロセスにとっては便利であり、ワークフローの記述にはまったく便利ではありません。
• そのような表記法の異なる開発者。 さまざまな時期に、さまざまな開発者が回路を記述するための新しい原則を考案しようとしました。 実際に彼らが使用する記法が必要な微妙さを反映できない（またははっきりしない）状況に出くわしたとき、彼らは善意からこれをしました。 時々、進化の過程で、そのような表記法はまるで平行しているかのようになります。 見た目は異なりますが、タスクは同じように解決されます。
• 目立ちたいという欲求。 これは、未知の理由で、目立ったものは何もないが、何らかの理由で作成者によって最も完璧なノウハウとして宣伝されている新しい表記法が突然現れたときです。 これはまだ起こっています。

この記事の目的は、あらゆる種類の表記法を検討することではなく（意図的に命名するわけではありません）、最も最適なオプションを長時間検索する過程でプロジェクトに選択した表記法の詳細な説明に焦点を当てることです。

他の表記法とその用途を知りたい人がいる場合は、「表記法について話す」と呼ばれる別の記事でそれを行う予定ですが、これはまだ計画中です。

eEPCの非常に興味深い、シンプルで実用的な表記法（翻訳：プロセスのイベントチェーンの拡張された説明）についての話を始める時が来ました。 彼女の文字通りの翻訳は、ビジネスプロセスのチェーンの説明という主な目的を明らかにしています。 「イベント」の原則における表記法の主な「トリック」。これについて詳細に検討します。

eEPC表記の利点は何ですか：

1. まず、これは完全に純粋な表記法ではありません。 つまり 一部の表記法では、要素の厳格なセットとそれらの使用規則がある場合（そうでなければ、すべてが混同されます）、eEPC原則により、独自の要素を追加できます。 これはどのように保証されますか？ もちろん、すべてが構築される特定の「コア」があります。つまり、 スキームが構築され、それによって読み取られる一連の明確なルール。 さらに、独自の要素を追加し、独自の企業標準にその使用規則を含めることができます（構想を混乱させ、読みやすさを複雑にするイニシアチブを除外するため）。それだけです！ これは非常に重要なポイントです。 さらに、他の制限やルールを企業標準で指定できます。
2. eEPCには論理要素が含まれています。 これにより、アクティビティを説明するために必要な条件を備えたスキームを構築できます（「合意が合意された場合は....、それ以外の場合は...」）
3. 要素のシンプルさにより、ソフトウェア製品と他の方法の両方で、紙の上でも図を描くことができ、混乱することはありません。
4. eEPCは学習と理解が非常に簡単であるため、クローゼットの中にほこりを集めるだけでなく、実際のアクティビティで使用できます。 ルールを学習するには約2時間かかります（学習者が希望する場合）。

もちろん、この世界のすべてのものと同様に、欠点もあります。 しかし、合理的な使用はそれらを最小化します。 私の意見では、主な欠点は、単純なツール（つまり、ビジネスプロセスのモデリングではなく、ダイアグラムを描画するためのプログラム）を使用する場合、オブジェクトの単一のデータベースがないことです。 さらに、入力と出力を制御することは困難です（必要に応じて、それらを正確に制御する、つまり、そのような制御の方法を考え出す必要があります）。 しかし、一方で、複雑なビジネスプロセスをモデル化するためのツールの使用にはかなりの金額がかかり、それらを使用するプロジェクトは数百万単位で測定されます。 したがって、非常に経済的で理解しやすいツールがあります。 より正確には、この欠点は、特に私が検討している記述方法、すなわち MS Visioまたは同様のソフトウェアを使用します。 オブジェクトのデータベースをサポートするビジネスプロセスを記述するために特殊なシステムを使用する場合、この欠点は回避できます。 さあ、始めましょう...

eEPC表記の主要なコア

すでに述べたように、略語eEPCの文字通りの翻訳は、偶然性の概念を隠しています。 これは、回路を構築する原理全体が構築される非常に重要なポイントです。 そのため、「イベント」と「機能」という2つの重要な概念があります。 誰かがプロセスを最初にeEPCダイアグラムの形式で描画しようとすると、しばしば問題が発生しますが、イベントは機能とどう違うのですか？ これを自分で明確に理解する必要があります。そうしないと、予測できない結果が生じます。 そのため、イベントは何かを達成したという事実であり、期間がないか、この時間がゼロになる傾向があります（または重要ではありません）。 さらに、イベントは常に関数の実行を必要とし、関数の実行は常にイベントで終了します。例を挙げて説明します。 電話が鳴ります。 マネージャーが電話を取りました。 この場合、「Phone Ringing」はイベントです。 電話での会話は機能です。 会話は完了（ハングアップ）-再びイベント。 したがって、イベントチェーンが観察されます。コール-会話-コールの終了。 また、呼び出しの完了には、おそらく、呼び出しの結果の記録など、新しい関数の実装が必要になります。

描いてみましょう。 最初に、「イベント」および「機能」要素がどのように表示されるかを調べる必要があります。





これらの2つの単純な要素は、eEPC表記のビジネスプロセス記述ルールの基礎を形成します。 使用されている色について少し言葉を言う必要があると思います。 他の表記法でプロセスの説明に出くわした場合、原則としてそれらは白黒でした。 そして当然、コンテンツの色への明確な依存はないはずです。 このスキームは、紙に鉛筆で描いたり、白黒プリンターなどで印刷したりできます。この場合（eEPC ntiでは）、要素が特定の色を持つように歴史的に発展しました。 それが必要だったと言うわけではありませんが、習慣が開発されており、電子的な認識が優れています-何が何であるかをすぐに見ることができます。 これらの色は推奨事項と見なすことができます。 なぜそうなのですか？ 確かではありませんが、ARISがその製品でeEPC表記をサポートすると、そのような色が与えられ、慣れてきたように思えます。 ちなみに、この表記は「ARIS」、「ARIS EPC」とも呼ばれることがありますが、これは完全に真実ではありません。 ARISはこの表記法を発明しませんでしたが、ビジネスプロセスモデリングプログラムでサポートしました。 一般に、色を使用することをお勧めします。 主なことは、要素自体の形式が同じであってはならないことです（つまり、色のみが異なる）。 白黒では、混乱を引き起こす可能性があります。 eEPCダイアグラムに「調和」を与えることができる他のルールがあります。それらについて説明します。

だから、イベントがあり、機能があります。 彼らはどのように接続されていますか？

event1により、 event2で頂点に達した機能を実行する必要が生じたことがわかります。 たとえば電話の場合、次のようになります。





イベントの束-関数-イベントを上から下に1行で表示するか、左から右に表示するのが一般的です。 チェーンの方向は、矢印で線を結ぶことで示されます。



図をより視覚的にするために、表記法にはさらにいくつかの標準要素が用意されています。

• ポジション （エグゼキューター）。 この機能を実行する人
• 情報 ドキュメンタリー以外の機能を実行するために使用される情報。 たとえば、電話、操作を実行するための指示など。
• ドキュメント 。 「ドキュメント」要素は、情報媒体（紙または電子）を表示するためのものです。 つまり 特定の構造での情報の提示。
• プログラム（アプリケーション）。 機能の実行に使用されるソフトウェア。

他のすべての要素は補助的なものであり、eEPC自体の要件によって事実上規制されていません。 ただし、独自の要素を追加するための障壁はありません。 主なものは、内部標準でこれを修正して、それらがどのように見え、なぜ適用されるのかについて共通の理解があるようにすることです。 リンクevent-function-eventが違反されない場合、そのような拡張は要件に違反せず、情報の認識を改善するか、業界固有の記述ルールを適合させることのみを目的としています。 独自の要素セットを追加しました。これについては、以下で説明します。

考慮される要素がどのように配置されるべきであるかを見つけることはまだ必要です。 これらの要素はすべて、何らかの方法で関数に関連付ける必要があります。 これは一般的なルールです。関数以外の単一の要素がイベントに関連付けられることはありません。 つまり これらの要素はすべて、関数を使用して矢印で接続する必要があります。 矢印とその方向について：情報を送信する方向がない場合、矢印の代わりに単純な線が表示されることが一般に受け入れられています。 情報が入る（入り口に入る）場合は、オブジェクトから関数への矢印の方向、出口の場合はその逆、逆も同様です。

ダイアグラム上のこれらの要素の位置に関するほんの少しの言葉と、コール処理機能の実行を指定してダイアグラムを再描画できます。 要素の配置には厳密な要件はありませんが、すべてのスキームで均等に表示することが慣例です（スキームの均一性と調和のため）。 ビジネスプロセスのグラフィカルな図の外観を統一するには、このようなルールを内部標準で修正して従う必要があります。 少し後で、このテーマに関するいくつかの推奨事項を示します。

次に、スキームを再描画します。





オペレーターが着信コールを処理し、着信コールを処理するためのルールに従って行動し、そのためにCRMプログラムを使用していることがわかります。 受信ドキュメントも送信ドキュメントも使用されません。

前述したように、表記法の長所の1つは論理の要素です。 同時に、これは理解するのが最も難しい瞬間の1つです。 したがって、最初に例を挙げてから、ロジックの要素を個別に扱います。

この例のようにしましょう。クライアントが興味を持っている場合、セールスマネージャーは彼とさらに作業を行い、商業的な提案を出し、MS Outlookメールクライアントを使用してメールで送信します。 関心がない場合、コール処理は完了します。 現実には、通話を終了するためのルールを使用するのは良いことですが、私はそうですが、単純化されています。 結果は次のとおりです。

eEPC表記法の論理要素

論理の要素は単純ですが、回路を論理的かつ明確に解釈するためのいくつかの特異性と規則があります。 遵守する必要がある最も重要なルールは100％です。 論理的な決定は、機能の実行時にのみ行うことができます 。 つまり 何らかのイベントの後、分岐することはできません。 なんで？ この場合、イベントの概念と矛盾するため、実行時間なしでシンプルかつ瞬時に行われます。 たとえば、電話が鳴り、その人が電話を取るかどうかを考えて座っている場合、これは理論的には意思決定を行う機能になります。 しかし、実際には、常識を含めて、彼は呼び出しを処理するためのルールに違反しています。 彼らは彼にこれらの呼び出しを処理するように彼に給料を支払います、そして、ここで議論することは何もありません（一般に、図に示されるように）。

合計で3つの論理要素が区別されます。

• そして 。 2つ以上のイベントが同時に発生した場合。
• または 。 1つまたは複数のイベントが発生する可能性がありますが、少なくとも1つは必ず発生する必要があります。
• 排他的または どちらか一方。 つまり 2つのオプションは同時に不可能です。

それらのいくつかを次に示します。









ご覧のとおり、ロジックエレメントのグラフィカル表示には2つのオプションがあります。 それらは全く違いはなく、完全に代替です。 両方持ってきました 実際には、両方のソースをさまざまなソースで見ることができます。 どちらを使用するかは、あなたが決定します。 私は最初のほうが好きです。

ここで、ロジック要素の適用を理解する必要があります。 まず、発生したオプションを検討してから、例に進みます。 各要素を個別に分析しましょう。

論理要素「AND」。



関数の実行がいくつかのイベントの同時実行を必要とする場合：







例：レポート期間が終了し（イベント1）、マネージャーにレポートを送信する時間になった場合（イベント2）、従業員は月次レポートを準備します。



関数の実行中にいくつかのイベントが発生した場合、要素の接続：







例：顧客とのいくつかの作業が完了しました。 2つのイベントが同時に記録されました。和解が調停され（イベント1）、行為が署名されました（イベント2）。



実際には、このようなアプリケーションは一般的ではありません。 原則として、1つの機能で多くのアクションが組み合わされる場合。



要素の接続。複数の機能を実行するときにイベントが発生した場合：







例：店主が注文を収集し（機能1）、オペレーターが書類を書き留め（機能2）、商品の出荷準備ができました（イベント）。



1つのイベントの発生が複数の機能のパフォーマンスにつながる場合の要素の接続：







例 ：委託品が到着しました（イベント）。 同時に、顧客が以前に注文した商品の出荷と、倉庫内の残りの商品の配置が開始されます。



論理要素「OR」。

イベントの1つが関数の実行を引き起こす可能性がある場合、要素の接続：



例 ：電話で受信したアプリケーション（イベント1）または電子メールで受信したアプリケーション（イベント2）を処理する必要が生じます。

1つの関数が少なくとも1つのイベントを引き起こす可能性がある場合の要素の接続：





例：商品請求書が作成され、顧客への出荷用に送信されました。 請求書は、メール（イベント1）、ファックス（イベント2）で送信できます。



複数の機能を実行するときに要素を結合すると、イベントがトリガーされます。







例：サービスが提供される（機能1）または製品が販売される（機能2）、顧客に債務がある（イベント1）。



論理要素「排他的OR」。



関数の実行に必要なイベントが1つだけの場合の要素の接続：







例：顧客が直接来店した（イベント1）、またはインターネット経由で注文した（イベント2）。 商品を出荷する必要があります（機能1）。



関数の実行の結果として、最大で1つのイベントが発生した場合の要素の接続：







例：決定が行われるかどうか。



発生 した場合、要素の接続は、 1つの機能のみが実行された後に発生します。



















例 ：商品は、独自の輸送（機能1）または輸送会社（機能2）のいずれかによって配送されました（イベント1）。



論理要素を正しく適用するには、ある程度の練習が必要です。 しかし、それは難しくありません。 考慮されるすべての組み合わせが実際に広く使用されているわけではないことに注意する必要があります（ただし、一般的にこれはアナリストの考え方によって決まります）。



論理要素を実践してみてください。 困難がある場合は、私に書いて、私は助けようとします。

ネイティブ要素で表記を拡張する

前にも言ったように、eEPCは表記法ではなく、記述ルールです。 また、これらのルールは、ダイアグラムに独自の要素を追加することを禁止していません。 主なことは、これらの要素は理解可能であり、そのような要素の拡張が修正されているドキュメントがあります。 たとえば、簡単な説明から自動化のためのタスクの設定まで、さまざまなタスクの実際のプロセスを説明する過程で徐々に生じた次の追加要素を使用します。





データ付きファイル 。 操作の結果としてデータファイルが作成された場合、またはファイルが操作の実行に使用された場合に使用されます。

データベース。 自動化システム間の情報フローを記述するために使用されます。

カードファイル。 紙のファイルまたはアーカイブを表示するために使用されます。

マテリアルフロー。 プロセス中に消費されるリソースだけでなく、着信および発信マテリアルフローを示すために使用されます。 マテリアルフローは、付随するドキュメントの左側に表示されます。

情報クラスター 構造化された情報（エンティティ表現）を示すために使用されます。 この図は、カスタムアプリケーションを使用してプログラムで生成されたドキュメントを参照するために使用できます。 この場合、Cluster要素は対応するドキュメントの左側にあります。 つまり ユーザーは紙の文書を作成しただけでなく、プログラムでその文書のインスタンスも作成したと言います。

図に図を配置する規則に関する合意

eEPC表記自体は、図を上から下または左から右に描くのが通例ですが、要素の相対的な配置に厳密な要件を課していません。 数人の専門家の場合にそれを統合することが不可能な場合、独特の「ビネグレット」が判明する可能性があります。 これを回避するには、要素の場所に関する独自のルールを作成して承認することをお勧めします。



私は次の規則を順守します（推奨します）。

• イベントと関数のシーケンスは、上から下（より良い）または左から右（十分なスペースがない場合）に配置されます。
• パフォーマーを示す要素は、機能の右側にあります。
• 関数の左上にある受信ドキュメント。 文書から機能への矢印の方向。
• 関数の左下にある送信ドキュメント。 機能からドキュメントへの矢印の方向。
• 「情報」要素は、関数の右下にあります。 十分なスペースがない場合、関数に可能な限り近い任意の配置が許可されます。
• Application要素は、関数の右上にあります。 （レポートではないファイルストレージがこれに使用される場合、それらは同様に表示されます）。 矢印のないコミュニケーション。
• 要素「データベース」と「ファイルキャビネット」はランダムに配置されます。
• 「マテリアルフロー」要素は、それに付随するドキュメントの左側にあり、矢印のない線でドキュメントへのリンクがあります。
• 「クラスタ」要素は、「ドキュメント」の図と組み合わせて使用​​して、電子形式のドキュメントを示す場合、対応するドキュメントの左側に配置されます。

例：給与計算機は、彼に提供された准将の書類に基づいて給与を計算します。 同時に、彼は文書「賃金に関する規制」に導かれ、計算はプログラム「1C：ZiK」で行われます。 計算の結果は、ドキュメント「Statement」です。

チャートの識別

ご存知のように、ビジネスプロセスの記述に対する有能なアプローチには、その識別、すなわち 各プロセスが独自のコード名を持っている場合。 したがって、プロセス内の個々の機能にも独自の名前と識別子があります。

図「文書」および「機能」は、図上での必須の識別の対象となります。

ドキュメントは、レジストリに従ってレポートまたはドキュメントのコードを左上隅に示すことで識別されます。 商品およびサービスの供給者から受け取った文書（着信）は、名前でのみ識別されます。

関数は、このプロセスグループの関数のシーケンス番号を示すことで識別されます。 つまり 機能番号は常にプロセスグループコードで始まります。 プロセスグループを識別する問題は、この記事の範囲外であり、個別に検討します。 さらに、プロセスを説明する前にプロセスを特定する方法を学習する必要があります。そうしないと、会社のすべてのアクティビティを1つの図で説明したい場合があります。

したがって、ここでは、ダイアグラムでこれをどのように表現できるかを例で示します。 呼処理の例に戻りましょう。 コード「04」を営業部門に割り当て、コード「VK」を着信連絡先の処理に割り当てたとします。 スキームは次の形式になります（明確にするために、識別は赤で強調表示されます）。 この場合、文書コードは、文書の一般的な登録簿にある文書のシリアル番号を示します（文書管理システムの調査を行う際には、これも別に検討します）。

フィードバック表示

モデルを構築するとき、特定の条件下でプロセスを周期的に実行する必要性や、意思決定者の活動を反映する必要性がしばしば発生します。 この場合、フィードバックについて話します。



制御フィードバックを表示するために、後続の分岐を伴う追加の制御機能のプロセスにおける「直接包含」の原則が使用されます（「排他的OR」論理要素が使用されます）。 例：

プロセスのテキスト記述

どんなに一生懸命ビジネスプロセスを図に表示しようとしても、完全な詳細を達成することはできません。さもなければ、無限の要素と条件のチェーンにたたくことができます。 これを回避し、グラフィカルに表示できないプロセス説明情報に追加するために、説明にテキストの伴奏が追加されます。 これを行うには、説明プロセスで入力されるさまざまなテキストテンプレートを開発します。 このようなテンプレートの形式は異なる場合があり、入力と出力、消費されたリソース、使用されたソフトウェアなどの説明を含む個別のセクションを含む

最も単純な場合、ビジネスプロセス記述テンプレートは次のようになります。

ビジネスプロセス：	インバウンド連絡先の処理	04.VK
プロセス機能：
お名前	説明	スキーム番号
着信呼処理	着信コールが到着すると、オペレータは着信コールを処理するためのルールに従ってコールを処理します。 顧客の関心を識別し、サービスに関する情報を提供します	04.VK.01
商業提案の形成	顧客の関心がある場合、オペレーターは連絡先を営業マネージャーに転送します。 セールスマネージャーは見積を作成し、それを電子メールで顧客に送信します。	04.VK.02
プロセス指標：
お名前	評価/測定方法
失敗の数	データベース統計

この記事の範囲外では、情報の収集、ビジネスプロセスの強調表示、分解、インジケータの強調表示などの重要なトピックが残ります。これらの問題は将来の問題で確実に研究します。