<皮肉>
ベンダーは常に完全かつ確実にTCOを計算し、統計を歪めたり、最適な構成を選択したりすることはありません。
</ sarcasm>
TCOシステムを開始する前に、組織がTCOシステムを計算するための独自の定義を作成できることが重要です。 オープンソースの支持者は、しばしばシステムの初期コストが低いことを急いで指摘します。 批評家は、メンテナンスの潜在的に高いコストを指摘します。 STRの支持者は、自由の側面と、それに対応する移行の低コストに重点を置いています。 これらの点はすべて真実ですが、全体として状況を説明するものはありません。 ITシステムのTCOは、次の4つのコンポーネントに分割できます。
*システム取得費用
*新しいシステムへの移行コスト
*システムメンテナンスコスト
*システムを放棄するコスト
更新を評価するときには、これらのそれぞれを考慮する必要があります。
初期費用
このセクションでは、フリーソフトウェアに明確な利点があります。 ゼロコストで、それは明らかな勝者です...現時点では、多くの商用ソフトウェア開発会社がこれを実際に学び、オープンソースソフトウェアの競合他社がいる地域で無料の製品を提供しています。 このような企業は、製品のソースコードにアクセスできるだけで、実際にサポートを提供できるのは彼らだけなので、有料サポートに焦点を当てています。
もちろん、標準的な配信のコストはストーリーの一部にしかならないことがあります。 多くの場合、ソフトウェアは特定のビジネスで使用するために改良が必要です。 フリーソフトウェアを使用する場合、提供された一連のインターフェイスを介して作業を行ったり、スクリプトを台無しにしたりする代わりに、ユーザー（または会社に雇われた請負業者）がコードを直接変更できるため、この問題に大きな柔軟性を持たせることができます。
フリーソフトウェアを変更する場合は、組織内でフォークしたままにするか、メインバージョンに変更を加える必要があります。 最初のオプションは高価になる可能性があります-メインツリーからの変更を定期的にコピーにマージする人に支払う必要があります-しかし、このオプションは短期的には競争上の優位性があります。 ソフトウェアを使用するだけで、それを中心にビジネスを構築しない場合、変更をリリースしても何も失われず、他の人がエラーの修正に役立つという事実から利益を得ます。 さらに良いことに、必要な変更が他の人にとって有用であれば、開発コストを彼らと分担できるかもしれません。
移行費用
すばらしい発見は、いくつかのメニュー項目がMicrosoft OfficeとOpenOfficeの異なる場所にあることを理解する価値があるということです。 さらに顕著なのは、同じ人がMS Officeの異なるバージョンで同じメニュー項目を移動した場合、何も学ぶ必要がないという事実です。
新しいシステムに適応するには時間がかかります。 追加の依存関係がある場合があります。たとえば、新しいWebアプリケーションには新しいDBMSが必要になる場合があります。 または、スタッフのトレーニングが必要です。
コンバージョンコストを評価するときには客観的になります。 スタッフが異なるワードプロセッサを切り替えるために大幅な再トレーニングを必要とする場合、おそらく現在のツールを効果的に使用していないでしょう。 この場合、Webインターフェイスやテンプレートシステムなど、まったく異なるものに切り替えることを検討できます。これは、より問題指向のアプローチを提供します。
システム管理のスキルは多少異なります。 管理者は、特定のソフトウェアのすべての機能と癖に精通している必要があります。 これには何らかのトレーニングが必要な場合がありますが、開発者の強力なコミュニティが存在する場合は部分的に相殺できます。
ほとんどの商用ソフトウェアは、ある程度のカスタマイズが必要であり、多くの場合、サードパーティ組織によってサポートされています。 サードパーティのサポートの機会がある場合、多くの場合、それは安価です。 これは、オープンソフトウェアとクローズソフトウェアにも適用されます。 ただし、これはフリーソフトウェアのより一般的なものです。
システム保守費用
非常に少数のシステム、ハードウェアまたはソフトウェアをインストールして忘れることができます。 ほとんどの場合、比phor的または文字通りの定期的なオイル交換が必要です。 プログラムの場合、メインフォームはサプライヤからの更新プログラムのインストールです。
ほとんどのアップデートは、リリース前に徹底的にテストされています。 残念ながら、問題を引き起こす可能性のあるハードウェアとソフトウェアのすべての可能な組み合わせをテストすることは不可能であり、多くの場合、その場で追加のテストが必要になります。 多くの場合、これはテスト用に予備のシステムが必要であることを意味します。これは動作中のシステムと同じ構成です。
セキュリティ更新プログラムはより不安定です。 多くの場合、パッチがリリースされる前に脆弱性が公開され、システムが脆弱になります。 そうでなくても、クラッカーにとって、脆弱性を識別するためのパッチのリバースエンジニアリングは完全に明白です。
リリーススケジュールも重要な考慮事項です。 パッチが定期的にリリースされると、インストールの計画が簡単になり、コストが削減されます。
製品のセキュリティレポートが不十分である場合、管理者は脆弱性を投稿してから検証済みの修正プログラムをインストールするまでの間に一時的な措置を取る可能性があります。
システム放棄費用
最も重要な-見落とされた-最終的なコスト。 ある時点で、すばらしい新しいシステムは時代遅れになります。 これには多くの理由が考えられます。 製造会社はサポートを終了するか、単に破産する場合があります。 開発者は、システムでの作業を停止することを決定できます。 これは、現時点で必要な機能が不足している可能性があります。
このターニングポイントに到達したら、代替手段を探す必要があります。 システムにどのように依存していますか？ 重要なインフラストラクチャを構築するために使用しましたか？
オープンスタンダードが重要になりつつあります。 システムが標準に準拠している場合は、比較的簡単に他のシステムに置き換えることができます。これは、ベンダーにとって標準がやや不人気になる事実です。
標準がない場合、依存関係チェーンは非常に長くなる可能性があります。 非標準のAPIを使用して作成されたソフトウェアを使用する場合、オペレーティングシステムを簡単に置き換えることはできません。 このソフトウェアが非標準形式でデータを保存している場合、簡単に置き換えることはできません。
POSIXやX11などの標準をサポートするオペレーティングシステムを選択した場合、既存のソースコードをこれらの標準をサポートする新しいプラットフォームに比較的簡単に移植できます。 ソースコードがない場合は、同型システムで適切に機能するバイナリ変換レベルがあります。
同様に、データがオープン形式で保存されている場合、アプリケーション間で簡単に移行できます。 OpenOfficeを使用してOpenDocumentファイルを作成する場合、すべてのドキュメントを新しい形式に変換することなく、AbiWordに切り替えることができます（たとえば）。
標準は、最低レベルのソフトウェアインターフェイスから高レベルのデータ表現まで、ソフトウェア開発のほとんどの分野に存在します。 ソフトウェアがそれらをサポートしている場合（同時に一意ではない場合）、 ベンダーロックインは比較的ありません。
おわりに
マイクロソフトは、製品から新製品への移行の低コストを頑固に強調しています。 多くのUNIXベンダーは、低いメンテナンスコストとベンダーバインディングの欠如を強調しています。
購入する前に、これらの計算を自分で実行し、最終的に決定にどれだけの費用がかかるかを確認することが重要です。