ITSMソリューションのアナリスト実装者であれば、各クライアントプロジェクトで膨大な情報のもつれを解く必要があることを正確に知っています。プロセスを理解し、要件を収集し、数十のドキュメントに記入して同意します...これらの段階のいずれでも、データトラップに陥りがちです。反復的なアプローチと...経験を節約します。
クライアントのサービスカタログのITシステムの設計段階では、タスクが少なくありません。この記事では、サービスカタログを作成するためのさまざまなアプローチをどのように試したか、複数ページのドキュメントとテーブルを放棄した理由、およびプロセスが現在どのように編成されているかについて説明します。
サービスカタログを作成するためのアプローチの進化
クライアントプロジェクトでは、サービスカタログをコンパイルするためのさまざまなアプローチを試みました。
Wordのテーブル。数年前、彼らは滝の開発モデルを使用して、細心の注意を払って情報をテキストファイルに収集しました。これらの文書には、サービスの名前、主な責任者から特定のサービスおよびSLAの活動の種類まで、すべてが記録されていました。
テキストドキュメント形式の「Eメール」サービスの表形式の説明の例
このような「インベントリ」の手順は簡単ではなく、部分的に役に立たないものです。サービスを1つずつめくって最後のサービスにたどり着くと、最初のサービスはすでに関連性を失います。請負業者が変更され、条件が調整され、一連の可能性が修正されました。すべての作業を新たに行うことができます。
サービスの監査が終了するまでに、完成したテーブルは数十に達する可能性があります
情報はその場で更新されるだけでなく、パラメータのセット自体もテーブルが更新されるたびに膨らみます。結局のところ、SLAとサービスの責任を知るだけでは十分ではありません。すべての受信者を名前で覚えておくと、サービスが提供するインフラストラクチャリソースと、サービスが依存しているリソースを確認することをお勧めします。
同時に、どの企業のプロセスも静的ではありません。新しいサービスが登場し、既存のサービスが開発されます。サービスは、クエリ、リファレンスブック、リンク、パラメータ、KEなどのオブジェクトの巨大な層で大きくなりすぎています。
ドキュメントの開発がどれほど長く続いても、見られる終わりと端はありません。この文書は合意するのが難しく、その適合性には疑問があります。これは、完了できず、一時停止することしかできない改修のようなものです。同様に、過去のプロジェクトでは、複数ページの「スクロール」での作業は通常、「十分です！システムに入る時が来ました。」
Excelテーブル。複数ページのドキュメントの代わりに、他のテーブルが私たちの実践に突入しました。クライアントの説明部分はテキストのままにしておきました。そして、サービスとそのパラメータのリストを含むテーブルが添付されました。繰り返しますが、必要な情報を1つのドキュメントに追加することは不可能でした。実際、サービスカタログは相互接続されたテーブルのネットワークに成長しました。
Excelで多くのタブと列を手動で維持するのは不便です。実装アナリストはこの作業に数百時間を費やしました
。自動化システムへの主要なインポートの基礎として、サービスのリストをコンパイルするこの方法を検討しました。さらなる開発と最適化は、ITシステムですでに実行される予定でした。しかし、このアプローチにも欠点がないわけではありません。
私たちのプロジェクトの経験が示すように、静的ドキュメントの形式でカタログを準備することは、経済的に正当化される作業ではありません。人件費は莫大で、排気はゼロです。文書に署名して行為を閉じることを除いて、それはもはや必要ではありません。便利な自動化ツールが導入された場合、誰もこれらのフットクロステーブルを修正しません。
もう1つは、動的カタログです。これは、最初は独自の構造と価値で設計されています。自動化ツールで。このようなディレクトリは、最初のサービスが表示されたときにのみ機能し始めます。実装段階でターンキーサービスカタログを作成することは不可能です。この期間中に、それを埋めて更新するプロセスを開始することが可能です。つまり、最善のアプローチは、最小限の情報を収集してITシステムに直接アクセスすることです。
サービスカタログの価値は何ですか
プロセスのすべての参加者は、適切に設計されたサービスカタログの利点を実感できます。
サービスの受信者は、数回クリックするだけですばやくアピールを作成でき、どこで何を選択するかについて混乱することはありません。便利なサービスのグループ化を備えたセルフサービスポータル
インターフェイス。 Naumen SMPプラットフォームに実装されています。
サービスプロセスの実践者は、カタログ自体を必要としません。指定された構造は、アプリケーションの分類プロセスとその後の処理を簡素化するのに役立ちます。期限、実装手順、影響を受けるサービス、調整とエスカレーションの利害関係者が明らかになります。
プロセスマネージャー提供されるサービスのポートフォリオに関するデータのスライスは、管理上の決定に必要です。要求の量の監査、合意に達するための情報、およびプロセス手順の遵守。
所有者と顧客は、品質と財務のパラメーターに関心があります。
ITシステムでサービスカタログを作成するのに役立つ手順
反復的なアプローチを使用し、手順を進めて明確なサービスカタログを作成することをお勧めします。
ステップ1.目標の定義
活動の主な質問は「なぜ？」です。私たち自身のために、サービスカタログの目標は次のように策定されました。
- サービス受信者との生産的な相互作用を整理します。
- ITSMプロセスを構築し、会社のすべての部門でサービスアプローチを適用するために、単一のプラットフォームを使用します。
- すべてのビジネスプロセスの管理と開発の基盤を築きます。
ステップ2.調査の実施
クライアントはよくこう言います。「当社のサービスカタログは準備ができています。しかし、気まぐれなアプローチで彼を倒さないように、私たちは彼を見せません。適切なカタログを最初から提供してください。」
今日、「ゼロから」は、ストーンエイジに戻ったり、自転車を再発明しようとしたりするようなものです。開発をあきらめるべきではありません。私たちは持っているものすべてをITシステムに詰め込みます。
社内のサービスカタログが正式化されていない場合は、次のアーティファクトを分析します。
- リクエストのログ。
- （使用する場合）アプリケーションの分類子とリファレンスブック。
- 情報システムおよび機器のリスト。
- 組織構造;
- 外部サプライヤーとのサービス契約。
さらに、アルゴリズムは次のとおりです。
- サービスプロバイダーによく寄せられる質問に焦点を当てます。
- ユーザーが理解できる言語で一連のサービスを形成します。
- 管理対象リソースへの呼び出しをグループ化して「グラウンド」します。
- ユーザーがリクエストを送信したときにITシステムに表示されるサービスの名前を提供します。
相関の例：ユーザーのアドレス-ITシステムの機器-サービス
最初に、カタログはサービス「その他」/「自由形式のアプリケーション」を提供する必要があります。舞台裏では「ガベージチャンネル」と呼ばれています。このような呼び出しを定期的に分析することで、次のことを判断できます。
- 言葉の悪いサービス名。たとえば、特定のサービスがカタログに存在しますが、ユーザーはそれを見つけられず、ユニバーサルサービスを選択します。
- スタッフのトレーニングの必要性。たとえば、特定の部門のユーザーは体系的にサービス「その他」を示しますが、ほとんどの部門は正しい分類子を選択します。
- サービス部門の発展における傾向とニーズ。たとえば、サービス組織によって提供されていないサービスに対する繰り返しの要求が大量にあります。
ステップ3.責任の分配
スターターサービスセットの準備ができたら、パフォーマーをインストールして修正する必要があります。
責任のレベルを定義することが重要です。
- リクエストの実行者。
- サービスマネージャ。
- ディレクトリマネージャー。
請負業者を見つけるのは簡単です。これを行うために、コールログの統計に基づいて、ジョブの説明を機能的な職務および能力と比較します。サービスが機能しない場合やサービスの品質が消費者に合わない場合は、まず
サービスマネージャーがお客様のご来店となります。おそらく、これは実行者の長または組織構造部門の上位の従業員です。ディレクトリ全体の責任者を
選択することは、より難しい作業です。実践が示すように、より頻繁にそのようなマネージャーが任命されます：
- ソフトウェア実装プロジェクトマネージャー。全体像を把握し、一元管理の決定を下すことができます。
- (-). , , .
- . , : , , , .
4.
カタログの初期バージョンが組み立てられると、より深く作業を開始できます。
ここで、私たちはすぐに私たちの開発を共有します：実際に最も需要があったパラメータとそれらが必要な理由。
サービスパラメータの既製のリスト。フルバージョンをダウンロード
ITシステムでサービスのカタログが作成された結果、高品質の分類子が作成され、更新および管理されます。
ステップ5.カタログの開発
サービスカタログの開発における重要な段階は、リソースサービスモデル（PCM）との接続を設定することです。それを設計および維持することは、無限の労力を要する可能性があります。しかし、それからはるかに多くの利点があります。
この接続の値を簡単な例で示します。社内ではインターネットが機能していません。インシデントは登録されています。問題の原因が（サポート機器に関連して）何であるか、およびこのノードに依存するどのサービスがさらに低下するかをすばやく見つけるのに役立つのはPCMです。
最後のコードは、サービス間の相互依存関係を描き、CUのリストを追加し、構成管理プロセスをITシステムに導入することです。そして、大切なのは、この繊細に集められたものがすべてこぼれないように、プロセスに従って生きることです！
KE分類子として同時に機能するサービスカタログの一部の例
サービスのカタログが作成され、KEがロードされ、接続が登録されると、それはアカウンティングシステムと統合されたままになります。サービスのコスト、それらのサポートのコストを計算します。しかし、それは別の話です…