基幹系システムを支えているのはマスター
社内SEとしての仕事のひとつとして、障害対応があります。障害の原因ですが、システムが起因の障害とヒューマンエラーが起因の障害に分けられます。
ヒューマンエラーが起因の障害は、さらに２つに分けられます。それはトランザクションとマスターの２つです。
今回はマスターによる障害についてです。
マスターが引き起こす障害の特性は、２つあります。１つ目は気づきにくいこと。２つ目は影響範囲が大きいこと。
社内SEの方なら、思い当たる節はいくつもあるでしょう。
ガバナンス上、マスター登録は承認が必要になります。しかし、日々行われるマスター登録です。すべてをチェックしている時間はありません。性善説で行われていることでしょう。
そのため、誤ったマスター登録をしても、誰も気付かないまま、月末や期末をむかえるケースもあります。
そうすると、影響は大きく、リカバリー作業が必要になります。
マスターは基幹系システムにおいて、根幹を支える屋台骨なのです。
情報系システムの分析軸のマスター
基幹系システムでマスターはトランザクションを動かすため必要なのは、理解されてることでしょう。
もう１つ重要なのは分析軸としてのマスターです。
そこで役立つのが「データモデリング」です。 データモデリングを行うことで情報が整理されます。それにより、新たな発見や現状の再認識を行うことできるようになります。ただし、ここには「データ分析」という作業は必要なります、
何をどのようにして保持するのかは、イノベーションの発見にもつながるのです。すべて信頼できるデータがあるためです。そのためには、信頼できるマスターが必要なのです。
マスター管理は永遠に続く課題
あなたは、マスター管理の大切は、普段の運用から十分に理解されてることでしょう。
では、次期基幹系システムを考えた場合、マスターはどうあるべきなのでしょうか？
基幹系システムが変わっても、マスターは変えないほうがよいです。なぜなら、これまでのデータの収集方法や分析がゼロからになってしまうからです。
とはいっても、そのようなことはほぼ不可能です。パッケージ製品にマスター登録している以上、パッケージの中にマスターが存在します。パッケージを変更することは、マスターの変更と同じことなのです。
そこでマスター管理だけを外部に持たせる方法があります。 MDM（Master Data Management） です。このようなパッケージ製品もあります。それほどマスター管理が大切であることことを意味にしています。
