次の方法で共有


Total Economic Impact(トータルな経済的影響) - 入門

Giga は、IT の意思決定を分析するための Total Economic Impact(TEI) モデルを開発しました。TEI は、所有の総コスト (TCO) と、コストを最小化するためのベスト プラクティス アプローチをベースにしています。

コスト

どのようなプロジェクト評価モデルであれ、包括的なコスト コンポーネントを組み込む必要があります。これには、ハードウェアとソフトウェアのキャピタル コスト、継続的な保守と運用、調達のための間接コスト、テクノロジ アセットの追跡などが含まれます。

しかし、Giga の TEI 分析は、TCO の範囲を超えて、次の 3 つの要因を明示的に組み込んでいます。

1. ベネフィット

あらゆる IT プロジェクトの目標は、ユーザーに対して、彼らのビジネス ファンクションの遂行を改善するようなコンピューティング サービスを提供することです。IT は、プロジェクトのビジネス ユニット スポンサーとともに、ユーザーの業務遂行の測定可能な変化として、どのような要素を取り上げるかを決定します。いったん行動上の変化が測定されたら、これらの測定値に値を割り当てることで、任意の個々のプロジェクトの投資収益を簡単に計算することができます。ベネフィットを推定するための単純なアプローチの 1 つは、将来の特定の時点における企業の姿を、2 つのパラレルなバージョンとして想像してみることです。1 つは予想されるシステムまたは変化が導入された場合の姿、1 つはそうでない場合の姿です。この 2 つの環境の違いを、システムの目標を基準として評価することにより、システムのベネフィットの推定値を得ることができます。

2. 柔軟性

システムの柔軟性は、後の時点で現実化する遅延型の、または潜在的なベネフィットと考えることができます。株式のオプションを購入するのと似て、今日のニーズを超えた IT インフラストラクチャに投資を行うことで、企業は将来に他のアプリケーションを配置できる能力を手に入れることができます。

3. リスク

リスクは、通常は予想される結果の不確実性の増大として理解されます。IT の投資のリスクが大きいほど、実際の結果が可能性が高い、または予想される結果からずれる確率が高くなります。このように、リスクはコスト、ベネフィット、または柔軟性の分析結果の誤差を拡大し、可能な結果の範囲を広げることになります。

IT が行う特定の決定には、さまざまな種類のリスクが関わります。プロダクトのリスク (あるプロダクトが予想どおりに機能しない)、アーキテクチャのリスク (選択したアーキテクチャが目的の拡大を簡単にはサポートできない)、文化のリスク (企業が新しいシステムに予期しない形で反応する) などです。

要約すると、TCO は効率性を意味するのに対し、TEI は効果の強さを測定します。TEI を使うことで、企業は個々の企業目標という観点からプロジェクトとプロダクトに関する決定を評価し、TCO の「コスト センタ」的な立場から、企業の戦略的な「バリュー センタ」的な立場に移行することができます。

図 2: Total Economic Impact モデル

この調査では、Giga はこの TEI モデルを適用し、大規模なユーザーが Exchange の配置を決定する際に考慮すべきさまざまな要素を理解するための包括的な情報を読者に提供します。

参加企業の要約

26 の参加企業のうち、約 1/3(34.6%) が Exchange に移行する前に複数のメール システムを使用しており、同じ比率の企業が MS Mail だけを使用していました。「複数のシステム」と回答した企業は、幅広いシステムを利用しており、MS Mail とその前身、Lotus(IBM) の cc:Mail、さらには IBM の Profs、Banyan の Beyond Mail、Novell の GroupWise などの名前が挙がりました。

このような混在システムの多様性が生じた原因としては、他の企業を買収したため、部門レベルで脱集中的な IT の意思決定を許したため、政治的な問題があったため、そして一般論としてエンタプライズ レベルでの計画が不十分だったためなどがあります。これらの状況は、一般に、非効率的なメール、互換性のない添付ファイル、メールの配信の遅れや消失、そして最終的には電子メールに依存するようになった経営陣の強いフラストレーションなどの結果を生み出しました。

図 3: 参加企業のロケーションにインストールされていたメール システム

Exchange の配置にあたって設定された主目標

この調査では、参加企業に対して、Exchange に移行するにあたっての目標は何だったのか、また現時点でその目標がどれほど達成されていると思うかを尋ねました。以下に示すのは、よく言及されたテーマの一部です。

  • 単一の、信頼の置ける、スケーラブルなエンタプライズ メール環境を開発すること
  • エンタプライズ内でディレクトリをシームレスに統合すること
  • ホスト ベースのメール システムをなくすこと
  • システムのフレンドリさとユーザビリティを高めること
  • 従業員の生産性を高めること
  • メール環境に付随するサポートと管理を軽減すること
  • 他のデスクトップ アプリケーションとの相互運用が可能なシステムを提供すること
  • 2000 年問題に対処すること
  • グループウェア、ワークフロー、およびセールス フォース オートメーションのためのプラットフォームを提供すること
  • 従業員、サプライヤ、およびカスタマとのコミュニケーションを改善すること
  • 複数の互換性のないメール システムをなくすこと
  • 業界標準の高機能なプラットフォームを提供すること
  • ローカルおよびリモート メールの信頼性を改善すること

このリストは優先度の順に並べたものではなく、回答を寄せた企業から報告された目標を要約したものです。これらの目標が達成できたかどうかという点については、参加者は 1 ~ 5 のスケールで (成功度は 1 が低く、5 が高い)、全体として 4.4 という比較的高いスコアを回答しました。これは、インプリメンテーションが比較的成功したことを示しています。

ほとんどの企業は、調査の時点で、Exchange インフラストラクチャの大部分をすでに配置していました。典型的な配置プロセスでは、まずメール、カレンダリング、スケジューリング、およびディスカッション グループ機能がインストールされます。これらのインプリメントが終わると、IT は、インフラストラクチャを活用するアプリケーションの開発に焦点を移し、よりコラボレーション性の強いアプリケーションの開発に着手します。これらの配置作業は、一般に、さまざまな予算、地理、および人的資源の制約に基づいて、複数のフェーズに分けた形でロールアウトされることがわかりました。そのため、後の方の開発サイクルでの、コラボレーティブ アプリケーションに焦点を当てたイニシアティブの多くは、部分的にしか配置されていなかったり、開発が終了していなかったりしました。

Giga が調査した企業のほぼ 3/4(73%) が、Exchange を全世界的に配置する計画を持っていました。残りの 1/4 は、その多様性、組織構造、および (または) 政治的な理由から、複数のメール環境を維持する予定でいるか、複数のシステムを持つべきかどうかをまだ決めていませんでした。

これらの企業の約 35% が、Exchange への移行の前には複数の既存メール システムを持っていました。Giga は、複数のメール環境を維持するのにはコストがかかることを示しており、全体的な影響をよりよく把握するためには、直接コストだけを評価するのではなく、TEI に関連する要素も評価することを勧めています。これらの発見は、この調査の参加者からのフィードバックによっても裏づけられました。複数のシステムを維持するときの、直接コストには現れない本質的な非効率性は、システムの運用を効果的に管理する企業の能力に大きな影響を与えます。

大部分のサイトは、Exchange によって、事前に設定されていた目標が達成されたことにきわめて満足していましたが、少数のサイトは配置が十分に進んでいないので、まだ判断ができないと報告しています。最初の時点で設定したすべての目標が完全に達成できなかったことの理由としては、さまざまな組織上の、また何らかのロジスティックス上の問題が挙げられました。たとえば、いくつかの企業では、所有権、更新、アクセス特権、一般的な保守の責任などに関する規則を確立することができないという問題のために、パブリック フォルダの配置が遅れています。また、最初の設計計画に含まれていた能力の一部を配置しなかった理由としては、コストの回収の問題や、インプリメントの方法などが挙げられています。