不良金融商品は、リスクを制限するために作られたはずの規制の甘さによって広がりました。特に、米国企業改革法(SOX法)と新BIS規制です。一部の人たちはその抜け道を見つけ、更なる規則を追加するように提案していますが、その兆候と原因は慎重に分離させる必要があります。つまり、それは、金融規制の欠如以上に、現状の原因とされるリスクを計測する際の正確さの欠如なのです。
新しい、あるいは変更された規制は、何も変わらないでしょう。ある組織が、非常に複雑な環境での活動における実態について計測しているよりも先に、その中での活動をおこなうと、極度のアンバランスさが浮上することもあるでしょう。このアンバランスは、すぐに表面化するものではありません。それは、組織とともにゆっくりと現れて、広がるものです。より高い価値が作られれば、より制御不能なものとなるかもしれません。始めのうちは、そのアンバランスが活動に影響を与えるようには見えないでしょう。しかし、その発見が遅れるほど、それを修正するための活動の開始がより困難になります。金融システムの崩壊は、この事象の最たる例です。根本的な問題は、組織が何故それほどに早く、それだけの規模で、発見されずにその活動の制御を失ってしまったのかということです。製品の精巧さと、常に増加する実行の速度は、そのような危険に対するうってつけの素地となります。彼らの活動をサポートしている情報システムの曖昧さで作られたこれらの製品の曖昧さによって、十分な正確さでリスクを評価し、精緻化することを不可能な状態にしています。しかし、今日、何らかのデータ群を分析せずに、活動や決定が行われることはまずありません。加えて、情報システムが大半のビジネスプロセスを自動化しているので、大抵の企業は、ビジネス要求の変更に対処し、競合圧力に対応するために、これらの記録システムを迅速に変更することができないということに悩まされます。最終的には、記録システムが組織の状態を反映していない状況に至ります。また、情報システムで得られた状況の意味に関する共通理解を得ることができません。
付帯的な複雑さは、不十分な設計基盤での非常に多くの戦略的なものによってもたらされました。そして、継続的な予算削減がITそれ自身に対して毒となっています。アプリケーションや技術の更新や撤去さえも不可能となり、主要な問題を解決することを前提としてパッチを適用するのがせいぜいです。心理的に、人はおこなったことを変更しません。しかし、最も重要なのは、IT管理によって、そのスタッフが何らかの綿密な革新を実行するような権限を与えられることはないということです。それは、活動における一貫した可視性を達成するために、プロジェクトが、十分に調べられ、配置されることはないからです。とは言うものの、15年以上の間、ISVは安定した基盤を提供することが困難で、持続可能なビジネスソリューションを構築したアプリケーションをパッケージ化していました。とても明確な形で、元からあるいくつかの制限に達したり、消耗したりするハードウェアとは異なり、ソフトウェアも永遠かの印象を与えます。私たちは、GoogleやAmazonのような、(例えば、更新可能な基盤ソフトウェアを構築することで、)過去の過ちを避けるであろう新しいソフトウェアベンダーを期待することはできます。しかし、それらは与えられたものではありません。全ての組織は、十分な性能と一貫性をもって、透過的で維持可能なビジネスソリューションを構築したときに、まさにそれが独自のものとなるのです。
問題は、私たちがこの状況に対する自覚をどのようにして高めることができるか？ということです。CIOにとって、この現実を受け入れることは容易ではありません。とても頻繁に、最高情報責任者は、最高情報システム責任者となります。そして、彼あるいは彼女は、会社の戦略に専念するために通常の役割を放棄しました。このシフトは、ビジネス革新とITの間の戦略的な関係をしばしば確立してきた業界の専門家や分析家によって広く支援されました。しかし、実際には、ITは革新を抑制するものとして受け入れられています。だからこそ、CIOは情報システムと情報でないものを管理することに満足しています。CIOは、少なくとも、ビジネスと向かい合って、情報システムの曖昧さを無くすことに注力しなければなりません。ビジネス活動(それは私たちの社会にとって欠かせないものです)に含まれるリスクへのより一層の理解を示している限りは、ビジネスと情報の間の単純な調整が、革新の可能性を増大させます。最終的に、人間のコミュニケーションは情報システムに深く依存するようになり、それらの有無に関わらず、繁栄するか滅びるかという複雑なレベルのものを作ったことを自覚しなければなりません。
この事象の一番の具体例の一つは、Societe GeneraleのトレーダーであるJerome Kervielです。彼は、70億の損失を生じさせ、その原因は、ITが実際のビジネスが実行されていないものと判断し、記録システムへのアクセス制御が開かれたままであったためでした(このケースでは、シミュレーションと実際の取引の間に差異があった)。悲惨なことに、同社はリスクに関する正しい報告を見える形で提供することができませんでした。
CIO、最高情報責任者としての役割に戻り、今一度、情報システムにより注力しなければなりません。記録を主としたシステムで作業を続けるのは、十分ではありません。企業は、ビジネスのサービスでITを求めなければなりません。この変化を達成するためには、IT資産がビジネスの可能性と協調できるようにすることで、技術やアプリケーションポートフォリオの価値を中心に置かなければなりません。今日、分析的ツールを除いて、CIOは、ITをビジネスに対してほとんど透過性のない技術によって操作・管理されている、アプリケーションとデータストアの一つのセットとして見ています。CIOが、自発的により戦略的な役割にシフトし、技術から離れることで、ポートフォリオの価値を簡潔に管理する情報コントローラーとしてこれらのシステムを管理します。何というパラドックスでしょうか！CIOの損得勘定は、彼または彼女が満足するであろう機能とは足並みがそろいません。
しかし、ある方法でこの変化を成し遂げることは可能です。そして、新しい技術は長年の経験のもとに発達しました。現代のCIOは、むしろ、マスターデータ、ビジネスルール、ビジネスプロセスといった、核となるIT資産の管理に注力すべきです。今日、これらの資産は、残念ながらそのほとんどが情報システムの中にハードコードされています。そして、そのシステムは、柔軟性と可視性の両方に関して、現在ビジネスに必要とされるものとは相いれない不明確なものとなっています。例えば、市場調査会社のForresterは、次のように述べています。「多くの企業が、今なお、アプリケーションの中にプロセス、ルール、レポーティングを含んでいます。言い換えれば、プロセスフロー、ルール、分析が、個々のアプリケーションにハードコードされているということです。これらの定義が別のアプリケーションコードに混じっている場合は、それらを見つけるのでさえ困難です。そして、変更するには長いQAの手続きを必要とします。(ビジネスルールの集約方法、BPMやBIがビジネスの最適化をもたらす。Forresterリサーチ, Inc. 2008年5月)」
これらの資産は、ビジネスに対して開かれていて、監査可能でなければなりません。アクセス権限、セマンティクス、バージョンルールなどを定めているガバナンスポリシーは、トレーサビリティを強化し、企業の活動リスクを把握するための強固な基盤を提供します。マスターデータ、ビジネスルール、ビジネスプロセスが、情報システムの技術の底にハードコード（ハンドコード）されている状況で、私たちはどのようにしてこれらの活動リスクを見抜くのでしょうか？
経営幹部にとってITは必要なものですが、残念なことに、ほとんどが競争上優位なものとなっていません。CIOを起点とした改善は、十分に報われていません。ITの管理は、コストを削減し、仕事を続けるためにのみおこなわれるものです。経営幹部は、その主要な活動の指標が緑である限り、ITコストがより少ないものとして満足するようです。もちろん、ビジネスは、ITによる柔軟性や可視性の欠如によって損害を受けます。それは、すべての人が自覚していますが、時間と共に、それが有望な技術を試した後の既成事実になるように思われます。多くの組織は、大きな問題が発生するまで、日々この苦しい状況を管理しています。
逆に、多くのIT組織は、過去、数十年以上にわたる情報を収集、処理、報告しています。しかし、今日、組織は経営者に気づかれることなく、すでに引き返せない局面まで来ています。後は、破たんのみです。ここ数年で、主要な国際企業のいくつかは、彼らがとったリスクを主張することができず、可視化の欠如によって自身のビジネスモデルの持続可能性を計測することができない結果、この過程が「健全な」状態から12か月以内で起こりうるものであることを示しました。歴史的に、投資家は格付け会社に頼ることができますが、今日、それらの評価が不明確な情報に基づいたほとんど意味のないものとなっています。その点で、格付け会社の評価をサポートするためにより多くの制御を加えることは無益なことです。むしろ、企業活動に正確な可視性を提供する方が重要です。ここで重要なのは、監査の信用性を示す計測基準を定義することで、情報システム自身の評価を確立することです。この評価は、その資産価値を管理する能力として、企業を評価するでしょう。即ち、それは、マスターデータ、ビジネスルール、ビジネスプロセスの管理方法です。
高い成熟度に基づき、これらのツールや方法は既に成功を納めています。最も重要なことは、彼らはビックバンアプローチを必要としませんが、リスク管理の順守による向上的で計画的な変更、ITによるサポート、データとSOAのガバナンスを必要としているということです。これら3つのリポジトリを結合することが重要です。それらは共に、ACMS(Agility Chain Management System、アジリティチェーン管理システム)と呼ばれる強力な概念を形成しています。アジャイルルールのないアジャイルプロセスはありません。そして、参照データやマスターデータに対するビジネスマネジメントのないアジャイルルールはありません(図1)。これら3つのそれぞれが、バージョン管理、権限管理、トレーサビリティ管理などを含んだ高度なガバナンス機能をサポートします。
図1. アジリティチェーン管理システム(ACMS)
例を見てみましょう。あるビジネスレギュレーション(例えば、米国企業改革法(Sarbanes-Oxley法)やSolvency II)は、監査可能であることを財務報告に要求します。その企業は、データを示すことができ、計算ルールが報告書作成とそのデータを証明するために作られ、ルールは正しいものでなければなりません。一般に、このような状況下で、企業は、ITシステムで明らかに実行することのできない紙で、監査役に文書を見せるのが精一杯かもしれません。さらに悪いことに、ITツールのための文書は昔のもので仕様書だけで、監査役に分析されるプログラムコードは利用可能だということです。そして、監査役はITの専門家ではないので、これらの材料を使うことができないでしょう。これは、一部の場合においては受け入れることができるでしょうが、監査役が要求する場合はどうでしょうか？あるいは、独立IT評価機関が、株主の要求によって情報システムを評価する場合はどうでしょうか？同じ監査役がビジネスルールとマスターデータのリポジトリを利用することで、ルールとデータ利用法を綿密に調べ、財務項目を容易に監査することができます。技術のみの指向によるUIではなく、ビジネス指向のUIを含んだリポジトリシステムであるため、これが可能となります。
これらのリポジトリは、通常、段階的に配備することができます。適切なガバナンスがおこなわれているので、ある企業は、いくつかのビジネスルールを避け、レガシーデータベースの前にMDMリポジトリを追加することによって、レガシーシステムでの変更を開始します。レガシーデータベースは、この段階では変更しません。トレーサビリティとアジリティの増加によって、1年以内に、ルールやマスターデータリポジトリによるメリットが得られるかもしれません。そのビジネスは、最終的に、ビジネス視点での情報システムの資産へのアクセスを得ることができ、ビジネスとITの人たちの間にある共通の曖昧さをなくします。一般には、プロセスの重要な対象として、企業は、ビジネスルールと参照データの両方で、ビジネスナレッジの強化も考えなければなりません。そして、受け入れられたモデリングの努力や、リポジトリから入手したドキュメントに感謝します。この文書化は、ITチームとシステムによってすぐに実行することができるということを心に留めておくことは重要です。つまり、これは、ビジネスとプログラムの間で十分な調整に対する保証であり、規則の要求に対する応えを含んだシステムの強化された監査能力に対する保障です。
リポジトリを制御するための手法とツールを使用し、レガシーシステムとの統合のためにそれらを採用する第一段階の後、一般に、次の段階は、旧式のプラットフォームを捨ててより俊敏になるように、すべてのシステムを再構築する段階となります。
この段階では、情報モデルは、レガシーシステム（図2）で取り扱われるデータ構造に関する詳細なビジネスの視点を取り入れるように設計されなければなりません(図2)。このモデルは、強い意味論的な凝集性を持っているデータ集合体の間の疎結合を促進するために、全体的な組織のデータスキームをベースとしなければなりません。共通モデルのいくつかのパーツは、参照データのリポジトリを構築するための基盤となります。つまり、データが、ビジネス監査を主要な目的として、システム間で共有されるということです。私たちは、空白ページ症候群を避けるために、参照データモデリングのプロセスにフォーカスしたMDM Alliance Group (MAG)で公開されているような、既にあるデータアーキテクチャモデルを選択するかもしれません。
図2. マスターデータ管理
ビジネスルールの面では、いくつかのアルゴリズムのパーツが、BRMSのルールとして書き直すために、既存のコードからとりだされなくてはなりません。流用したコードを置き換えるために、ある呼び出しがルールエンジンに追加されます。そのルールエンジンの呼び出しによって送信されたビジネスデータは、先に説明した共通情報モデルに順守して形式化されます。BRMSやMDMシステムは、大抵が異機種環境で現行システムで動いている物理的な表現から独立した同じデータモデルを共有します。ルールの発見は、簡単な作業ではありません。それは、ビジネスとITのチーム間での協調が必要です。一緒に、彼らはITシステムを分析し、内部に潜んでいるルールを発見(あるいは再発見)します(図3)。
図3. ACMSの実際
統治された情報のセマンティクスとシステムの俊敏性は、それらが必要不可欠なものであることが最近になって理解されているため、さらなるITの主要な課題となります。これらの課題は、サービス指向アーキテクチャを基盤に構築されたACMSの原則に従った情報システムに対して、困難なリエンジニアリングや作りかえをおこなうことだけで解決されるものではないでしょう。幸いなことに、この作業は段階を経ておこなうことができ、途中で価値を追加することができます。特に、それを動かすための主要な要素には、企業活動の可視化(と監査能力)や価値によるポートフォリオ管理を含みます。すべての組織によってなされた進展は、上級管理者や株主に意味のある危機管理指標を提供するために公的に評価されなければなりません。