この記事はServiceNowアドベントカレンダー2024 の12月9日分の記事として執筆しています。
はじめに
こんにちは、@ynakano26です。
ご覧いただきありがとうございます。
本記事では、私が所属する会社でご提供するPCのライフサイクル管理サービスに、ServiceNowのITOM機能を組み合わせてお客様にサービス提供を行った過去の案件対応から得た、PCのライフサイクル管理業務における課題感やポイントを簡単にまとめます。
PCを中心としたIT資産のライフサイクル管理は多くの企業様にとって悩みの種だと思いますので、現在取り組まれている方にも、検討中の方にもちょっとした参考となれば幸いです。
なお、本記事が自身初となる記事投稿のため、稚拙な文章となっている点はご容赦ください。
また企業情報に該当しうる内容は割愛しておりますので、その点もご了承ください。
筆者について
・ServiceNow関係の業務経験：約２年（Tokyoバージョンより）
所属会社について
・2017年にServiceNowを導入（Istanbulバージョン？）
・ITOのサービス基盤としてServiceNowを運用
PC-LCMサービスについて
■ サービス概要
弊社がお客様向けにご提供しているPC-LCMサービスとは、PCを中心としたクライアント端末の調達から廃棄までに至るライフサイクルを、一気通貫で管理・運用するサービスです。
お客様は日々の発注業務やエンドユーザー様からのお問い合わせ対応などの、煩雑な業務に割く工数を削減し、コア業務に集中いただけるといったメリットがあります。
本サービスの運用基盤として、ServiceNowを採用しています。
ServiceNowはドメインセパレーションの機能によってお客様毎に独立して存在し、各ドメインにお客様の資産情報を格納しております。
またワークフローの機能を用いて、お客様からの申請やお問い合わせに基づき、キッティングセンターや保守部隊とスムーズに連携をしてお客様にサービスをご提供しております。
■ サービス基盤について
前述の通り、弊社のサービス基盤であるServiceNowでは、ドメインセパレーション機能を採用しております。
ドメインセパレーション機能については、以下のドキュメントをご参照ください。
ドメインセパレーション機能を用いることで、一つのインスタンス上でありながら、セキュリティを担保されたお客様独自の環境をお使いいただくことが可能です。
また、PC-LCMサービス以外にも、リモート監視やヘルプデスク等のサービス基盤としてもご利用いただいております。
PC-LCMサービスとITOM機能の適用事例
ここから、本記事の主題である、PC-LCMサービスにITOMを適用した実例のご紹介をいたします。
今回ご紹介する案件では、従来のサービス基盤としてのServiceNowの機能を用いつつ、Service Graph Connectorsの機能を採用し、クラウドインベントリ収集ツールであるTaniumとServiceNowの連携を試みました。
Service Graph Connectorsについては、以下の公式サイトよりご参照ください。
なお標準のDiscovery機能ではなくTaniumとの連携を行った理由は、既にお客様がServiceNowよりも先にTaniumを導入しており、Taniumとの連携を要件とされたという背景があります。
■ ライフサイクル管理業務の流れ
上図における、全体のライフサイクル管理業務の流れと、ServiceNowの関わり方は以下の通りです。
【調達フェーズ】
① エンドユーザーからの新規発注の申請をもとに、運用担当者にてServiceNowにデータを登録
② ServiceNowでワークフローが動き、キッティングセンターと情報を連携してキッティングを開始
③ キッティングセンターからエンドユーザーへPCが配送され、PCを利用開始
④ エンドユーザがPCを起動したタイミングで、②のキッティング作業時にインストールされたTaniumが起動。PCの情報がTanium側のデータベースへ送信される
⑤ 日次のバッチ処理で、TaniumからServiceNowへリアルタイムにPC情報が連携（ITOM適用によるインベントリ収集の自動化）
【回収フェーズ】
① エンドユーザーからの回収依頼をもとに、運用担当者にてServiceNowにデータを登録
② ServiceNowでワークフローが動き、回収業者と情報を連携して回収作業を開始
③ エンドユーザーからPCを回収し、リース会社へ返却（または廃棄や保管）を行う
④ PCの利用停止に伴い、TaniumからServiceNowへの連携もストップ
実例から見えてきたシステム開発と運用上の課題
■ キー値の定義について
TaniumとServiceNowを連携する際にはキー値を定義する必要があります。
PCの場合はシリアル番号をキー値とするケースが多いですが、実際にシステム連携を行うと、Taniumからシリアル番号が空のデータが送られてきたり、ServiceNow上でシリアル番号が重複して不適切なデータ更新が発生するといった事象がありました。
このように、運用上で致命的なデータ不整合が発生しうることに注意して、仕様の設計を考慮する必要があります。
■ 手動運用とシステム連携を組み合わせることのギャップ
今回の事例では、Taniumとの連携によってインベントリ収集の自動化を実現できましたが、一方で運用担当者によるデータ取込や更新といった手動の運用が存在していました。
手動運用による入力ミスや、Tanium連携とのタイミング的なズレといった様々な理由により、重複したPCレコードが作成されてしまう、意図せぬデータ更新が行われてしまうといったトラブルが発生しました。
■ イレギュラーケースの運用
要件定義の際に網羅しきれなかった特殊な端末の調達や管理方法など、イレギュラーケースが実装段階になって判明するということがあります。
そのようなイレギュラーケースに合わせてServiceNowの設計を変更していくと、工数が肥大化したり、メンテナンスが煩雑になってしまうリスクがあります。
まとめ
実例を通じて筆者が感じたポイントを、最後に３点まとめたいと思います。
① PCのライフサイクル管理業務におけるITOM適用の有益性
他社のインベントリ収集ツールと連携すること自体のハードルは決して高くなく、リアルタイムにPCのデータがServiceNowに連携されてくることは、データ管理の品質向上に有益であると実感しました。
② データクレンジングにかかる負担
ITOM適用によりPCデータの収集を自動化しても、前述の通りシステム間の連携におけるエラーや、手動運用とのギャップが発生し、データクレンジングには相当の工数がかかることを痛感しました。
③ ServiceNowを現行の運用ルールに寄せすぎない
各企業様それぞれにイレギュラーな運用ケースが存在することを前提として、現行の運用ルールに合わせてServiceNowの設計開発を行うのではなく、時には現行ルールをServiceNowの仕様に寄せていくことの考慮も必要だと改めて実感しました。
以上短い内容ですが、この記事がどなたかの参考になれば幸いです。
最後まで記事を読んでいただき、ありがとうございました！