DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

menuclear


隔週で連載している本ブログシリーズも、前回で90回目を迎え100回まで残すところ10回となった。ユーザ企業目線で、優れたベンダーサービスを取り込みつつも、自身のITアーキテクチャが如何に重要であるかを様々な角度から読者にお届けしてきたつもりである。ここに至るまで企業システムのITアーキテクチャについては概ね語り尽くしたので、本シリーズは100回目でひとまず区切りをつけたいと思う。

今回も含め残りの回は、(アーキがテーマなので)今まで敢えて語って来なかったマネジメント要素に焦点を当てたテーマを取り上げてみたい。初回は本シリーズの中核をなすMDM(Master Data Management)システムの運用管理面での“憲法”なるものについてお話する。なお、MDMについては“バックナンバー”2014.3.12「マスタHUB(狭義のMDM)」“を参照されたい。

以下のMDM憲法に掲げた1~5項は、せっかくマスタデータを一元管理するシステムを導入しても、これらのルールをないがしろにすれば、本来期待される効果を上げることができないばかりか、MDMシステムが崩壊し短命に終わることになるものを掲げている。やや理屈っぽい内容であることをご勘弁いただきたい。どんなに優れたコンピュータシステムも、最低限の人間系ルールを守る事がやはり前提となり、なぜそのルールが必要かといった理由がそれぞれに存在する。

1.「個別アプリケーションの業務処理を載せない」
MDMシステムと個別業務アプリケーションとの役割分担については、構築前に取り決めしておくことが大事である。基本はMDM環境内には、受注、購買、生産、営業、会計等の個別アプリケーションに関連する“業務処理”を搭載しないことが原則である。MDH(マスタデータHUB)の役割は各業務アプリケーションに依存しない「共通マスタデータ」の集配信機能だ。受発注や生産計画等の業務処理を搭載することは、個別アプリケーションとの密結合化を招き、MDMシステムの複雑化、巨大化の要因となる。よって、各種の業務処理とは一線を画さなければならない。

2.「異なるシステム間のデータ変換を一元的に扱う」
個別業務処理のMDH搭載は厳禁であるが、データ形式の変換(コード変換、フォーマット変換など)については、本MDH上に一元的に配備するのが良い。歴史的経緯や実装方式が異なることによって、複数のシステムに存在する本来同一の意味を持つ情報でも、そのデータ形式(型、桁数)やレコード形式(縦持ち/横持ち等)が異なることがしばしばある。全てのシステムのデータ・レコード形式を統一することが非現実的であることから、データ変換プロセスを介する事になるが、この“コンバータ“を永続的に管理する為には、唯一MDM上に一元化して配備しなければばらない。

3.「1つのマスタデータを複数箇所で更新してはならない」
共通マスタを一元管理するということは、その共通マスタデータを生成するプロセスを一元管理することと同値である。従ってMDHインバウンド処理において登録画面若しくは発生源システムから取り込んだマスタ更新用トランザクションを元に正本マスタ(ゴールデンレコード)を生成する処理は唯一1箇所にしか存在してはならない。MDHアウトバウンド処理ではゴールデンレコードを個別業務アプリケーションに向けて配信するが、これを受け取った個別業務アプリケーション側では参照利用のみが許され、さらなるデータの更新をしてはならない。仮に更新処理を施したい場合は、再度、MDH上にアップロードしゴールデンレコードを更新しなければならない。

4.「ゴールデンレコードのデータ品質を保証する必要がある」
MDHから配信される共通マスタデータは不特定多数の業務アプリケ-ションに使用されるので、そのデータ品質についてはとりわけ高い精度、鮮度が必要となる。万が一、誤ったデータがゴールデンレコードに紛れ込んだ際は、すぐさま正しいデータを送り込めるリカバリー処理が発動できる(人間系を含めた)システムになっていなければならない。また当然ながら、その原因究明の為、ゴールデンレコード生成過程のトレーサビリティ、証跡保存のしくみが求められる。従って、一般的には集信データはマスタ更新差分データを受け取るケースが多い。配信データについては更新差分若しくは全件など、相手システムの要求に応じて柔軟に対応することで良い。

5.「システム変更にはデータ管理グループの承認を伴う」
上記の1~4のルールを遵守していても、ビジネスニーズはMDMシステムとは無縁のところで発生する。常に、全体最適化の責任部署の承認を得ることで個別最適に走ることを抑止する組織運営がやはり必要である。新たなシステムのスパゲッティ化、サイロ化を抑止するため、特例としてあるアプリケーションが他システムのマスタを直接参照もしくはCOPY利用する際は、データ管理グループ(仮称)の承認を必要とする。また逆に、MDH上のマスタ乱造を防ぐために、MDM上に共通マスタデータを配備するためにはデータ管理グループの承認を必要とする。

以上、今回はマスタデータ一元管理のしくみ“MDM”の導入において、それがどんなに優れたアーキテクチャーであったとしても、その人間系での運用ルールを守ることが前提となることをお話した。余談であるが、もしもガバナンスが働かなかった場合のMDMシステムの賞味期限とはどのようなものになるだろうか。。。私の過去の経験から“3年”がいいところなのではないだろうか?システムの荒廃は実に早くあっけないものである。せっかくの投資をムダにしたくないものである。

| 目次

採用情報
PM-waigaya
PM-WaiGaya
コンサルタントのトーク動画
PM Weekly Talk
PM Weekly Talk
コンサルタントが語る「PMBOK®12 の原理・原則」

Profileプロフィール

Avatar photo
中山 嘉之
1982年より協和発酵工業(現、協和発酵キリン)にて、社内システムの構築に携わる。メインフレーム~オープンへとITが変遷する中、DBモデラー兼PMを担い、2013年にエンタープライズ・データHubを中核とする疎結合アーキテクチャの完成に至る。2013年1月よりアイ・ティ・イノベーションにてコンサルタントを務める。【著書】「システム構築の大前提 ― ITアーキテクチャのセオリー」(リックテレコム)

Recent Entries最近の記事