-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
監査の取締執行機関を排除する方法はありますか?
あります。
IBPL のベストプラクティスでは取締執行機関による監査の排除策として契約交渉における監査項目内の取締執行機関および第三者の指名という項目の削除を提言しています。
海外では実践者も増え、交渉時のポイントとして一般化してきています。
IAITAM CSAM 講習でも、このポイントについては講義しています。
資産の標準化によるメリットはなんですか?
IT資産管理とITサービス管理の関係がよくわからないのですが?
資産管理を行う上で、簡単に何をやるのかを3つのステップぐらいでまとめると、何をすればよい?
資産管理のためのベースラインの作成はどのように行えばよいですか?
SAMをアウトソーシングする場合に注意点はなんでしょう?
サービス提供者としてクライアント環境サービスを提供する場合の考慮ポイントはなんでしょう?
IT資産管理プログラムとプロジェクトの管理ポイントはなんですか?
IT資産管理サービスを提供する場合に必要となるツールはなんですか?
IT資産管理プログラムの管理は、どのように計画すればよいのでしょう?
サービス提供者として運用チームに求められるものはなんですか?
ユーザー教育が必要だと言いますが、何故、必要なのでしょうか?
AMDB(資産管理DB)/ CMDB(構成管理DB) の位置づけ?
サービス提供者として提供すべきIT資産管理サービスってなんですか?
ライセンス監査の実行者であるBSAって誰(どんな組織)ですか?
ライセンス違反の取り締まり執行機関にはどのような組織がありますか?
米国不正競争防止法が資産管理に関係するのですか?
関係します。
例えば日本の製造メーカーの中国拠点で違法ソフト(低価格または無料のコピー)を使用した結果、競争力の高い、低コストの製品を製造できたとします。
その輸出対象国が米国で会った場合、正規のソフトウェア・ライセンスの使用料を支払ってコストが高くなったために違法ソフトを使用した企業の製品との正当な競争ができなくなった場合、不正競争防止法が関係してきます。
この場合、日本の製造メーカーが中国で生産した製品を対象地域で販売できなくなる、あるいは、罰金が科せられる可能性があります。
参考資料:
http://monoist.atmarkit.co.jp/mn/articles/1305/24/news065.html
http://www.shinnihon.or.jp/industries/technology/knowledge/pdf/Technology-2012-12-02-J.pdf
IT資産管理お勧めのツールはありますか?
ツールは大きく分けてインベントリ収集のためのエージェント・ツールと、情報の関係性を管理するAMDB(資産管理DB)/CMDB(構成管理DB)に大別できますが、どちらも選択の際にはいくつかの注意点があります。
インベントリ収集はWMI/DMI インタフェースを用いているので、ツールによって収集できる情報の差異はありません。ただし、取得可能なすべての情報を収集するとテキスト情報だけで2MBぐらいになるのでインベントリ収集のトラフィックが大きくなりすぎてしまいます。
多くのツールが100kから200kぐらいのサイズに制限してインベントリ情報をサーバに送っていますが、この際に、捨てる情報、あるいは収集する情報が、目的達成のために必要十分であるかどうかを検証し、不足しているようであれば、充足するために収集情報を指定して展開する必要があります。
また、AMDB/CMDB も、必要となるすべての情報を網羅するテーブル設計になっているのかどうか、テーブルのフィールドが充足しているのか、などを確認する必要があります。
いずれにしても、プロセス設計の結果、目的に則った要件定義のもと選択する必要があります。
SCCM をデフォルトで展開していますが、資産管理情報として利用できますか?
できません。
残念ながら、SCCM をデフォルトで展開している場合、AMDB/CMDB との突合のための準備ができていない可能性が大です。
一意識別子/物理識別子による個体の特定とAMDB/CMDB の資産管理番号で管理されるレコードとの紐付などができていないと、ソフトウェアインベントリを収集していたとしても突合作業ができません。
データだけが蓄積されていてもデータクレンジングが必要だったり、コンピュータ名と実際の使用者が紐づかなかったり、整合化や是正措置に必要な情報が不足していたりします。
資産標準として登録される情報はどのように利用されますか?
資産の標準化の目的は、マスター化し、整合性がとれた自動化システムを構築するためにマスター情報を常に参照することにあります。
標準化された資産はマスター登録され、登録名やインデックス番号などで自動化ツール上での整合を維持します。
マスター化されていない資産は、その資産情報にゆれが発生し、名寄せが求められるようになると、データクレンジングを定期的にする必要がでて、工数を上げることになってしまいます。
標準化されたハードウェア名称のマスター化
標準化されたソフトウェア契約と利用規約のマスター化
標準化されたソフトウェアライセンス名称のマスター化
これらはサービスカタログ(資産カタログ)において選択可能な標準資産として提供され、発注書、納品書、請求書において統一された名称、情報粒度で扱われることで、資産登録プロセス、受領プロセス、支払プロセスなどで情報の突合、確認処理が効率的に実施されます。
また、ソフトウェアライセンスの割り当て処理、ソフトウェアのインベントリ収集と突合処理などにおいても、インベントリ収集したライセンス名称の名寄せの自動化および突合処理において標準化され、マスター化された情報は整合性の維持と自動化の正確性、効率性を高めます。
考慮するポイント:
ソフトウェアライセンス名称のライブラリ:ソフトウェアインベントリ名寄せ辞書(ソフトウェア辞書)
利用規約のライブラリ:利用規約辞書(ソフトウェア辞書)
インシデント管理-リクエスト管理-承認プロセス(サービスカタログ/資産カタログ)
資産管理番号、論理識別子と物理識別子ってなんですか?
IT資産(ハード、ソフト、契約)を管理する場合、これらを管理するために組織が割り当てる管理番号が必要となります。
つまり、論理的に対象資産を管理するための通し番号として資産管理番号を論理的にに割り当てる、ということです。
この場合、一意の資産を論理的に識別するので、論理識別子と呼びます。
一方、ハード、ソフトウェアの契約などは、特定のハードを一意に識別する物理識別子を持って、論理識別子と紐付て管理する必要があります。
この場合、ハードを一意に識別できるシリアル番号やMACアドレスなどを一意識別子として識別し、論理識別子と紐付て管理します。
AMDB/CMDB で契約書、発注書によって識別された新規の資産は資産登録され、最初に、論理識別子である資産管理番号を付与されます。
調達-納品における受領プロセスにおいて物理識別子(シリアル番号)が識別され、インベントリ収集の際の主キーとしてAMDB/CMDB においける突合に使用されるために、AMDBに登録され、これによって論理識別子である資産管理番号と物理識別子となるシリアル番号が紐付られ、以降はインベントリ収集によって収集されたインベントリ情報のシリアル番号を主キーとして突合が自動的に行われるように設計します。
ライセンス監査の対策準備って何をしたらいい?
アウトソーシング(シートマネジメント)ってどんな事を期待したらよい?
ITサービスってなに?
サービス管理、セキュリティ管理、IT資産管理の整合性を維持するって、どういう意味?
IT資産管理はIT部門の仕事だ、と言って協力を拒否された場合、どうしたらよいでしょう?
ステークホルダーと役割って具体的にどのような人ですか?
ソフトウェアメーカーには監査権があり、いつでも監査に入れるというのは本当ですか?
本当です。
ソフトウェアライセンス契約には多くの場合、「監査権の行使」という条項が含まれています。
この条項には、ソフトウェアの著作権者および著作権者の指定する第三者が必要に応じて監査に入る権利を行使する、という内容が明示されていますので、いつでも監査に入ることができます。
また、万が一、ソフトウェアライセンス契約には明示されている条項が無かったとしても、著作権法や知的財産基本法などで著作権者に与えられた権利として監査権を行使することができますので、著作権者に法律が与えた権利ですから、著作権者の要求があった場合、それを拒否することはできません。
ITIL が関係するということですが、具体的にどのようなプロセスが関係するのでしょうか?
IT部門がサービス提供者として自律するという目標を持っている場合、IT部門の戦略としてサービスモデルをITIL を参照して実現しようとしていたとします。
IT資産管理は、サービスを提供する全ての資産を管理対象としますので、資産の標準化やユーザーからのリクエスト、運用中の変更管理など様々なプロセスにおいてITIL のプロセスを利用することになります。
具体的な例としては、例えば「標準化された資産のリクエスト」は、独立したIT資産管理の資産リクエストを管理して記録を取るなどせずに、ITIL のインシデント管理のインシデントチケット区分のリクエストなどでトラッキングします。
また、資産の使用中の変更管理も、独立したIT資産管理専用の変更管理システムを構築するのではなく、ITIL の変更管理システムを利用して記録をし、資産の使用中に発生する変更の経緯などをトラッキングします。
ITIL はシステム管理のプロセス・フレームワークではない、というのはどういう意味ですか?
ITIL は、ITIL V2 のオペレーション焦点の導入から、運用チームにとってはシステム管理のベスト・プラクティスと捉えられる傾向が強いのですが、ITIL 自体はIT部門がサービス提供者として自律するためのサービス・モデルというビジネス・モデルの参照フレームワークです。
ITIL では、サービス提供者としてのIT部門やITベンダーのあり方としての、戦略、マーケティング、サービス製品の設計/製造、デリバリ、運用、サービス製品の継続的な品質改善というサービスメーカーの品質コントロールにいたる参照プロセスを提供しています。
DevOps のように、運用が複雑化するIT環境のコントロール・タワーとして機能するためには、複雑なサービス提供者のライフサイクル・プロセスを実装する必要があるため、参照フレームワークとしてITIL が世界的に利用されているのです。
本当にIT資産管理プロジェクトのステークホルダーにCxOクラスの人が必要ですか?
本来は、IT資産管理プログラムのステークホルダーとしてCxOクラスの支援、後援を取り付けておいた方が良いのです。
しかし、IT資産管理プログラムが構築されていない場合は、プロジェクトレベルでCxOの支援、後援を取り付けて、IT戦略との整合を維持する重要性をCxOに理解を求め、IT資産管理を後ろ向きな、単なる「管理プロジェクト」から、前向きでIT戦略の実現を左右する「重要プロジェクト」へとポジションを変えることが大切です。
IT資産管理は組織横断的なBPR(ビジネス・プロセス・リエンジニアリング)が必要なのでしょうか?
はい。
これも組織の目標、目的によるのですが、大手組織における資産の最適化を目標とした場合、あるいは、ユーザーに対する課金の精度を上げる、さらには、将来はユーザーに対してユーティリティモデルのようなチャージバック(課金)モデルを実施したい、と言う場合は、標準化から発注を起点とする契約内容、会計情報を対象範囲とするIT資産管理のプロセスを、人事、契約、法務、業務、会計部門などを横断的に業務プロセスの統合を行う必要があります。
IT資産管理をアウトソースできますか?
できます。
まず必要なのは、自社の目標、目的を理解し、どのようなIT資産管理プログラムが必要なのかを把握し、プロセス設計を行います。
必要となるプロセスが文書化され、パターン化できれば、どの部分をアウトソースするのかが明確に設計できるようになります。
このとき、単なるツールの運用のアウトソーシングではない、ということに注意しましょう。
IT資産管理プロセスのアウトソーシングですから、ツールの機能運用のアウトソーシングに留まらず、必要となるアウトプットを定義し、SLA(サービスレベル契約)で明文化し、測定項目を明らかにしてアウトソーシングの契約をする必要があります。
海外では、クライアント環境の運用管理アウトソーシングは、シートマネジメントとして一般化してきましたが、国内ではツール運用のアウトソーシングが多いのでIT資産管理のアウトソーシングには注意する必要があります。
IT資産管理に ITIL は関係ありますか?
IT資産管理に ITIL が関係あるかどうかは、組織の目標によって決定されます。
例えば、あなたの組織がグローバルな組織で、ユーザーのIT部門への期待が、自律したIT部門、ベネフィット・センター/イノベーション・センターという期待であり、IT戦略としてコンソリデーション(統合化)、バーチャリゼーション(仮想化)を実施し、リソースプールを用いて資産の最適化を図ろう、という目標を持っている場合、可能性としては、ITサービス管理プログラムおよびプロセスの参照モデルとしてITIL をグローバルに参照する、とされている場合、IT資産管理もITILとの整合を維持している必要があります。
IT資産管理は、ITIL の”サービス資産および構成管理”(SACM)と密接な関係があり、構成管理システム(CMS)の構成管理DB(CMDB)の一翼を担っています。
この場合、適切なIT資産管理プロセスなしには、構成アイテムの情報精度、鮮度の高いCMDBの成功は無いと言えるでしょう。
SAM(ソフトウェア資産管理)とITAM(IT資産管理)の違いは何ですか?
簡単に言えば、視点の違いであり、組織にとっての目標、目的が同じであれば、SAMもITAMも同じプログラムで管理されます。
実際のプロセスから考えると、どちらを実現する場合でも、同じ管理プロセスが必要となります。
ソフトウェアのライセンス契約を管理する場合でも、それに紐付くハードウェアなどの情報が必要となりますので、いずれの場合でも管理対象は変わらないといっていいでしょう。
まずは広い視野からITに関係する資産管理を捉えて、目的によって細分化して考えてみるようにしましょう。
インベントリツールとAMDB(資産管理DB)とはツールが違うという事ですか?
そうです。
一般的なクライアント環境のPCやモバイルデバイスなどを対象としてインベントリ情報を収集するソフトウェアをエージェント・ソフトウェアと呼んでいますが、AMDB(資産管理DB、あるいはCMDB:構成管理DB)は、資産の保有情報を管理します。
資産の保有情報とは、発注書や契約書など、実際に組織として購入した資産を、誰に割り当てたのかを管理します。
インベントリ情報は、現状、実際に使用されている状態を管理する情報で、インベントリ情報を収集し、AMDBと突合して、割り当てて、意図した資産の状態で運用されているかを確認することができます。
IT資産管理は、クライアント環境の資産だけではなく、データセンターの資産も対象となるのですか?
広義のITAM(IT資産管理)は、ITに関係する全ての資産、つまり、クライアント環境からデータセンターまで、ハードウェアからソフトウェア、ソフトウェアのライセンス契約書からアウトソーシングの契約、クラウド契約まで全ての契約資産を含むIT資産を指しています。
IT資産管理は組織の規模や目的によってプロセスが違うのですか?
そうです。IT資産管理プログラムとプロセスは、組織のIT戦略や目標、目的によって実施するべき業務内容が異なります。IT戦略がIT部門のベネフィット・センター化、イノベーション・センター化というサービス・プロバイダとしてのIT部門の自律を期待しているのであれば、EA(Enterprise Archtecture)やITIL(IT Infrastructure Library)などとの整合が取れたIT資産管理戦略が求められ、IT戦略・ITサービス管理戦略やプログラムのロードマップと同期が取れているIT資産管理戦略とロードマップが必要となります。
したがって、実施すべきプロセスも異なってくる、というわけです。
ライセンス監査は毎年来るというのは本当ですか?
本当です。
一度監査に入られると、「管理体制が構築されていない」というラベルが貼られてしまいます。
簡単に言えば、ソフトウェアメーカーのブラックリストに載ってしまうという事です。
毎年同じソフトウェアメーカーが監査にくることは稀です。恐らく同じメーカーは2-3年周期レビュー監査に来ます。
しかし、近年は監査活動はソフトウェアメーカーにとって利益率の高い活動となっていますので、1社が来れば、次々とソフトウェアメーカーが監査にやってくる、という状況が日常化しています。
いつ、外部監査が来ても対応できるように、内部監査体制をしっかりと整えましょう。
IAITAM 日本支部に相談できますか?
はい。
IAITAM の会員であればIT資産管理に関してご相談ください。
ご相談メールの宛先は info@iaitam.jp または takeuchi@iaitam.jp まで。
また、パブリックフォーラムでご相談いただくことも可能です。
ツール選択で注意すべきポイントはなんでしょう?
IT部門内でおさまるIT資産管理は、可能ですか?
いいえ。
残念ながら、良く耳にするのは
「IT部門内でおさまるIT資産管理をやりたい」とか、
「IT部門は、間接部門なので組織横断的な協力を求めるのは難しい」とか、
「財務、法務、人事などの部門は、自分たちのシステムで完結しているので協力を得られない」などのIT部門の悲痛な叫びでし。
しかし、今までに少なくとも1回、あるいは2回以上IT資産管理に取り組みながら、その取り組みが成功だった、と認識されていない場合、多くの場合の原因は「ステークホルダー」と「スコープ」の問題であるといっても過言ではありません。
ただし、これはIT資産管理を任されたプログラム マネジャーや、プロジェクト マネジャーの責任ではないのです。
これは、明らかにIT資産管理の重要性と取り組みについてのIT担当役員(CIO)の認識不足であり、多くの場合、プログラム マネジャーや、プロジェクト マネジャーは、これらの必要性を経営層に訴え続けてきているのです。
そして、IT担当役員の認識を得られ、IT担当役員が組織横断的な協力を求めるべく各部門長と交渉し、IT部門のプログラム マネジャーに対して責任だけでなく、権限を委譲し、関係各部門からプログラムに参加するメンバーを供出させることができれば、IT資産管理プログラムの成功率を飛躍的に向上させることができることは、数あるプログラム/プロジェクトの前例から立証されているのです。
「IT資産管理は所詮、後ろ向きな取り組みだから重要ではない」などという経営者がいたとすれば、それは、
「IT部門はいつまでもコストセンターでいい」、つまりは、IT部門はどこまでいっても
「技術サービス」を提供するコストセンターに留まらせる、という決断を下したに等しいのです。
もしも、IT部門をプロフィット センター(ベネフィット・センター/イノベーション・センター)として、サービスモデルの実現を目標にIT戦略を構築している、あるいは、しようとしているのであれば、まったく、その動きと相反した矛盾した言動と言えるのです。
組織は、コンソリデーションを行っているだろうか?
仮想化を行っているだろうか?
リソース プールを構築しているだろうか?
ビジネス ユーザーのニーズを捉え、迅速に対応するためにサービス指向アーキテクチャ(SOA)へ移行しようとしているだろうか?
クラウド サービスの採用などにより、ハイブリッド クラウドの採用を考えているだろうか?
これらの問いへの回答がYESである場合、それは、すなわち、サービス モデルへの移行を意味しています。
つまり、ユーザーあるいは経営者の期待は、IT部門が「部品の提供者」で「コストセンター」であったところから、
「サービス プロダクトの提供者」で「プロフィット センター」として自律する能力を求めているのです。
これから、ますますサービス プロバイダによるサービス プロダクトの競争が激しくなっていくなか、IT部門は可能であれば1st Tier(ユーザーに直接対応する唯一のプロバイダ)サービス プロバイダのポジションを確保すべきです。
ところが、もちろんのこと選択肢としては、大手ベンダーが虎視眈々そのポジションを狙っているのです。
IT資産管理プログラムは、サービス プロダクトを提供する上で、メーカー(サービス製造者)にとってはBOM(Bill of Material)管理に等しいのです。
IT担当役員(CIO)は今こそ認識を改め、IT資産管理プログラムに真剣に取り組む必要があると言えるのです。
IT資産管理プログラム・アーキテクチャを管理する必要がありますか?
はい。
「ステークホルダーの特定」や「スコープ計画」などからも理解できるように、IT資産管理プログラムでは、複数の立場、目的などが折り重なるメッシュ状態の関係を管理することが必要となります。
例えばIBPLなどのフレームワークを参照する場合、それぞれの管理プロセス エリアの依存関係をアーキテクチャとして図示していますが、複雑に関係するプログラム構成要素間の関係を構造化し、統制ルールに準拠させなければなりません。
また、IT資産管理プログラムのコンポーネントである調達、法務、財務、コンプライアンスなどは、それぞれのインターフェースについて透明性のある管理が重要となります。
プログラム アーキテクチャは、目的が異なるステークホルダー間の関係を明確にし、同じ目標を持ってIT資産管理プログラムに取り組むための共通理解を得るためにも重要な役割を担うのでプログラム チームのメンバーからステークホルダー全てに対してのコミュニケーション計画や教育計画に含むべき内容と言えます。
プログラム アーキテクチャには、プログラムを構成する以下のプロセス エリアを含む。
1.ポリシー管理
2.ベンダー管理
3.財務管理
4.調達管理
5.法務管理
6.コンプライアンス管理
7.資産識別管理
8.廃棄管理
これらのプロセス エリア間の依存関係やインターフェースには以下の項目を含むが全てではない。
1.調達ポリシー
2.環境要件
3.購入情報
4.パフォーマンス情報
5.購買情報
6.資産パフォーマンス
7.一意識別子
8.突合・整合化データ
9.要求事項
10.再配置・変更
11.法令順守要件
12.法令・法規
13.税法
14.財務記録
15.課金
何故、組織横断的なステークホルダーの識別が重要なのですか?
IT資産管理プログラムの管理で最も重要であり、困難なプロセスは「ステークホルダーの特定」や、「スコープ計画」などが考えられます。
何故ならば、ステークホルダーを特定するためには、まず現在のIT資産管理のプロセスを洗い出し、フローチャート化し、すべての関係プロセスを明らかにした後に、それらのプロセスに関係する人物を部門や職務内容に関係なく網羅的に列挙する必要があるし、それは、IT部門に留まらないので、他部門へ問い合わせて他部門における関係プロセスも明らかにする必要があるからです。
もし、この作業を避けて通れば、IT資産管理の管理システムはIT部門の部分的な最適化を実現しても、部門横断的な全体最適化を実現することは不可能となり、IT資産管理に関係するデータの信頼性や、鮮度の維持、データ利用の効率化と効果的な管理システムの自動化テクノロジーの運用を妨げることとなります。
つまり、IT資産のライフサイクル プロセスの管理は、それに関係するすべての関係者の効率化や効果的な管理システムと自動化テクノロジーの運用なくして、実現はありえないと言えるのです。
そのためには、まず、「ステークホルダーの特定」や「ステークホルダーの期待管理」を「スコープ計画」や「目標と目的」、「要求事項定義」などと合わせて、全体戦略との整合性がとれたロードマップを構成するに足るIT資産管理プログラムの計画を構築することが求められるのです。
段階的な導入とは、どのように計画したら良いのでしょう?
IT資産管理プログラムは、ITサービス管理プログラムのプロセスを共有する部分も多く、インターフェースや統合を考慮していないと、独立したマネジメントシステムが構築され、最終的な結果を、効率的に統合できなくなる可能性が高い。(例:要求実現、インシデント管理、問題管理、変更管理、構成管理、サプライヤ管理など)
また、セキュリティ管理プログラムともユーザー顧客における体制構築において共有されるべき部分が多く、インターフェースや統合を考慮していないと、独立した組織構造が構築され、効率的、効果的な運用が妨げられる。
IT戦略における目標を明確にし、その目標を実現するためのロードマップをITサービス管理、IT資産管理、セキュリティ管理という標準やベストプラクティスを参照し、統合された形で実施していくためにそれぞれのプログラムを管理し、プログラムやプロジェクトの整合性を維持していくためのシステムを構築する。
ここでいうシステムとは、マネジメント・システムとして、インプットとアウトプットがあり、一つのアウトプットが、次のプロセスのインプットとなり、新たなアウトプットを生成するというシステムを指している。
ロードマップの作成には、「あるべき姿(ToBe)」のモデルが明示されていなければならない。現状である「ありのままの姿(AsIs)」を把握し、そこにある問題を明らかにし、あるべき姿へはどのように、これら問題を解決し、ギャップを埋め、段階的に近づいていくかを計画しなければならない。
IT資産管理者の教育はどのようにしたらよいでしょうか?
IAITAM の教育プログラムは、主要プロセスエリアの定義に則ってハードウェア資産管理担当者、ソフトウェア資産管理担当者、IT資産管理担当者向けに設計されています。
ソフトウェア資産管理者教育としてCSAM (Certified Software Asset Manager: 認定ソフトウェア資産管理者)、CHAMP (Certified Hardware Asset Manager Program: 認定ハードウェア資産管理者プログラム)、CITAM (Certified IT Asset Manager: 認定IT資産管理者) など、オンサイトでの集合教育、オンライン、クラスルーム形式の集合教育などを提供しています。
IMUG (ユーザーグループ)勉強会なども定期的に開催しています。
メンバーフォーラムのフォーラムでのディスカッションも良い教育の場と言えるでしょう。
IT資産管理プログラムとは、何を意味していますか?
IT資産管理プログラムとは、組織におけるIT資産管理の以下の項目を定義、網羅することを目的としています。
1.ミッション
2.全体戦略
3.目的
4.測定項目
5.優先順位
IT資産管理プログラムは、すべての活動が定義、実装、制御、監視され、中央管理されたプロセスです。
「全体戦略」と「目的」は、IT資産管理プログラムのミッションを支援するロードマップを定義します。
「測定項目」は、IT資産管理プログラムの有効性を検証するために必要なフィードバックを提供します。
IT資産管理者は、常に主要ビジネスドライバに基づき、IT資産管理プログラムに関係するプロジェクトやタスクの「優先順位」を管理しなければなりません。
IAITAMは、これら中央管理プロセスを 12 の主要プロセスエリア (KPA: Key Process Areas) と定義し、これら12主要プロセスエリアをIT資産管理プログラムとしています。
1.調達管理
2.資産識別
3.コンプライアンス管理
4.コミュニケーション管理
5.廃棄管理
6.文書管理
7.教育管理
8.財務管理
9.法務管理
10.ポリシー管理
11.プログラム・プロジェクト管理
12.ベンダー管理
IT資産管理の世界標準になっているベストプラクティスとはなんですか?
IT資産管理ではIAITAM が提供する IBPL (ITAM Best Practice Library)が世界で広く参照されています。
IT資産管理の国際標準ベストプラクティスとして世界で参照されている IBPL は12 の主プロセスエリア(KPA)を対象に12冊のベストプラクティス書籍として提供されています。
調達管理(Acquisition Management) |
財務管理(Financial Management) |
資産識別(Asset Identification)
|
法務管理(Legislation Management) |
コミュニケーション&教育(Communication and Education) |
ポリシー管理(Policy Management) |
コンプライアンス管理(Compliance Management) |
プログラム管理(Program Management) |
廃棄管理(Disposal Management) |
プロジェクト管理(Project Management) |
文書管理(Documentation Management) |
ベンダー管理(Vendor Management)
|
IBPL―IT資産管理ベストプラクティスは、業界標準や基準などに対応し、世界数百企業のプラクティスをベースに10年をかけて育成してきたナレッジの集大成です。
ISO19770、ITサービス管理のITILやSOXなどの国際規格やフレームワーク、法規などに対応し、最新の考慮、企業規模や成熟度により実践可能なベストプラクティスを、世界の組織で導入可能なわかりやすさを提供するのが IBPL ― IT資産管理ベストプラクティス ライブラリです。
ソフトウェア資産管理ができていない場合のリスクとはなんですか?
ソフトウェアライセンスの購入とは、すなわち「契約」です。
まずは、契約書の諸条件を管理していないと、購入時は利用規約に準じた運用が行われていても、環境の変化により運用状態が変化し、利用規約に準じた状態が損なわれて「契約違反」になる可能性があります。
大きな組織になればなるほど、購入者と、契約書の文言チェック、契約内容・諸条件の確認者、運用者が異なるので、契約条件に則った運用の担当や責任の所在が不明確、あるいは宙ぶらりんになります。
IT資産管理プログラムやソフトウェア資産管理プログラムの重要性は、これらの責任と役割を明確にすること、目標と現状を把握し、リスクを把握することにあります。
そしてさらに、法的リスクがあります。
法的リスクは、日本においては著作権法、知的財産法などによって保護されている著作権や知的財産権の侵害行為により、刑法や民法によって責任が問われる事態を指しています。ソフトウェアの違法利用の結果としての組織における法的リスクについて意外なほどに認識が低いのが現状です。
組織ぐるみで 著作権侵害(刑事罰および民事責任)
組織代表者:10年以下の懲役刑、または1,000万円以下の罰金刑(または併科)
法人格:3億円以下の罰金刑
民事的責任:損害賠償(民法709条)
株式会社:役員、株主代表訴訟(商法266条5項、267条)
従業員:10年以下の懲役刑、1,000万円以下の罰金刑(または併科)
従業員の著作権侵害行為を知りながら黙認した上司は「共犯」として刑事責任を問われる可能性あり。
ISO 19770-1 を順守しなければいけないのですか?
いいえ。
ISO 19770-1 は国際標準化機構(ISO)が国際規格として提供する参照規格です。
特に、順守しなければならないとか、全ての要求事項を充たさなければならない、ということではありません。
ISO 19770-1 は、ITサービスマネジメントの承認規格であるISO 20000 との緊密な連携をとり、とされていることから共通するプロセスや連携するプロセスが多数存在する、これらを理解するために参照する、ということが大切であって、ただ要求事項に対応すれば良いということではありません。
最も重要なことは、組織の目標、IT戦略に則ったIT資産管理、ソフトウェア資産管理を実施するために、ISO 19770-1 などを参照して、計画する、ということです。
ISO 19770 ってなんですか?
ISO 19770 は、ソフトウェア資産管理のプロセス標準ですが、ISO 9001 品質、ISO 27001 セキュリティ、ISO 20000 ITサービスマネジメント など 国際標準化機構(ISO)が規程する国際規格の一つです。
ただし、ISO 27001、ISO20000 などのような認証基準ではなく、あくまで参照なので、「ISO 19770 を認証を取得」というのはありません。
ソフトウェアメーカーなどが提供しているSAMプログラムなどの多くは、この ISO 19770-1 を参照して設計されているので、ISO 19770-1 を理解しておくのは良い事です。
ISO 19770-1 は英語なので邦訳を読むか、あるいは、日本語化された JIS X 0164-1 ( http://kikakurui.com/x0/X0164-1-2010-01.html ) を読んでおくと良いでしょう。
http://www.isms.jipdec.or.jp/sam/doc/JIP-SAM112-10.pdf
JSA Web Store http://www.webstore.jsa.or.jp/webstore/Com/FlowControl.jsp?bunsyoId=JIS+X+0164-1%3A2010&dantaiCd=JIS&status=1&pageNo=0&lang=jp
基本的にはアセスメント、評価などする場合に参考資料として利用可能な目標などが提供されていると考えてよいでしょう。
IT資産管理やソフトウェア資産管理は段階的に導入するべきプロセスであり、プログラムによりロードマップをもって計画し、段階的なプロジェクトにより推進していくべきものです、いっきにISO 19770-1 や JIS X 0164-1 に全面的に対応する、などという無謀な挑戦は避けましょう。
また、これらの規格を読むとわかりますが、ISO 20000、ITサービスマネジメントとの共通プロセスが多数存在し、冒頭に「ISO 20000との緊密な連携をとり」とあるように、「統合/連携」が前提となっていることに注目しましょう。
IT資産管理はツールだけでは実現できないのですか?
「IT資産管理は、ツールを導入すれば実現できる」という規模や目的の組織であれば、ツールの導入で実現は可能ですが、IT資産管理の目的によっては、ツールを導入する前に充分なポリシーの確認/再設計、IT資産管理プログラムの構築、プロセスの設計後にパターン化されたプロセスで自動化が可能なプロセスを識別し、自動化の要件定義を実施する。
つまり、自動化ツールの要件定義のためには、ツールの導入の前にプロセスの設計がされている必要がある、ということです。