記事では、OTRSの使用を含む、ITILプラクティスの実装の機能を明らかにしようとします。
ユーザーはそもそもIT部門に何を望んでいますか？
次のように、ユーザーの言葉（これは非常に良いユーザーである必要があります）でITILに目を向けて答えようとします。 サービスの提供に障害がある場合、彼はどこを向くべきかを知らなければならず、サービスはできるだけ早く復元する必要があります。 さらに、ユーザーはソフトウェアのインストールなどの特定のITサービスを受け取りたいと考えています。したがって、すぐに実装できる基本プロセスは次のとおりです。
インシデント管理
フルフィルメントのリクエスト
インシデントの例：PCの電源が入らない、アプリケーションの起動中にエラーが発生したなど。
サービスのリクエストの例：ソフトウェアのインストール、企業リソースへの権利の付与など。
コメント内のholivarを防ぐために、ソフトウェアのインストールは変更またはサービスリクエストのいずれかであり、権限の付与はアクセス管理によって規制されます。 それはすべて、IT部門が直面するタスクと、その部門が提供するサービスの説明に依存します。
ITILの用語
インシデントは、ITサービスの計画外の中断またはITサービスの品質の低下です。
インシデント管理プロセスの目標：ユーザーのITサービスの迅速な回復。
OTRSについて少し
Habrにはこのシステムへの言及がありましたが、それについて少し思い出させてください。
Wikiによると、これはオープンなアプリケーション処理システムですが、その機能はアプリケーション処理だけにとどまりません。
このシステムは、公式Webサイトwww.otrs.comからダウンロードでき、インストールおよび構成のマニュアルもあります。
OTRSを構成する
チケットの種類を決定します。 より正確には、システムにはすでに定義済みの設定セットがあるため、上記のプロセスを実装するために必要なものは残します。
必要に応じて、ハードウェア、印刷、ソフトウェアなどのキューを定義できます。 各キューには、エージェントアクセスを設定する機能があります。 エージェントは、インシデントを解決するために働く従業員であり、通常はServiceDeskの従業員です。
キューの場合、カレンダーを定義する必要があります。 作業スケジュールに従って特定のキューを担当するエージェントの空き時間。
カレンダーの設定はモジュールで行われます：
コア::時間::カレンダー1
最大10個のこのようなカレンダーを割り当てることができ、それぞれの曜日、年次および1回限りの休日と週末にエージェントの作業時間を指定できます。 SLAに従う時間は、エージェントの可用性を考慮に入れます。
サービス（サービスカタログ）とSLAサービスレベル契約を定義します。
少なくとも1つのSLAで十分であり、最初の反応の時間と溶液の時間を決定します。
アプリケーションは、Webインターフェース、電話、IT部門のエージェントのインターフェースを介して受信されます。
OTRSにはリクエストを処理するためのユーザーインターフェースがあるという事実にもかかわらず、joomla上で実行される内部サイトを介して相互作用を実装しました。 プラグインを使用すると、アプリケーションを作成し、以前に作成された「自分の」リクエストを表示できます。
OTRSゲートウェイ
受信したアプリケーションは、新しい状態を受け取ります。 エージェントのインターフェースでは、最初の反応まで、そして解決までの時間が利用可能です。
アプリケーションでの作業の開始の事実は、テンプレートに基づいて作成された回答によって修正されます
その後、アプリケーションはブロックされ、オープン状態を受け取ります。 同時に、検討のためにアプリケーションが送信されたというメッセージがユーザーに送信されます。 最初の反応がリセットされる前の時間カウンター。
要求は、必要に応じて、ユーザーが誤って修正したデータを入力してください。
決定後、アプリケーションを保留中の自動クローズ+状態に移行します。
タイムアウトは、パラメーターによって設定されます。
$ Self-> {'Ticket :: Frontend :: PendingDiffTime'} = '14400'
ユーザーがリクエストへの追加を受信しなかった場合、リクエストはクローズ成功状態に移行します。 はい、完全に正直ではないかもしれませんが、一方で、ユーザーに追加でWEB-Interfaceにアクセスし、完了したリクエストにコメントを書くように要求することはありません。
$ Self-> {Ticket :: StateAfterPending} = {
「保留中の自動クローズ+」=>「クローズ成功」、
「保留中の自動クローズ」=>「クローズに失敗しました」
cron Unixスケジューラーは状態遷移を担当します。状態遷移では、ステータス更新頻度をデフォルト値の2時間未満に設定する必要があります。
120分ごとに保留中のジョブを確認します
45 * / 2 * * * $ HOME / bin / PendingJobs.pl >> / dev / null
パラメータを変更します。この例では、時間を5分に設定します。 同時に、システムのパフォーマンスも記憶しています。
5分ごとに保留中のジョブを確認します
* / 5 * * * * $ HOME / bin / PendingJobs.pl >> / dev / null
エージェントインターフェイスでリクエストを簡単に表示するには、パラメータを設定します。
コア::チケット:: ViewableStateType、
新規およびオープン状態のみを残し、それにより、エージェントインターフェイスで待機状態を非表示にします。
課題
ユーザーを疲れさせないように、説明ダイアログを膨らませることなく、リクエストの説明をユーザーの肩に部分的にシフトします。 必須フィールドのサービスとタイプを指定します。 誤って記述された要求は、ServiceDeskによって修正されます。
すべてのユーザーリクエストを記録することが不可欠です;サービスデスクの従業員のモチベーションによってこの問題を解決します。
報告
レポートは、レポートウィザードを使用して、次のような標準機能を使用して生成されます。
アーティストごとの平均応答時間
サービスの平均応答時間
アーティストによる平均決定時間
平均サービス決定時間
実行者によるレポート期間（月）のリクエスト数
サービスのレポート期間（月）のリクエスト数
リクエストの総数に対するSLAに従って行われたリクエストの割合。
サービスの運用に関与する専門家を評価（動機付け）するためには、実行者に関する報告が必要です。
サービスに関するレポートは、関係者に提供されます。
さらに、データベースへのSQLクエリによって取得されたレポートが使用され、それらはITサービスの主な指標です。
SLAに基づいて完了したリクエストの割合。 （私たちの場合は80％で、90％を目指して努力しています）
次は何ですか
次に、問題管理、サービスカタログ管理、変更管理、構成管理などを検討します。
ITIL全体、特にOTRSに移行することは可能です。