Loading article…
統合コンピテンシーセンター（ICC）は、統合センターオブエクセレンス（COE）とも呼ばれ、組織内、特に大企業や公共機関において、体系的なデータ統合、システム統合、またはエンタープライズアプリケーション統合を提供する共有サービス機能です。
データ統合により、企業は、ばらばらのシステムに分散している企業データや機能にアクセスし、コア情報やプロセス資産を統合された正確かつ一貫性のあるビューとして作成し、企業全体で活用してビジネス上の意思決定や業務を推進することができます。システム統合とは、構成要素となるサブシステムを統合し、それらが効果的に連携して機能することを保証することです。エンタープライズアプリケーション統合は、個別のコンピュータアプリケーション間で効率的な情報交換とビジネスプロセスの自動化を、一貫性のある形で実現します。
頭字語を分解すると理解が深まるかもしれません。統合とは、ICCが全体的な視点に立ち、複数の機能グループにわたってコスト効率、組織の俊敏性と有効性、運用リスク、顧客（内部または外部）体験などの特定の特性を最適化するという目的を指します。能力とは、ICCがサービスとして提供する専門知識、知識、または能力を指します。センターとは、サービスが、それがサポートする機能領域とは独立した共通の（中央の）ポイントから管理または調整されることを意味します。
大規模組織は通常、マーケティング、営業、流通、財務、人事など、さまざまな機能分野に細分化されています。これらの機能グループはそれぞれ独立した業務を行い、垂直統合されており、「サイロ」や「縦割り組織」と呼ばれることもあります。組織的な観点から見ると、ICC（統合コミュニケーションセンター）とは、特別なスキルを持つ人々が集まり、中央で調整され、個別の機能分野が連携して取り組む必要のあるミッションを達成するためのサービスを提供する組織です。
ICCの主な目的は以下のとおりです。
ICCは企業に以下のことを可能にします。
ICCは、プログラムを支援する一時的なグループである場合もあれば、組織の恒久的な一部である場合もある。さらに、ICCは、企業の部門内、企業全体、あるいはサプライチェーンにおける複数の企業間など、さまざまな規模やレベルで設立することができる。
「インテグレーション コンピテンシー センター」という用語とその頭字語 ICC は、 2001 年に「インテグレーション コンピテンシー センター」から始まる一連の記事やカンファレンス プレゼンテーションで、ガートナーのロイ シュルテによって普及しました。[ 1 ]彼は同僚のゲイリー ロングからこの用語を聞き、ロングは顧客の一部がこれを使っているのを発見しました (彼らは既存の用語「コンピテンシー センター」をインテグレーションに適用しました)。それ以前 (1997 年から 2001 年まで)、ガートナーはこれを中央インテグレーション チームと呼んでいました。概念自体は (ラベルが付けられる前でも)、1996 年にガートナーがインテグレーションについて最初に発表したレポートの 1 つです。
大きな節目となったのは、2005年にジョン・G・シュミットとデビッド・ライルによるこのテーマに関する最初の書籍『 Integration Competency Center: An Implementation Methodology』[ 1 ]が出版されたことである。この書籍では、5つのICC組織モデルが紹介され、ICCの人材、プロセス、テクノロジーの側面が探求されている。この書籍のレビューは、IT ToolboxやAmazonでいくつか見ることができる。IT領域における能力としての統合という概念は、10年以上存続しており、勢いを増し、広く受け入れられつつあるようだ。
近年、ICCは統合センター・オブ・エクセレンス、SOAセンター・オブ・エクセレンス、データ管理センター・オブ・エクセレンスなど、さまざまな名称で呼ばれるようになりました。最先端のICCは、リーン統合手法を用いてエンドツーエンドのプロセスを最適化し、継続的な改善を推進しています。大学でも、MBAプログラムやコンピュータサイエンスのカリキュラムに統合に関するトピックを取り入れ始めています。例えば、ペンシルベニア州立大学の情報科学技術学部は、以下のミッションを掲げたエンタープライズ情報学・統合センターを設立しました。
「エンタープライズ情報学・統合センター（EI²）は、企業プロセス、知識管理、意思決定における重要な課題に取り組むため、産業界、非営利団体、政府機関のリーダーと積極的に連携していく。」
ICCの組織形態には様々な方法があり、その任務範囲も多岐にわたります。ICCに関する書籍[ 1 ]では、5つのICC組織モデルを紹介し、ICCの人材、プロセス、テクノロジーの側面を探求しています。それらは以下の通りです。
このICCモデルの主な機能は、効果的で広く適用可能なプラクティスを文書化することです。プロジェクト全体にこれらの標準を実装するための中央サポートチームや開発チームは含まれておらず、通常はメタデータの管理も行いません。ベストプラクティスICCを実装するには、企業は多様なチームに対応し、既存のシステムやプロセスを強化・拡張できる開発環境を必要とします。このチームは多くの場合、既存のエンタープライズアーキテクチャ機能の一部であり、通常は少数のスタッフ（1～5名）で構成されます。
標準サービスICCは、ベストプラクティスICCと同様の知識共有を提供するだけでなく、ソフトウェア開発とハードウェア選定における技術的な一貫性を徹底します。標準サービスICCは、命名規則の標準化と徹底、メタデータ標準の確立、変更管理手順の導入、標準に関するトレーニングの提供といったプロセスに重点を置いています。また、このタイプのICCは、新興技術の評価、ベンダーの選定、ハードウェアおよびソフトウェアシステムの管理も行います。通常、エンタープライズアーキテクチャチームと密接に連携しており、ベストプラクティスICCよりも規模が大きい場合があります。
共有サービス型ICCは、開発サポートから本番環境のプロジェクト向けヘルプデスクまで、幅広いサポート付き技術環境とサービスを提供します。このタイプのICCは、ベストプラクティスや標準サービスモデルよりもはるかに複雑です。製品トレーニング、標準の適用、技術ベンチマーク、メタデータ管理などの知識管理プロセスを確立し、プロジェクト全体にわたる影響分析、ソフトウェア品質、開発者リソースの効率的な活用を促進します。共有サービス型ICCの組織構造は、ハイブリッド型またはフェデレーション型モデルと呼ばれることもあり、多くの場合、小規模な中央調整チームと、複数の分散チームとの点線による報告関係で構成されます。
中央サービスICCは、企業全体の統合を管理します。他のモデルと同様のプロセスを実行しますが、通常は独自の予算とチャージバック方式を持ちます。また、開発プロジェクトに対して、管理、開発リソース、データプロファイリング、データ品質、単体テストなど、より多くのサポートを提供します。中央サービスICCは他のモデルよりも開発活動に深く関与するため、運用オペレーターとデータ統合開発者が必要です。中央サービスICCのスタッフは必ずしも中央に配置されている必要はなく、地理的に分散していても構いません。重要な違いは、スタッフがICCディレクターに対して明確な報告関係を持っていることです。これらのチームの規模は様々で、組織のITスタッフの10～15%にも達することがあります。
セルフサービス型ICCは、組織における最高レベルの成熟度を表します。ICC自体は、その機能が日々のシステム開発ライフサイクルに深く根付いており、インフラストラクチャと緊密に統合されているため、ほとんど目に見えない存在となり、維持に必要なのは小規模な中央チームのみとなる場合もあります。このICCモデルは、非常に効率的な運用を実現すると同時に、独立した開発とイノベーションが花開く環境を提供します。この目標は、ツールとシステムによって実現される自動化プロセスを通じて、一連のアプリケーション統合標準を厳格に適用することで達成されます。
ICC（統合コミュニケーションセンター）という概念自体は非常にシンプルです。共有サービスを提供するためのITマネジメントのベストプラクティスを具現化したものです。しかし、組織的な概念であるため、組織ごとに異なる特性があり、ICCを成功させるには個々の組織に合わせたカスタマイズが必要となるため、概念的な理解よりも実際の導入ははるかに困難です。以下に、ICC設立の過程でよく見られる課題をいくつか挙げます。
ICCへの投資に着手する際には、これらの問題を考慮することが重要です。なぜなら、ICC導入の最終段階こそが最も重要だからです。組織内で実施されないICCの知的定義は、企業にとって何の価値もありません。