会社の業務を知るためのITSMを軸とした典型例

未分類

ServiceNowを理解するため近道は、「どんな業務を、どのように動かすのか」を具体的にイメージすることです。ここでは、多くの企業に共通する「社内IT部門」を舞台にして、ServiceNowが実際にどのように使われるのかを見ていきましょう。

ここでは、ServiceNow を活用した ITSM の実践例を中心に、ITサービス運用業務にフォーカスします。

舞台設定と登場人物

まずは、この物語の舞台となる架空の会社と、IT部門で働く登場人物（役割）をご紹介します。

舞台設定

  • 組織名: 山田ITソリューションズ
  • 本社所在地: 東京・丸の内
  • 拠点: 国内5拠点（東京本社＋4事業所）
  • IT部門の提供サービス: 社員の業務に必要なITインフラや業務アプリケーションの運用・保守
  • 問い合わせ窓口（チャネル）: 電話、メールのほか、専用のポータルサイトやAIチャットボット（Virtual Agent）も活用

主な登場人物（役割）と担当業務

IT部門の中では、各メンバーが専門的な役割を担い、連携して業務を進めています。

  • ITサービスデスク:社員からの「PCが動かない」「パスワードを忘れた」といった問い合わせの最初の窓口（一次対応）です。ServiceNowのインシデント管理やリクエスト管理を主に使います。
  • ソリューションエンジニア:サービスデスクで解決できない、より専門的な技術調査が必要な問題を担当する二次対応の専門家です。障害の根本原因を調査し、再発防止策を考えます。問題管理やナレッジ管理が主な活躍の場です。
  • 変更管理マネージャ:システムの仕様変更やサーバーの入れ替えなど、本番環境への変更作業を計画し、安全に実行するための責任者です。関係者を集めた会議（CAB）を調整し、変更のリスクを管理します。変更管理アプリケーションを駆使します。
  • 構成管理担当:社内にあるPCやサーバー、ソフトウェアライセンスといったIT資産の情報を、一元的に管理する台帳（CMDB）に正確に登録・更新します。構成管理データベース（CMDB）や資産管理が担当領域です。
  • サービスオーナー:ITサービス全体の責任者。サービスの品質が維持・向上しているかをKPI（重要業績評価指標）で監視し、改善計画を立てます。サービスポートフォリオ管理やパフォーマンス分析といった機能で、IT部門全体のパフォーマンスを可視化します。

IT部門の主な仕事 ― ITSMの5大業務カテゴリ

山田ITソリューションズのIT部門では、日々さまざまな業務に取り組んでいますが、その中心となるのが次の5つの業務です。

業務カテゴリ目的・内容代表的なKPI（目標指標）
インシデント管理障害や問い合わせを、とにかく迅速に復旧させ、業務への影響を最小限に抑えること。平均修復時間（MTTR）、初回解決率
サービスリクエスト管理PCの利用申請や備品の貸与など、あらかじめ決められた定型の依頼を効率よく、できれば自動で処理すること。リクエスト処理時間
問題管理同じインシデントが再発しないよう、その場しのぎの対応ではなく、根本的な原因を突き止め、恒久的な対策を立てること。再発インシデント数
変更管理システムへの変更作業を、安全かつ計画的に、ビジネスへの影響なく迅速に実施すること。変更成功率、緊急変更率
構成／資産管理社内のIT資産（PC、サーバー、ライセンス等）の情報を正確に維持し、無駄なコストやセキュリティリスクをなくすこと。構成情報（CI）の精度、棚卸完了率

シナリオで見る業務の流れ（インシデントから変更まで）

では、これらの業務が実際にはどのようにつながっているのでしょうか。ある一つの障害発生から解決までの流れを、シナリオ形式で追いかけてみましょう。

graph TD
    subgraph "ユーザー"
        A[ポータルで「業務アプリが使えない」と申告]
    end

    subgraph "ServiceNowプラットフォーム"
        B(インシデント管理<br>チケットが自動起票) --> C{一次対応で解決できず}
        C --> D(問題管理<br>二次対応へエスカレーション)
        D -->|根本原因を特定| E(変更管理<br>恒久対策の変更要求を作成)
        E -->|CABで承認| F[リリース & 構成更新<br>パッチを適用し、CMDBを更新]
    end
    
    A --> B
    F -->|解決を通知し自動クローズ| B
  1. ある日、営業部のAさんが、顧客管理アプリが使えないことに気づき、ServiceNowのポータルサイトから障害を申告します。
  2. 申告内容に基づき、インシデント管理のチケットが自動で作成され、ITサービスデスクに通知が飛びます。
  3. ITサービスデスクが基本的な対応を試みますが、解決できません。チケットは二次対応のソリューションエンジニアに引き継がれます。
  4. 調査の結果、特定のソフトウェアのバグが根本原因であることが判明。エンジニアは問題管理のプロセスにのっとり、恒久的な対策としてパッチを適用する必要があると結論付けます。
  5. 対策を実施するため、変更管理のプロセスへ移行。エンジニアが変更要求を作成し、変更管理マネージャが招集するCAB（変更諮問委員会）で承認を得ます。
  6. 承認後、計画通りにパッチが本番環境に適用（リリース）され、同時に構成管理データベース（CMDB）の情報も自動で更新されます。
  7. システムが復旧したことがAさんに通知され、インシデントチケットは自動的にクローズされます。

自動化の舞台裏

この一連の流れの裏側で、ServiceNowの自動化機能が活躍しています。ユーザーからの申告内容に応じたチケットの担当者割り振り、二次対応へのエスカレーション通知、CABの予定登録、リリース後の構成情報更新までを、Flow Designerという機能が人の手を介さずに連携させます。これにより、対応のスピードアップと人為的ミスの削減を両立できるのです。

まとめ

この章で見てきたように、ServiceNowのITSMプラットフォームは、インシデント、問題、変更、構成といった、バラバラになりがちなIT運用業務を、単一のデータモデル、つまり「同じ言葉・同じルール」でつなぎ合わせます。

一つの場所に入力されたデータは、次のプロセス、またその次のプロセスで再利用され、「入力は一度、データは再利用」という理想的な状態を実現します。

コメント

タイトルとURLをコピーしました