そのため、このスキームを変更することをお勧めします。 つまり、ITILライブラリからのいくつかの推奨事項。 それらは私たちの職業のすべての避けられない否定性が解決するフィルターになります。 まだ興味があるなら、猫へようこそ。
本サービス操作（インシデント管理、問題管理）からの2つのプロセスと本サービス移行（変更管理、構成管理）からの2つのプロセスを検討します。 つまり、インシデント、問題、変更、構成管理を実装することを提案します。
例として、1人の管理者が勤務する会社を取り上げます。 彼は、内部ITインフラストラクチャとそのユーザーをサポートする上司と一定の作業量を持っています。
インシデント管理
インシデントは毎日発生します。 プリンター、コンピューターが故障すると、何も失敗します。 あなたはバグを修正することで正直に働きます。 故障と修理の流れは記憶の中に混在しており、四半期の終わりに完了した作業について質問されると、一般的な用語でのみ報告できます。 もちろん、そのような答えはリーダーシップに適切な印象を与えません。つまり、昇給もアシスタントへの新しい仕事の割り当てもありません。 客観的なレポートを作成するには、インシデント管理システムのいずれかを実装するだけです。 有料、無料、自分で開発したもの、またはスプレッドシートエディタで大量のメールから組み立てたもの-関係ありません。 主なことは、彼女であることです。
各リクエストについて個人的に実行する必要はありません。多くの場合、「既に修復されています」という精神でユーザーから何かを聞いています。 人々にメールまたはWebインターフェイスを介してリクエストを送信させます。最悪の場合、電話でリクエストを受け入れます。
ただし、合理的です。ユーザーとの関係を損なうことは有益ではないため、これを上級管理者側の革新として提示してください。 彼らもあなたに同情します。 トップマネジメントの場合、最初にIT部門への申請手順の短い注文に署名し、アプリケーションの記録を保持します。 これは注文用であることを経営陣に説明します。 リーダーは秩序が大好きです。
インシデントのデータベースを維持することで、勤務時間を計画したり、「見て、私のコンピューターはそこで動作しません」という後援の下での一定の散歩をなくすことができます。 上司は、いつでも、行われた作業、費やされたリソース、愚かなユーザーリクエストに関する明確でわかりやすいレポートをいつでも受け取ることができます。 ユーザーは、個人的に煩わされることなく、オンラインでアプリケーションのステータスを表示できます。
このシステムは、あなたの人格と、便利な「稲妻」を求めて人間社会で必然的に循環するあらゆるネガティブとの間の隔離層になります。 彼女には性格がありません。 システムに尋ねるのは愚かで、scるのは無意味です。 彼女と議論することは何もありません。 安全面では、アクセス制御システムとビデオ監視システムは、メインに加えて、警備員から人間の攻撃を排除する重要な機能も備えています。 後発者は、彼を日記に書き留めたことで管理人に腹を立てていますが、カードの改札口に腹を立てることはありません。 請求書を印刷する必要があることを伝えるのではなく、自分自身と壊れたプリンターのユーザーに対して同じことを行い、リクエストのステータスを見て、次の部門で請求書を印刷します。
問題管理
インシデント管理を実装した後、次の論理的なステップは問題管理を実装することです。 毎月故障する非常に有害なプリンターがあり、絶えず時間をかけて修理作業を調整し、会社のお金を浪費しているとします。 インシデントデータベースを既にセットアップしているので、このプリンターに直接関連するものを選択してから、問題を作成できます。すべてのデータが一緒に接続されます。 上司に、彼の修理にはすでに新しい費用の半分の費用がかかっており、将来的にはそれを超えることも見せます。 新しいプリンターを購入することの妥当性は、IT業界から最も遠い頭にとっても明らかです。
問題は再発するだけでなく、一般的にインフラストラクチャに重大な影響を与えるすべてのインシデントです。 たとえば、メールサーバーでのコントローラーRAIDの故障により、ビジネス通信が一時的に中断される場合は、問題のステータスが必要です。 つまり、このようなベースを維持することで、インフラストラクチャの変更を使用する必要があるソリューションのインシデントおよびインシデントのグループを識別することができます。
理想的には、ワークフローを整理するという観点から、問題の解決に努めるべきです。 すべてのインシデントはアシスタントに転送する必要があります。アシスタントは、前四半期の明確で詳細なレポートのおかげで、なんとかしてくれました。
変更および構成管理
次のステップは、変更管理を実装することです。 重要な機器の交換、サーバー設定のすべての変更を文書化する必要があります。 少量の生産、またはIT部門の十分な人員配置で、構成管理ベースにマウスの交換を追加して、どのユーザー、いつ、何を注文したかを追跡することもできます。
これらすべてのプロセスが機能するベースは、CMDB（構成管理データベース）と呼ばれます。 これは構成管理の一部です。 利用可能なすべてのハードウェア、ソフトウェアソリューション、および会社の従業員を格納し、それぞれにインベントリ番号が割り当てられます。 データベース内のこのような各エントリは、構成ユニットと呼ばれます。 それがインシデントであるか問題であるかに関係なく、すべての要求は、このデータベースからの構成ユニットとの接続を自身内に持つ必要があります。
変更管理の実装時にすでにアシスタントがいる場合は、部門に変更要求システム（RFC）を導入することを強くお勧めします。 機器の構成を変更する場合、またはアシスタントが機器を交換する場合は、正式な許可が必要です。 それなしでは、この非常に助手は、どんな変更に対しても懲戒処分を受けます-または、もっと簡単に言えば、たとえ彼がデータベースに情報を入力したとしても。
繰り返しますが、この経済全体を実装するための最も予算的なオプションは、メール、スプレッドシートエディタ、およびHTMLを介して実装できます。
この記事では、一般的なイデオロギーを可能な限り単純に説明しようとしましたが、詳細や詳細には触れません。 興味のある方は、各プロセスを詳しく調べたり、ITILライブラリの他のプロセスや推奨事項を、私たちの生活の現実に合わせて説明したりできます。