チケット管理やサービス管理の製品と連携します。既にこれらを運用している組織で、NinjaOneの情報を活かすための設定です。
連携する理由
既にPSAやITSMを運用している場合、NinjaOne Ticketingへの全面移行は現実的ではありません。運用が定着しており、他の業務とも結びついているためです。
連携すると、次のことができます。
| できること | 効果 |
|---|---|
| NinjaOneの検知からチケットを起票する | 監視と対応が1つの流れになる |
| デバイス情報を参照する | チケット対応中に状態を確認できる |
| 資産情報を同期する | 台帳の二重管理を避ける |
| 対応時間を連携する | 請求や工数管理に反映する |
対応する製品
主要なPSA製品とITSM製品に対応しています。対応の範囲は製品によって異なるため、公式ドキュメントで確認してください。
導入前に確認すべき点は次の通りです。
- 自社が使っている製品が対応しているか
- どの情報が同期されるか
- 同期の方向は一方向か双方向か
- 同期の頻度はどのくらいか
3番目が設計に影響します。双方向同期では、どちらの変更が優先されるかを理解しておく必要があります。
連携の設定手順
一般的な流れは次の通りです。
- 連携先の製品で、接続用の認証情報を発行する
- NinjaOneで連携を追加し、認証情報を登録する
- 同期する情報の対応関係を設定する
- テスト用のデータで動作を確認する
- 本番の運用に切り替える
3番目が最も手間のかかる作業です。NinjaOneのOrganizationと連携先の顧客、デバイスと資産、といった対応関係を定義します。
【注意】 対応関係の設定を誤ると、間違った顧客にチケットが起票されます。MSPでは特に注意が必要です。本番切り替え前に、少数のOrganizationで動作を確認してください。
同期される情報
製品によって異なりますが、一般的には次の情報が対象になります。
| 情報 | 同期の方向 |
|---|---|
| Organization / 顧客 | NinjaOneから、または連携先から |
| デバイス / 資産 | NinjaOneから連携先へ |
| チケット | 双方向の場合が多い |
| 対応時間 | NinjaOneから連携先へ |
デバイス情報はNinjaOneが正になることが多くなります。Agentが自動収集するため、手入力より正確で最新だからです。
重複を防ぐ設計
連携で起こりやすい問題が、チケットの重複です。
| 状況 | 対策 |
|---|---|
| 同じ事象で両方に起票される | 起票元を一方に統一する |
| 同じデバイスが二重登録される | 対応関係の設定を見直す |
| 通知が両方から届く | 通知の経路を一方に絞る |
起票の経路を整理してください。監視からの自動起票はNinjaOne、利用者からの依頼は連携先、といった切り分けが実務的です。
連携の停止と解除
連携を止める場合、次の点を確認してください。
- 停止後、どちらに情報が残るか
- 進行中のチケットはどう扱われるか
- 同期していたデータは削除されるか
- 連携用のコンポーネントを削除する必要があるか
いきなり削除せず、まず無効化して影響を確認してから解除することを推奨します。
【運用のポイント】 連携の設定内容は文書に残してください。対応関係の定義は複雑になりがちで、設定した本人以外には理解しにくくなります。記録の残し方はApps & Servicesの登録と活用を参照してください。