コンサル的思考実験と読書メモブログ

ITコンサルタントが身を持って学んだこと、フレームワークの使い方、書評などを挙げていきます。IT企業や企業内IT部門の管理者やリーダ層の方、ITコンサルタントを目指す方に参考になる情報発信できればと思います。

ITIL 活用〜要求実現で取り組むべき申請統合〜

久しぶりにITIL についてです。

 

本当はブログのタイトルになってるくらいなのでもっと書いていきたいところですが、興味あることばかり書いてしまってるので、のんびりお付き合いいただければ幸いです。

 

要求実現とは、サービス要求(ユーザーからの作業の依頼などユーザーからの作業を伴うリクエストの対応)を管理するプロセスです。

 

一昔前はインシデント管理の一要素として管理されていましたが、サービスの計画外の中止などで定義されるインシデントとは主旨が異なることから分けて管理する事が推奨されています。

 

サービス要求の例としてはパスワードのロック解除やPCのキッティング依頼など、業務としては申請を受け付けて対応する業務が挙がります。

 

これらをITIL に準拠させて標準化したり効率化していく際に多く取るのが、バラバラに行われていた申請をツールに載せていく事に合わせて整理するというアプローチがあります。

 

 申請業務をツールに載せる上で一番やってはいけない事は、現状の業務をそのまま載せようとする事です。

 

特に組織が大きく利害関係者が多い企業ほど、整理をしてから移行する事が求められます。それは以下の理由からです。

 

・大企業だと軽く100を超える申請があったりします。それをそのままツールに載せるのはコストがかかりすぎる。

→そもそも同じ意味合いでも申請が分かれていたり、項目もバラついている

 

・ユーザー視点で申請が統合されずシステム別の提供者視点の申請となっている。

→ユーザーは異動やなんらかの事業上の要件によって申請を出してきます。それらのユースケースではなく、申請対象ごとに申請が設けられたりするので1つのイベントで複数申請を出さなくてはいけないと言った手間が発生します。ひどい時には申請先がそれぞれ異なって状況説明を都度必要となります。

 

どんなツールでも、無制限にバラついた申請をそのまま載せるには、仕様上の制約やメンテナンス工数が膨大となり、現実的ではなくなります。

 

申請自体の統廃合や申請項目などの統廃合を行う事で、移行に伴うコストの削減や、ユーザーの手間も削減する事ができます。

 

まずは、整理するという大方針の元に進めるようにしてください。 

 

より細かい統廃合のポイントや移行の方法についてはまた後日お話できればと思います。