ServiceNowにおける資産-CI関係の習得：決定版実装ガイド

エグゼクティブサマリー

本レポートは、ServiceNowにおける財務的資産（alm_asset）と運用的構成アイテム（CI）（cmdb_ci）間の標準的な紐付けメカニズムに関する、包括的なアーキテクチャ分析と実践的な実装ガイドを提供する。この統合の核心は、単なる技術的なリンクではなく、IT資産管理（ITAM）とITサービスマネジメント（ITSM）の規律を戦略的に融合させることにある。中心的な論点は、製品モデル（cmdb_model）とそれに関連するモデルカテゴリ（cmdb_model_category）の綿密な構成が、ITライフサイクル全体の統一的で正確、かつ自動化されたビューを達成するための基礎的な前提条件であるということである。本レポートでは、自動化エンジンを分解し、段階的な実装手順を提供し、強化された変更管理から完全なライフサイクル可視性に至るまで、正しく実装された資産-CI関係がもたらす深遠な戦略的利益を探求する。

I. 基礎概念：資産、CI、モデルの共生関係

このセクションでは、データモデルの背後にある概念的な「なぜ」を確立し、各コア要素の明確でありながら補完的な役割を明らかにする。資産とCIは同じ根底にあるエンティティに対する2つの異なる視点を表しており、製品モデルはそのエンティティを記述するための共通言語を提供するということを理解することが重要である。

資産の定義：財務・契約レコード（alm_asset）

資産の核心的な目的は、アイテムの財務的および契約的な側面を表現することである。その主な機能は、ビジネスの観点から価値、所有権、ライフサイクルを追跡することである 。これは、「何を購入したか？」「費用はいくらか？」「誰が所有しているか？」「保証はいつ切れるか？」といった問いに答える。  

資産のライフサイクルはCIのライフサイクルよりも広範である。それは要求または調達の瞬間から始まり、最終的な廃棄で終わる。CIが運用可能になる前や運用停止になった後にも存在する可能性のある「在庫中」「廃棄待ち」「廃棄済み」といった段階を含む 。これは、基本的な実装では見落とされがちな重要な区別である。  

alm_assetテーブルとその拡張は、発注書（PO）番号、ベンダー、コスト、減価償却、保証期限、契約詳細、廃棄情報などの財務データに焦点を当てている 。これらの属性はIT資産管理（ITAM）アプリケーションスイート内で管理される 。例えば、物理サーバー、ソフトウェアライセンスエンタイトルメント、携帯電話などが資産にあたる。直接的なコストがかからない仮想サーバーは、CIではあるが必ずしも資産ではない典型的な例である.  

構成アイテム（CI）の定義：運用的・関係性レコード（cmdb_ci）

CIの核心的な目的は、アイテムの運用的および技術的な側面を表現することである。その主な機能は、技術的な属性、ステータス、および他のCIとの関係を追跡することによって、サービス提供をサポートすることである 。これは、「IPアドレスは何か？」「どのOSが稼働しているか？」「他にどのサービスが依存しているか？」「誰がサポートしているか？」といった問いに答える。  

CIのライフサイクルは、その運用状態に結びついている。アイテムがインストールまたはプロビジョニングされ、IT環境の一部となったときに始まり、サービスから運用停止されたときに終わる。そのステータスは、「インストール済み」「メンテナンス中」「廃棄済み」など、運用上の準備状況を反映する 。  

cmdb_ciテーブルとその多くの拡張は、OSのバージョン、メモリ、CPU数、シリアル番号、場所、および構成管理データベース（CMDB）に保存されている他のCI（アプリケーション、データベース、ネットワーク機器）との関係といった技術仕様に焦点を当てている 。例えば、データセンターで稼働しているサーバー、特定のソフトウェアインストール、ネットワークスイッチ、ビジネスサービスなどがCIにあたる。  

ギャップを埋める：定義の単一ソースとしての製品モデル（cmdb_model）の役割

製品モデルは、組織が調達、使用、または販売する製品の特定のバージョンまたは構成のマスター定義またはテンプレートである 。これは、資産レコードとCIレコードの両方が参照する中心的なオブジェクトであり、財務レコードと運用レコードが全く同じもの（例：「Dell Latitude 7420, 16GB RAM, 512GB SSD」）を記述していることを保証する。  

共通の製品モデルを使用することで、組織はデータ標準を強制する。「Dell 7420」や「Latitude Laptop」のような自由テキスト入力の代わりに、そのタイプのすべての資産とCIは、単一の権威あるモデルレコードを指す。これは、正確なレポート作成と管理の基本である 。  

製品モデルレコード自体が直接資産とCIのリンクを作成するわけではない。代わりに、自動化の真のトリガーであるモデルカテゴリへの参照を保持している。モデルは「それが何か」を定義し、カテゴリは「それがどのように管理されるべきか」（つまり、資産として、CIとして、またはその両方として）を定義する 。これは微妙だが非常に重要なアーキテクチャ上の詳細である。  

資産とCIのライフサイクルが完全に一致しないという事実は、調達から展開までの現実世界のプロセスを反映した、意図的なコア設計原則である 。組織はサーバーを購入した瞬間からそれを資産として所有するが、それがラックに設置され、電源が入り、構成されて初めてITインフラの機能的な一部（CI）となる。この区別を認識することは、資産の受領、在庫室管理、および展開のための効果的なワークフローを設計する上で鍵となる。このため、システムは資産のみが存在する一時的な状態（例：在庫室にあるサーバー）に対応できるように設計されており、自動化（セクションIIで詳述）は、ライフサイクルの適切な時点（例：資産の状態が「在庫中」から「使用中」に変わったとき）でCIの作成をトリガーするように構成されなければならない。  

また、製品モデル（cmdb_model）は、ITAMとCMDBの両方にとって最も重要なデータガバナンスのポイントである。厳密に管理された製品モデルのセットがなければ、資産テーブルとCIテーブルの両方に一貫性のない低品質のデータが入力され、レポートの信頼性がなくなり、自動化が不可能になる。製品カタログのキュレーションに費やされた労力は、プラットフォーム全体で利益をもたらす。

表1：資産 vs. CI – 比較分析

ドメイン	資産 (alm_asset)	CI (cmdb_ci)
主な目的	財務・契約情報の追跡	運用的・技術情報の管理
準拠する規律	IT資産管理 (ITAM)	ITサービスマネジメント (ITSM)/CMDB
中心的な問い	「その価値は何か？」	「それはどのように機能するか？」
典型的な属性	コスト、保証、発注書	IPアドレス、OS、関係性
ライフサイクル範囲	調達から廃棄まで	展開から運用停止まで
主要テーブル	alm_asset	cmdb_ci

Google スプレッドシートにエクスポート

II. アーキテクチャの詳細解説：同期のメカニズム

このセクションでは、資産とCIのリンクを自動化し、統制する技術的なコンポーネントを分解する。このアーキテクチャを理解することは、トラブルシューティング、カスタマイズ、そして標準提供ソリューションの洗練性を理解するために不可欠である。

要となるモデルカテゴリ（cmdb_model_category）

モデルカテゴリレコードは、自動化の真の心臓部である。その主な目的は、CIクラス（cmdb_ci_*）を資産クラス（alm_*）に関連付けることである 。これはプラットフォームに対する一連の指示として機能する。  

CIクラスと資産クラスの両方が定義されたモデルカテゴリに製品モデルが割り当てられると、対応するレコードの自動作成が有効になる。例えば、「コンピュータ」カテゴリに属するモデルの資産を作成し、そのカテゴリがalm_hardwareをcmdb_ci_computerにリンクしている場合、システムは自動的に対応するcmdb_ci_computerレコードを生成する 。これが中核となるメカニズムである。モデルカテゴリのフォームには、「資産クラス」と「CIクラス」という2つの重要なフィールドが含まれている。片方が空欄の場合、その方向への自動作成は無効になる。作成後にCIクラスを変更することはできないという事実は、その基礎的な性質を強調している 。  

自動化エンジン：主要なビジネスルールとスクリプトインクルード

サーバーサイドのロジックはここに存在する。プラットフォームは、コードを実行するタイミングを定義するビジネスルールと、再利用可能なコード自体を含むスクリプトインクルードの組み合わせを使用する。

レコード作成用：

• スクリプトインクルード AssetandCI: このスクリプトインクルードには、資産とCIの作成を管理するための主要な関数が含まれている。このプロセスの中心的なライブラリである 。  
• ビジネスルール:
  • alm_assetテーブル上：Create CI on insertが最も重要なルールである。新しい資産が作成されると、このルールが発動し、AssetandCIスクリプトインクルードを呼び出し、対応するCIレコードを生成する。ただし、これはモデルカテゴリがそのように構成されている場合に限る 。  
  • cmdb_ciテーブル上：Create Asset on insertは逆の操作を実行する。これは、CIが最初にディスカバリツールによって作成された場合によく見られる。システムはその後、「シェル」となる資産レコードを作成する 。  

継続的な同期用：

• スクリプトインクルード AssetAndCISynchronizer: このスクリプトインクルードは、リンクされた資産レコードとCIレコード間の継続的な更新を管理する 。  
• ビジネスルール:
  • alm_assetテーブル上：Update CI fields on changeは、資産レコード上の同期対象フィールドへの変更を検出し、それをCIにプッシュする 。  
  • cmdb_ciテーブル上：Update Asset fields on changeは逆の操作を行い、CIから資産への変更をプッシュする 。  

このシステムは、「プロアクティブな」資産作成を意図して設計されている。資産を最初に（調達時にプロアクティブに）作成し、そこからCIを生成させることで、最初から正しいデータの系譜が確立される 。これにより、後からディスカバリツールが重複したCIや「望ましくないモデルレコード」を作成するのを防ぐことができる。これは、新しいデバイスの信頼できる情報源を、予測不可能なディスカバリデータから、管理された調達プロセスへと移行させる。ディスカバリツールがデバイスのBIOSから読み取るモデル文字列は、公式の製品カタログにあるものとわずかに異なる場合がある。もしCIがディスカバリによって最初に作成されると、システムは新しい、望ましくない製品モデルを作成してしまう可能性がある。しかし、資産が最初に正しい、承認された製品モデルで作成され、そこからCIが生成された場合、ディスカバリが実行されると、シリアル番号に基づいて既存のCIと一致させ、モデルの不一致を無視して技術属性のみを更新する。これにより、製品カタログの整合性が保たれる。  

データブリッジ：資産-CIフィールドマッピングテーブル（alm_asset_ci_field_mapping）

この専用テーブルは、資産とそのCIの間でどのフィールドが同期されるかを正確に定義する。スクリプトにフィールド名をハードコーディングすることなく、同期を管理するための柔軟で拡張可能な方法を提供する 。このテーブルの各レコードは、alm_assetテーブルの1つのフィールドをcmdb_ciテーブルの対応するフィールドにマッピングする（例：asset.serial_number -> ci.serial_number）。AssetAndCISynchronizerスクリプトは、何を更新すべきかを知るためにこのテーブルを読み取る。管理者は、ビジネスニーズに合わせてこのテーブルのマッピングを追加、削除、または変更できる 。  

このアーキテクチャは、「何を同期するか」（データテーブル）と「どのように同期するか」（スクリプト）を意図的に分離している。alm_asset_ci_field_mappingテーブルとAssetAndCISynchronizerスクリプトの分離は、堅牢なソフトウェア設計の典型例である 。これにより、管理者はコードに触れることなく同期の範囲を変更できる。これはカスタマイズへの障壁を下げ、システムの保守性とアップグレードの安全性を高める。マッピングがスクリプトにハードコーディングされている場合、変更には開発者によるスクリプトの修正が必要となり、プラットフォームのアップグレード時にスキップされる可能性のある公式のカスタマイズ（sys_update_xmlレコード）が作成され、カスタマイズが壊れる可能性がある。マッピングをデータテーブルに配置することで、変更はコードではなくデータとして扱われ、はるかに回復力と柔軟性のあるアプローチとなる。  

また、資産のStateとCIのStatusの間のマッピングは、単純な1対1ではなく、「最も論理的な対応物」にマッピングされる 。例えば、資産の状態が在庫あり - 廃棄待ちの場合、対応するCIのステータスは処分中となる。これは、システムが財務・物流ライフサイクル（資産の状態）と運用ライフサイクル（CIのステータス）の間を翻訳するための複雑なロジックを含んでいることを意味する。管理者は、カスタムの状態やステータスを作成する前に、これらの標準のマッピングを理解する必要がある。カスタム値は、AssetAndCISynchronizerスクリプトインクルードの基盤となるロジックを修正しない限り、正しく同期されない可能性があるため、注意が必要である。  

表2：資産-CI同期のための主要な自動化コンポーネント

コンポーネントタイプ	コンポーネント名	プライマリテーブル	主な責務
スクリプトインクルード	AssetandCI	Global	対応する資産またはCIの初期作成のための関数を含む。
ビジネスルール	Create CI on insert	alm_asset	資産の挿入時にトリガーされ、AssetandCIを呼び出してリンクされたCIを作成する。
スクリプトインクルード	AssetAndCISynchronizer	Global	リンクされたレコード間のフィールドの継続的な更新/同期のための関数を含む。
ビジネスルール	Update CI fields on change	alm_asset	資産の更新時にトリガーされ、AssetAndCISynchronizerを呼び出してリンクされたCIに変更をプッシュする。

Google スプレッドシートにエクスポート

III. 実装ガイド：ステップバイステップの手順

このセクションでは、セクションIIのアーキテクチャ理論を、プラットフォーム管理者のための実践的で順を追ったガイドに変換する。

フェーズ1：実装前構成 – モデルカテゴリの検証

目的： データを作成する前に、自動化のための基本的なルールが正しく定義されていることを確認する。 手順：

1. 製品カタログ > 製品モデル > モデルカテゴリに移動する。
2. 既存の標準提供カテゴリを確認する（標準で127個存在する ）。  
3. 対象のカテゴリ（例：「ハードウェア」）のレコードを開く。
4. 重要ステップ： 資産クラスフィールドが正しい資産テーブル（例：ハードウェア [alm_hardware]）を指し、CIクラスフィールドが対応するCIテーブル（例：ハードウェア [cmdb_ci_hardware]またはより具体的なコンピュータ [cmdb_ci_computer]）を指していることを確認する。このマッピングが自動化のマスターイッチである 。  
5. 適切なカテゴリが存在しない場合にのみ新しいモデルカテゴリを作成する。CIクラスは作成後に変更できないことに注意する 。  

フェーズ2：製品モデル（cmdb_model）の作成

目的： 管理したいアイテムの標準化されたテンプレートを作成する。 手順：

1. 製品カタログ > 製品モデル > すべてのモデルに移動する。
2. 「新規」をクリックしてモデルフォームを開く。
3. モデルのタイプ（例：ハードウェア、ソフトウェア、消耗品）を選択する 。  
4. 主要な詳細を入力する：モデル名（例：「HPE ProLiant DL380 Gen10」）、製造元、製品ID。命名規則に従い、正確に入力する。
5. 重要ステップ： モデルカテゴリフィールドで、フェーズ1で検証したカテゴリ（例：「サーバー」）を選択する。これにより、モデルが自動化ルールにリンクされる 。モデル定義自体が、選択されたカテゴリの構成に基づいて、資産、CI、またはその両方を作成するかどうかを決定する 。  
6. 製品モデルレコードを保存する。

フェーズ3：手動での資産作成と自動的なCI生成

目的： プロセスを実行し、リンクされたCIの自動作成を観察する。 手順：

1. 資産 > ポートフォリオ > すべての資産に移動する。
2. 「新規」をクリックする。
3. 重要ステップ： モデルフィールドで、フェーズ2で作成した製品モデル（「HPE ProLiant DL380 Gen10」）を選択する。
4. モデルカテゴリはモデルから自動的に入力される。
5. 資産タグやシリアル番号など、他の必要な資産詳細を入力する。
6. 状態を「在庫中」または他の適切な初期状態に設定する。
7. 資産レコードを保存する。
8. 観察： 保存すると、Create CI on insertビジネスルールが実行される。フォームが再読み込みされ、資産レコードの構成アイテムフィールドに、新しく作成されたCIへの参照が入力される 。  

このプロセスのユーザーエクスペリエンスは一見シンプルに見える。ユーザーはフォームに入力して保存するだけである。しかし、その背後では、複数のデータベーステーブル、ビジネスルール、スクリプトインクルードが関与する複雑な一連のイベントがトリガーされている。成功する実装には、管理者がこの隠れた複雑さを理解することが不可欠である。なぜなら、UIはプロセスが失敗したときにほとんど手がかりを提供しないからである。最も一般的な失敗点であるモデルカテゴリの設定ミスは、エラーメッセージなしに構成アイテムフィールドが空のままになるという結果を招くだけである。したがって、この実装ガイドでは、コアプロセス自体がエンドユーザーにとって「ブラックボックス」であるため、事前構成ステップ（フェーズ1）と検証ステップ（フェーズ4）の重要性を強調する必要がある。

フェーズ4：リンクと同期の検証

目的： 2つのレコードが正しくリンクされ、データがそれらの間で流れることを確認する。 手順：

1. 資産レコードから、構成アイテムフィールドの横にある参照アイコンをクリックし、新しいCIレコードを開く。
2. CIのモデルIDフィールドが正しい製品モデルを指していることを確認する。
3. CIの資産フィールドが作成した資産レコードを指していることを確認する。これにより、双方向のリンクが確認できる 。  
4. CIレコード上で、シリアル番号などの同期対象フィールドを変更し、レコードを保存する。
5. 資産レコードに戻り、フォームを更新する。資産のシリアル番号がUpdate Asset fields on changeビジネスルールによって自動的に更新されたことを確認する。これにより、同期が機能していることが確認できる 。  

フェーズ5：高度な同期のためのフィールドマッピングのカスタマイズ

目的： デフォルトの同期を拡張し、カスタムフィールドやその他のビジネス上必要な属性を含める。 手順（に準拠）：  

1. 資産 > 管理 > 資産 - CI フィールドマッピングに移動する。
2. 「新規」をクリックする。
3. 資産フィールドリストから、alm_assetテーブルのソースフィールドを選択する。
4. 構成アイテムフィールドリストから、cmdb_ciテーブルのターゲットフィールドを選択する。
5. （オプション）資産マッピング条件ビルダーを使用して条件を追加する。例えば、モデルカテゴリが「コンピュータ」の場合にのみこのマッピングを同期させるなど。
6. 新しいマッピングレコードを送信する。AssetAndCISynchronizerは、この新しいマッピングをロジックに含めるようになる。

表3：デフォルトの同期フィールド（標準提供）

資産フィールド (alm_asset)	CIフィールド (cmdb_ci)
asset_tag	asset_tag
serial_number	serial_number
location	location
comments	comments
cost_center	cost_center
assigned_to	assigned_to
managed_by	managed_by
company	company

Google スプレッドシートにエクスポート

IV. 戦略的意味合いとベストプラクティス

この最終セクションでは、正しく実装された資産-CI関係から得られるビジネス価値と長期的な利益を探求し、それを技術的な構成からビジネスの戦略的イネーブラーへと変える。

財務的コンテキストによるITSMプロセスの強化

• 変更管理： これは最も強力なユースケースである。CI（例：「サーバーXYZのRAMをアップグレード」）に対して変更要求が提出されると、資産へのリンクにより、重要なビジネスコンテキストに即座にアクセスできる。そのサーバーは保証期間内か？リース終了が近いか？これを知ることは、変更を承認、却下、または修正する決定に影響を与える可能性がある。ハードウェア資産管理（HAM）との統合は、CIの変更に必要な資産アクションを決定するのに役立ち、これを直接サポートする 。  
• インシデント／問題管理： CIに対してインシデントが発生した場合、リンクされた資産レコードはサポートチームに契約情報、SLA詳細、ベンダーのサポート連絡先を提供し、解決を迅速化できる 。問題管理では、特定の資産モデルに結びついた繰り返されるインシデントの財務コストを理解することで、交換のためのビジネスケースを構築できる。  
• 完全なコスト可視性： CI（運用アイテム）を資産（財務アイテム）にリンクすることで、組織はビジネスサービスの真の総所有コスト（TCO）を計算し始めることができる。インシデント、変更、ソフトウェアライセンスからのコストは、CMDBの依存関係マップを通じて集計され、サービスをサポートする資産に関連付けることができる 。  

この資産-CIリンクは、CMDBを受動的なインベントリから能動的な意思決定支援システムへと変革する。従来のCMDBは技術コンポーネントのマップである。しかし、各コンポーネントがリンクされた資産からのリアルタイムの財務および契約データで強化されると、それは戦略的な意思決定のためのツールとなる。CIOは「このサービスへの変更に伴うビジネスリスクは何か？」と問い、技術的な依存関係だけでなく、保証状況、サポート契約の価値、資産の年齢を含む答えを得ることができる。この統合はデータの重複ではなく、データの強化に関するものである。CIの運用コンテキストは資産の財務コンテキストによって強化され、その逆もまた然りである。この相乗効果は、CMDBと資産データベースの価値を、それぞれが単独で提供できるものをはるかに超えて高める。

完全なライフサイクル可視性の達成

この統合は、財務計画と調達（資産）から、運用展開、保守、監視（CI）、そして最終的な廃棄と処分（資産）まで、アイテムのシームレスで包括的なビューを提供する 。これにより、財務・調達チームとIT運用チームの間の従来のサイロが打破される。単一のリンクされたレコードは、データの乖離や不一致を防ぐ。リンクがなければ、IT運用チームはサーバーの場所を「データセンターA」としているかもしれないが、財務チームのスプレッドシートでは「ビル7」となっているかもしれない。自動同期により、共有データポイントに対する単一の信頼できる情報源が保証される 。  

データガバナンスとベストプラクティス

• 製品カタログの統制： 製品モデルカタログは基盤である。モデルの作成と変更のための厳格なガバナンスプロセスを導入する。重複した、または不十分に定義されたモデルの作成を避ける。
• プロアクティブな作成の採用： 調達・受領フェーズで最初に資産を作成し、システムにCIを生成させるというベストプラクティスに従う。これにより、データの整合性が保証され、ディスカバリツールが不正なレコードを作成する問題が防止される 。  
• 過剰な同期を避ける： 考えられるすべてのフィールドを同期させようとする誘惑に抵抗する。構成タイプのフィールドを資産テーブルに、または資産タイプのフィールドをCIテーブルに作成しないことが推奨される 。真に共有され、片側で権威のあるデータのみを同期する。他のデータについては、フォームやレポートでドットウォーキングを使用して関連情報を表示し、データの冗長性を生じさせないようにする。  
• 例外の計画： すべての資産がCIを必要とするわけではない（例：キーボードのような消耗品、ソフトウェアエンタイトルメント）。すべてのCIが資産を必要とするわけではない（例：仮想サーバー）。それぞれの資産またはCIクラスフィールドを空のままにすることで、これらの例外を正しく処理するようにモデルカテゴリを構成する。

成熟した資産-CIの実装は、全社的な自動化とリスク管理を効果的に行うための前提条件である。その利点は、コアITSMをはるかに超えて広がる。セキュリティ運用は、リンクされたデータを使用して、資産コストやビジネスの重要性に基づいて脆弱性の修正を優先順位付けできる。財務は、より正確な監査を実施できる。人事部は、「標準的なラップトップバンドル」（製品モデル）を要求することで、従業員のオンボーディング／オフボーディングを合理化し、必要な資産レコードとCIレコードを自動的にプロビジョニングできる 。このリンクを正しく実装しないと、セキュリティ運用、GRC、さらには完全で正確なIT環境の全体像に依存するカスタムアプリケーションなど、他のモジュールの有効性を妨げる波及効果が生じる。これを正しく行うための初期の努力は、プラットフォーム全体の将来の能力への投資である。  

結論

ServiceNowにおける資産と構成アイテム（CI）の連携は、単なる技術的な機能ではなく、ITとビジネスの間のギャップを埋める戦略的必須事項である。本レポートで詳述したように、この関係の核心は、財務的・契約的なライフサイクル（資産）と運用的・技術的なライフサイクル（CI）を、共通の定義ソースである製品モデルを通じて統合することにある。

成功裏の実装は、モデルカテゴリの綿密な構成に依存しており、これが資産とCIの自動作成と継続的な同期を推進するエンジンとして機能する。Create CI on insertのようなビジネスルールを活用し、調達プロセス主導でプロアクティブにレコードを作成するアプローチは、CMDBと資産データベースの両方でデータの整合性を確保し、ディスカバリツールによるデータの汚染を防ぐためのベストプラクティスである。

最終的に、正しく構成された資産-CI関係は、プラットフォーム全体の価値を飛躍的に高める。それは、変更管理における意思決定を強化し、インシデント解決を迅速化し、サービスの総所有コストに対する前例のない可視性を提供する。この統合されたデータ基盤は、ITSMの領域を超え、セキュリティ運用、財務監査、人事プロセスをサポートし、ServiceNowを真のエンタープライズサービス管理プラットフォームへと昇華させる。したがって、この連携の習得は、データ駆動型の意思決定を可能にし、IT運用をビジネスの財務的現実に整合させることを目指す、あらゆる組織にとって不可欠な取り組みである。レポートに使用されているソースreddit.comWhat is the difference between an asset object and configuration item object in Servicenow?新しいウィンドウで開くreddit.comServicenowの資産オブジェクトと構成アイテムオブジェクトの違いは何？ – Reddit新しいウィンドウで開くcyntexa.comWhat is ServiceNow ITAM? Everything You Need to Know新しいウィンドウで開くservicenow.comWhat is IT Asset Management (ITAM)? – ServiceNow新しいウィンドウで開くvirima.comServiceNow IT asset management: Features, benefits, and alternative – Virima新しいウィンドウで開くservicenow.comAsset and CI management – ServiceNow新しいウィンドウで開くservicenow.com資産と構成アイテムの管理 – ServiceNow新しいウィンドウで開くservicenow.comConfiguration Management Database (CMDB) – ServiceNow新しいウィンドウで開くservicenow.comモデル – ServiceNow新しいウィンドウで開くservicenow.com製品モデルの作成 – ServiceNow新しいウィンドウで開くservicenow.comモデル – ServiceNow新しいウィンドウで開くservicenow.comWhat is the use and relationship between alm_asset… – ServiceNow …新しいウィンドウで開くservicenow.comModel categories – ServiceNow新しいウィンドウで開くservicenow.comAssets, Configuration Items, and Model Categories:… – ServiceNow …新しいウィンドウで開くnoderegister.service-now.comEnable Create CI on Asset Insert Business Rule – Product Knowledge新しいウィンドウで開くservicenow.com資産と CI の操作 – ServiceNow新しいウィンドウで開くservicenow.com資産と CI の操作 – ServiceNow新しいウィンドウで開くservicenow.com資産フィールドと CI フィールドをマッピングする – ServiceNow新しいウィンドウで開くyoutube.comConfiguration Items (CIs) in ServiceNow – YouTube新しいウィンドウで開くservicenow.comChange Management integration with Hardware Asset Management – ServiceNow新しいウィンドウで開くaelumconsulting.comThe Definitive Guide to ServiceNow ITAM for Asset Managers – Aelum Consulting新しいウィンドウで開くaelumconsulting.comBest Practices to Implement ServiceNow ITAM at Scale – Aelum Consulting新しいウィンドウで開く参照されたもののレポートには使用されていないソース