EEM-その1

 前回は情報モデルの関係性の記述の考え方を取り上げました。
 今回からはEEM(Entity Event Matrix)の設計の考え方を取り上げます。
 
 EEMという言葉は始めてお聞きになる方が多いと思います。この手法は現在のe-Japanの一環である電子政府システムの内部設計の位置手法として活用されていますのでご紹介いたします。

 EEMのEntityとは実体と訳するのですが、具体的にはスタンディング情報(=マスターファイル情報)を捉え、Eventとはイベント、すなわち受注や発注等のトランザクション)を捉えています。
 Matrixとはイベント処理とマスターの関係をトランザクションの発生する順の時系列で記述することから、付いています。そのマトリックスの校正は、縦軸にEntity、Eventと横軸にトランザクション発生順の時系列のマトリックスです。

 ◆EEM発想の起点
 このメソドロジーは、e-Japanの一環として進められている電子政府の業務設計のアーキテクチャでEA(=EnterpriseArchtecture)として使用されたことで、いくつかの大手の企業でも採用するところが出てきています。
 考え方の基本はインテーネットでの取引のシステムである「One-Writingシステム」にあります。
 仙台の球団争奪で有名を馳せました“楽天”、“ライブドア”にはインターネットショッピングの機能がありますね。このシステムの仕組みをみてみますと、消費者は購入要件を一度入力するだけで購入した品物が送られて来るしくみになっています。
 すなわち、一度の入力(=One-Writing)で、購入受付→受注確認→出荷手配→出荷→請求処理までトランザクションが連続して一気に書く処理プロセスで変換され、処理されるシステムになっているのです。
 それぞれのトランザクションの流れでは、確認と承認の作業が入るだけで、消費者とのやりとりは発生しません。入力者は入り口で1度だけ入力するだけですので、このようなシステムをOne-Writingシステム」と呼んでいます。非常に効率的なしくみです。
 このしくみは官公庁の業務の仕組みとまったく同じです。国民や市民からの申請書(=Event)を受付、申請書の内容を審査基準情報(=Entity)に従って、審査・承認または却下して、次のプロセスへと進みます。そこでも、基準情報に従って、審査・承認または却下され次プロセスへ渡されます。
 まさに、One-WritingシステムでIT化すれば、大幅な効率向上となること請け合いです。

 このシステムのビジネスプロセスのデータフローの記述を体系的に整理したものが、EEMなのです。
  “何か情報モデルのプロセスに似ていませんか?”

 ◆EEMの構造
 EEMはビジネスプロセスと情報モデルを一体化して作成される業務フローチャートです。
 Entityはスタンディング情報が配置され、Event(=イベント)は人が起動する処理単位で捉えます。
 例をあげますと、受注処理イベントは受注受付によって起動され、在庫引当の後、不足分は発注処理に渡されます。この発注処理で仕入先選定や発注金額の査定とその承認の人的操作が加わるとすると、発注処理は発注承認によって起動されるイベントとなります。
 このイベントでのトランザクション処理にはトランザクションデータがあります。
 このデータがスタンディング情報を下に、イベント処理の時系列に沿って順次渡され、変換されていくわけです。トランザクションデータを中心に、それを発生するイベント、情報引用のためのEntity(=マスター情報)を関係付ければよいことになります。
 
 “ビジネスプロセスの情報モデルの考え方と同じですね”

 考え方は同じですが、その整理の仕方を情報システムの設計がし易いように整理した設計図なのです。
 EEM構造を整理しますと次のようになります。
 
 *人的アクションの起こるトランザクション処理単位を時系列順に横軸として整理する。
 *情報モデルでのスタンディング情報を縦軸のEntityに配置する。
 *イベントであるトランザクション処理をEntityの下に続いて縦軸で配置する。
 
 このようにマトリックス配置をして、処理記述を施していきます。
 トランザクションは発生順に並べますので、最初のトランザクション処理は販売システムで言えば“受注処理トランザクション処理”になります。
 
 このトランザクション処理を発生させるイベントの入力情報に次のトランザクション処理に必要なEntity情報を抽出し、次のトランザクション処理に必要なデータへ変換または追加し、次の処理へ渡す。
 
 以下、同様にイベントでの入力、Entityからの情報抽出(および既に抽出しトランザクションデータ内にあるEntity項目の引用)そして、新たなトランザクションデータを次プロセスへ渡すといったマトリクスの表形式で、処理フローが整理できることになります。

 第59回はここで終了します。EEMの設計の考え方を取り上げました。
 次回は、EEMにおける抽象化として「EEM(Entity Event Matrix)-2」を取り上げます。

シェアする

  • このエントリーをはてなブックマークに追加

フォローする