前回の記事「4つのサービスの欠陥」から明らかなように、当社ではITSMアプローチを積極的に実装しています。 今日は、企業でのITSMの実装が通常どのように始まるのか、つまりサービスカタログについてお話したいと思います。
サービスの割り当ては簡単な作業ではなく、多くの困難に直面しました。
- ITサービス用のソフトウェアパッケージを入手できますか？
- サービスが複合であり、2つのソフトウェアシステムでサポートされている場合、責任者を特定するにはどうすればよいですか？
- ITインフラストラクチャ全体が崩壊し、ほとんどすべてのサービスが提供されていない場合に、インシデントを登録するサービスを決定する方法。
以下に、サービスを強調する際に遵守する原則を示します。
- すべてのサービスには、その品質（インシデント、可用性などのタイムリーな排除）に完全に責任を持つ単一の責任者が必要です。
- サービスの名前と説明は、エンドコンシューマー（内部クライアント）が理解できるようにする必要があり、同時にサービスは理解可能な値を提供する必要があります。
- 既存のサービスは、少なくとも1つのビジネスプロセスをサポートする必要があります。
これらの原則をさらに詳しく見て、それらがどのようにサービスを正しく割り当てるのに役立つかを理解しましょう。 はい！ これらは私たちの原則であり、すべての組織での適用可能性を主張するものではないことをすぐに警告したいと思います。 私は個人的に、これらの原則に準拠していないいくつかのサービスカタログを見ました。
すべてのサービスには、その品質に完全に責任を持つ単一の責任者が必要です。
論理的には、すべてが明らかなようです。 責任者が1人もいない場合、責任の喪失の問題と、インシデントを排除する際のピンポンの問題は、前の記事で書いたように、除外することはできません。
ただし、複合サービスの責任者を決定する方法。 たとえば、サービスU1があり、その本質は特定のデータセットへのインターフェイスを提供することです。 O1部門を開発しているソフトウェアP1があります。 P1ソフトウェアは、会社の全従業員に対してU1サービスの一部として提供されるデータのみを表示します。 P1ソフトウェアのすべてのデータは、O2部門によって開発されたP2ソフトウェアによって提供されます。
U1サービスの唯一の責任者は誰ですか？
私たちは、責任を決定するためのインターフェースの原則があると自分自身で決めました。
これはどういう意味ですか？
責任定義のインターフェース原則
サービスの責任者=内部クライアントがサービスを使用するアプリケーションの責任者。
なんで？ クライアントにとって、サービスの内部アーキテクチャは理解されるべきではないからです。 クライアントは、P1プログラムインターフェイスを使用してU1サービスを使用します。サービスに問題がある場合、P1プログラムを担当する従業員のイメージ（P1プログラムのイメージ）が影響を受けます。 ここで、P1プログラムのデータに関する問題の80％が、P2プログラムがデータのアンロードに問題があるという事実に関係していることは問題ではありません。
サービスの責任は、データの最終表示の責任者にあり、彼の仕事は、アプリケーションP2の責任者とのやり取りを確立して、サービスの知覚品質が損なわれないようにすることです。
サービスの名前は、最終消費者が理解できるものであり、クライアントが理解する価値を反映している必要があります
最初の部分では、すべてが明確になります。 一般に、クライアントが理解できる言語でクライアントと通信する必要があります。 特に、クライアントが理解できるようにサービスを呼び出します。
サービス名にデータ転送プロトコルの名前と同様の技術用語を使用する必要はありません。
たとえば、「XMPPメッセージング」サービスの代わりに、「インスタントメッセージングサービス」を使用することをお勧めします
物理的な練習に関するマニュアルを開いた後、2番目の段落で次を読みました。
「ベースに注入された穴はコレクターに向かって拡散するはずです」
それはよりシンプルである必要があり、それからより明確になるでしょう。
サービスの値は、サービスの名前からクライアントに明確でなければなりません。 たとえば、「現金取引の自動化」サービスには、クライアントが理解できる価値があります。 しかし、サービス「データネットワーク」はそうではありません。 一般の一般ユーザーにとって、このようなサービスの価値は明らかではありません。 なぜ彼はデータを転送する必要があります！？ 彼はどんな価値を手に入れますか？
ITILは価値の概念を非常に厳密に定義しています。
サービス「現金取引の自動化」は生産性を提供し、サービス「サイト上のアプリケーションの受け入れ」は制限を取り除きます（コンセントに物理的に存在する必要性）。 サービス「データ転送ネットワーク」は、平均的なユーザーには明確ではないため、ユーザーには何の価値もありません。 しかし、この価値を理解しているITプロフェッショナルにとっては価値があります。
この原則により、サービスカタログにあるべきではないもの、つまり内部サービス（たとえば、LAN、仮想サーバーなど）を入力することから保護されます。
最近、私はnalog.ruに行き、税控除を得るには、「3NDFL証明書を記入する」サービスを使用する必要があることを見ました。そのようなサービスは価値がありません。 第一に、3NDFLはアカウンティングで理解できない用語であり、第二に、サービスの価値が何であるかが完全に不明です。 しかし、「医療費の13％を返す」というサービスは価値があります。
既存のサービスは、少なくとも1つのビジネスプロセスをサポートする必要があります
繰り返しますが、すべてが論理的です。 サービスがビジネスプロセスをサポートしない場合、ビジネスはそれを必要としません。 そして、サービスのカタログでは彼女は属していません。
この原則により、最も一般的な場合のソフトウェアパッケージはITサービスと間違えられないという考えに至りました。 サービスが変更されないまま、ソフトウェアパッケージを別のソフトウェアパッケージに置き換えることができます。 たとえば、テレフォニーサービスは、コールセンターのビジネスプロセスをサポートします。 IPテレフォニーのハードウェアとソフトウェアの複合体を別のものと交換する場合、サービスは変更されません。 したがって、「Oktell IP Telephony」サービスはありません。
同じ原則は、同じソフトウェアで異なるITサービスを区別する必要がある場合の理解に役立ちます。
1つのアプリケーションの異なる論理モジュールが異なるビジネスプロセスをサポートする場合、サービスは異なるはずです。
たとえば、企業管理のさまざまな側面を実装するRM +アプリケーションがあります。有効性の計算と給与の計上、計画、サービスのリクエスト（サービスデスク）などです。
さまざまなRM +アプリケーションモジュールが、さまざまな企業のビジネスプロセスをサポートします。 したがって、サービスは異なります。
一方、さまざまな企業のビジネスプロセスもサポートする電子メールサービスがありますが、同時に、さまざまなビジネスプロセスをサポートする論理モジュールをサービスで選択することはできません。 すべてのビジネスプロセスに同じメール送信機能が必要です。
したがって、この場合、「メール」という1つのサービスがあります。
もう1つの第4の原則があります。これは、記事の冒頭で明示的に書いていません。
インフラストラクチャの一部が崩壊した場合、クライアントが現在使用できないサービスに対してインシデントを開始する必要があります。
これが何を意味するかの例を見てみましょう。
顧客がサービス1、サービス2、サービス3の3つのサービスを利用するとします。3つのサービスはすべて、内部サービス「データ転送ネットワーク」に直接依存しています（このサービスはユーザーのサービスカタログにありません）。
ルートスイッチに何かが起こったとしましょう。 内部サービス「データネットワーク」は提供されなくなりました。 その後、サービスカタログのサービスは提供されなくなります：サービス1、サービス2、サービス3。
エンドカスタマーは、Data Network Serviceについて何も知りません。 現在、サービスカタログの3つのサービスはすべて機能していません。 サービスデスクは、エンドカスタマーからのインシデントをどのサービスに開始する必要がありますか？また、インシデントを解決するためのSLA基準はどのサービスに適用する必要がありますか？
私たちの答え：現在クライアントが望んでいるが、顧客ができないものと、クライアントが何も知らない内部のものによると。 この場合、サービスの場合：「サービス3」および内部サービス「データ送信ネットワーク」。 クライアントの残りのサービスが機能しないが、それらを使用しようとさえしない場合、インシデントは無視できます。
この記事で共有したいのはこれだけです。 楽しんでいただけましたでしょうか。 よろしくお願いします！
いくつかの贈り物
Service Deskプラグインの20％割引。これは、社内のITSMアプローチに従ってサービスを提供するのに役立ち、他の多くの便利な機能も実装します。
割引は3週間有効です。
Redmineプラグインは世界中で使用されており、柔軟性と低コストで有名です。