前のページへ サイトマップへ ホームへ   
  DOAのお役立ち情報DOAソリューションこのサイトについて  
     
 HOME > INFORMATION > ER図で業務が分かる

コラム ER図で業務が分かる

1.ER図とデータベース構築

  「ER図で業務が分かる」とはどのような意味なのでしょうか。
 ER図(ERD−エンティティ・リレーションシップ・ダイアフラム)とは、業務で用いられているデータ項目を、 対象ごとに整理した、実世界(ビジネス)の「模型」(モデル)です。
 模型なので、詳細に作れば、ER図上に、業務の各プロセスや、対象物、 実施者などのビジネスの要素を余さず表現する事ができます。
 それを使って、ビジネスを俯瞰的・全体的に把握することが容易になるので、システム要件の確定や、問題点の発見などに活用する事ができます。
 それをここでは、ER図で業務が分かると表現したと言う訳です。
  このことを、順を追って見ていきたいと思います。

2.なぜ業務分析が難しいのか

  業務を分析するとは、以下の点を確認することにあります。
  1. 遂行されている業務プロセスの全体像がどのようになっているか
  2. 各業務で使用されているデータ項目はどこで入力され、どのように導出されているか
   3. その業務を実現するために必要な情報が過不足なく出力されているか
  4. 会社から見て、業務プロセスが十分に機能しているか
しかし、現実には
  1. 全社規模で、業務の内容や理由、緊急時に何をどのように変更するか、把握している人が少ない
  2. そのため、部署単位で業務内容を把握するを得ず、「個別最適」に傾きがちである
  3. モデルに基づいて、業務を実行したりシステムを作る人間が分かりやすいモデルになっているとは 限らないため、分析者の意図が現場やITベンダに伝わらず、結果として業務改善できなかったといった事も発生しているようです。

3.ER図とは何か

  ER図をもう少し詳細に説明すると、業務で用いられている画面や帳票のデータ項目、 つまり現実世界の情報を、エンティティ(実体・管理対象)と リレーションシップ(関係)で整理したものです。
  これにより、あるデータ項目が、どのビジネス要素の何を表現しているのか(例えば、顧客氏名が、顧客と言うビジネス要素の氏名を表現しているデータであるなど)を整理して、実世界を正しく反映したデータモデルを構築することができます。
  DOAは、このER図を元に先ず、データ基盤を確立した上で「どのデータを用いてどのような出力画面・帳票をつくりたいのか」という観点で、 システムを構築していくやり方です。
 同時に、この実世界がそのまま表現されているER図上で、エンティティが表している対象物 (顧客や商品、売上や出荷など)に対して、改めて、現在どのようなことが行われているか、今後どのような働きかけが可能であるかを、 ER図を前に関係者どうしで検討することができるわけです。

 今までのER図作成では、技法の教条的な適用で、あたかも半自動的にデータベースを設計する事を目指しているようなこともあり、エンティティとリレーションシップの把握、特にリレーションシップ設定のやり方が確立されていないか、 難解のものになっているようで、リレーションシップが少ないER図を良く見ます。
 ビジネスルールを如何にリレーションシップに表現して行くかを理解してしまえば、リレーションシップの少ないER図をビジネスルールを、キチント表現するものえとレベルアップする事も可能で、ビジネスのモデルとしての新しい活用も出来るようになります。
 このER図に基づく業務分析では、
  1. 全ての業務プロセスが一覧できるため、ボトルネックとなるプロセスを発見し、
    全体としての最適化を図れる。
  2. 各プロセスの内容がER図上に表現され、分析成果をDOA(データ中心アプローチ) を
    通じた短納期・低コストでのシステム化に直結できる。
  3. エンドユーザにER図作成方法を覚えてもらうことで(元々ビジネスを表すので簡単に覚えられる)
    エンドユーザとの仕様確定や全社経営戦略の策定などをスムーズに行える。
といった効果を得ることができます。

4.どうやってER図から業務を浮かび上がらせるのか

  ER図上に表されているデータ群から業務を浮かび上がらせるには、どうすればいいのでしょうか。
  簡単に言えば、出来事を表すエンティティ(イベントと言います)が鍵になります。
  先ほど、エンティティとは「管理対象」である、と言いました。
 データ中心指向では、 通常、管理対象の性質によってエンティティをリソースとイベントという2種類にわけています。
 これらの性質は以下の通りです。
・リソースは「モノ」、つまり個人・商品・倉庫といった物理的存在や法人・部署といった規約上の存在
・イベントは「コト」、取引・納入・事故といったある一時点に発生した出来事

 データ分析では、使用している画面・帳票を全て集め(取りあえず、集められるだけ集めればOK)、その中の「〜番号」「〜コード」 、「〜名」というデータ項目などから、判断してエンティティを捕捉します。(例えば、「顧客コード」 「売上番号」「納入番号」などがあれば、「顧客」「売上」「納入」がエンティティです。)
 これらのエンティティがどちらなのか簡単に区別する方法は、何時が属性となるかどうかで判断出来ます。
 何時が通じればイベントです。 
  以上のことを考えていくと、ER図上に表記されたイベントは、つまり企業活動の中で発生する、ビジネス上の出来事そのものであると言う事が出来ます。
 例えば、
   1. 外部からの連絡(発注指示・クレーム・市場状況)
   ⇒自社の対応動作(在庫引当・クレーム対応・購買)のトリガーとなる可能性
   2. 社内活動の計画(出荷・訪問予定など)
   3. 活動結果の記録(出荷実績・事故対応結果・顧客訪問結果など)
というものが考えられます。

 いずれにせよ、イベントの発生前後に、画面や帳票の入出力(単純なメモも含めて)という動作があり、 それに基づいて業務プロセスが行われる場合が多いと言えます。(リソース・エンティティも、入力/出力という視点から業務に関わってくるのですが、 ここでは詳しく触れません)つまり、ER図上に表れたイベント・エンティティに着目し、「このイベントが起きたら、何をしているのか」 「このイベントの情報を記録するのはどういうタイミングか」を推測したり、エンドユーザーにヒアリングしたりすることで、 業務の全貌を明確にしていきます。

5.浮かんだ業務の内容をどう見るのか

  さて、個々の業務活動は浮かびましたが、それぞれの連動関係や影響といった関係性がまだ良く見えません。 そこで、リレーションシップの検討を行います。リレーションシップは、 エンティティ間の関係を表しています。 具体的には因果関係であったり、後続関係だったり、業務プロセス(イベント)に関わった作業者や対象物だったりします。
 システム的には参照可能な関係にある、ということを表します。つまり、あるレコード(特定の顧客や取引)に関与した他の対象の情報 (担当者、購入商品、支払状況など)を同じ画面/帳票に同時に表示することができるわけです。

 先ほど説明しましたが、イベント・エンティティの情報表示/入力が業務の開始指示または終了報告になります。 ここで表示/入力する画面・帳票の内容は、他のエンティティとのリレーションシップ次第で変わってくるわけです。ここで、 以下の作業が必要になります。
  1. 「この画面/帳票で仕事ができるか」を現場担当者と検討
   ⇒必要ならばリレーションシップの張り替え(=データモデルの変更)
  2. 「現在のリレーションシップでは、このような画面/帳票表示になる」ことを提示
   ⇒項目の過不足や、入出力タイミングを確認する
こうした作業に加え、場合によっては下記のような作業も可能です
  3. 「このリレーションシップが張られていないが、この項目を組み合わせることで、
    新しい顧客アプローチが可能になるのではないか」という提案
   ⇒新しい、より望ましい業務プロセス仕様の立案
 ここで考え方を一歩進めると、それぞれの社員が遂行する定型的な業務も、定型化することもできます。
 つまり、 どのデータを参考にすると業務を実行できるのか、さらに顧客の反応や市場の状況、在庫状況などから、 どう判断を下すべきか、最終的にどのような作業結果・報告にまとめればいいのか、をフローチャート化し、 マニュアル化を行うことができるわけです。
 ものによっては、システム化の対象とすることも考えられますし、 もし人間にしかできない業務であってもマニュアル化による効率化やスキルの平準化、低コスト要員へのシフトを行うことができます。
  それにより、スキルのある要員を顧客対応や戦略分析、ノウハウ創出といった、より重要な作業に集中させることができる訳です。
  以上の内容について、「もっと具体的な例で示してほしい」などの疑問を持たれた方もいらっしゃると思います。
 弊社では、上記のご質問や、さらに分かりやすくご説明する無料セミナ を開講しておりますので、どうぞお気軽にご参加ください。

  ページトップへ