ポストの最初の部分は理論的なものです-試運転の準備について、2番目の部分はシステムのセットアップについてです。
1.部門の現在の活動の分析
会社に関するいくつかの言葉：
主な方向は、建設、常駐スタッフ> 150人、> 5つのリモートサイトです。
部門について：
部門は6人を雇用しています。
- 1Cプログラマー-会社のニーズに役立つソフトウェアの実装に関する問題を解決します。
- 技術サポートスペシャリストは謙虚な使用人であり、メインエリアはユーザーサポートであり、セカンダリは部門のドキュメントの開発などです。
- ネットワーク管理者-会社のサーバー、電話などの管理。
- Web開発者-会社のWebサイトの責任者。
- インフラストラクチャスペシャリスト-会社の内部インフラストラクチャ。
- IT責任者
結論：
従業員の職務に精通した結果、システムをセットアップして使用するための4つの主要な方向が特定されました。
- サポート-これには、変更、インシデント、重大なインシデントのリクエストが含まれます。 このタイプのアプリケーションの期限は、サービスのカタログに従って設定されます（以下について）。
- メンテナンス-使用するシステム、リソース、機器の設定を変更します。 締め切りは、アプリケーションの決定を担当するスペシャリストによって設定されます。
- プロジェクト（別個のGLPIモジュール）-新しいプロジェクトで作業します。 プロジェクトを決定するための指定された基準：開始時刻と終了時刻があり、明確な目標（プロジェクトのマイルストーン）があり、参加者のグループがあり、目標があります。 期限はプロジェクトチームによって設定されます。
- 従業員に対する部門長のタスク。
また、マルチレベルのサポートを提供することも決定されました。 最初は単一レベルのサポートの問題が考慮されていましたが、この場合は呼び出しが重複していました。
2. GLPIシステムの内部セットアップの準備（理論、ドキュメント）
システムを運用する最初の段階は、システムの動作とシステムの動作の理論的な部分の説明です。 誘惑されることはありません。システムをセットアップする過程で多くのことがすでに文書化されています（このシステムにチュートリアルがないためです）。
サービスカタログ：
itilの最高の伝統では、会社のサービスのカタログを編集し、提供されるサービスを説明することが決定されました。 次に、問題の解決を担当するアプリケーションのメトリック、SLAを登録します。 サービスカタログの構造は次のとおりです。
- 「サービス」タブ-メール、1C、電話などのサービスの名前。
- 「サービス」タブ-サービスの一部として提供されるサービス。たとえば、アカウントの設定、アクセスの提供など。
- 「ユーザー」タブ-トップマネジメント、管理、オフィスなど、サービスを使用するユーザーグループの説明。
- 「可用性」タブ-サービスの可用性のレベルの説明。たとえば、24x7、5x40など。
- [影響]タブ-サービスの重要度レベルの説明、他のサービスへの影響、会社のビジネスプロセスへの影響。
- 責任タブ-サービスの提供を担当する専門家。
- タブ「メトリック」-測定可能なメトリックの説明。たとえば、コールへの応答時間、コールを解決する最大時間、特定の日付の許容コール数など。
アプリケーションの種類：
次は、アプリケーション/呼び出しをタイプに分離するプロセスでした：
- リクエスト-何かを変更するためのすべてのアプリケーション。たとえば、アクセス権の付与/変更、ソフトウェアのインストールなど、5x40モードでのそのような呼び出しの解決。
- インシデント-一度に1〜3人のサービスへのアクセスまたは操作の一時停止、5x40モードでのそのようなアピールの解決策。
- 重大なインシデントは、一度に4人以上がサービスを利用できないことです。このような呼び出しに対する解決策は、24時間365日のモードで発生します。
グループ：
部門のグループへの分割（スタッフ拡大のための準備金を含む）および責任者の任命：
作業の方向とglpiシステムとの相互作用が異なるマルチレベルのサポートモデルを使用することが決定されたため、いくつかのグループが割り当てられました。
- インフラストラクチャ-これには、ネットワークインフラストラクチャ、標準開発、ゲートウェイサポート、ネットワーク機器サポートが含まれます。 責任者-ネットワーク管理者。
- テレフォニー-PBXサービス、加入者管理、コールとのインターフェース-センター。 責任あるネットワーク管理者。
- ユーザーとユーザー機器-職場の設置とサポート、周辺機器の接続、機器の修理、消耗品の交換などがここに集められます。
- サーバーインフラストラクチャ-責任あるインフラストラクチャスペシャリスト。
- Webリソース-作成、サポート、およびメンテナンス。 責任あるWeb開発者。
- 企業情報システム。 開発とリリース、ユーザー権利の管理、請負業者との連携。 責任者-1C開発者。
- サードパーティITサービス。 モバイル通信、効率性、インターネット-これが自動ソース上にあるものです。
この分離により、責任のある分野を区別し、議題から質問-従業員が同僚によって管理されている理由を排除することが可能になりました。
SLA：
その後、SLA（控訴の期限）を解決する時が来ました。 以下に、SLAのインストールに特に影響を与えた要因を示します。
- 顧客の場所。 一部の問題では、サイト上の顧客への訪問がそれぞれ必要です。そのような通話の締め切りは、通常のSLAからの時間の20％の移動時間を考慮して定められました。
- 重要度/影響-会社のビジネスプロセスに顕著な影響を与えるアプリケーションのSLAは、可能な最小の決定期間を設定します（合理的な範囲内）。
- サービスの責任。 サービスが利用できないことを意味します-私たちまたはプロバイダー。 インターネットなどのプロバイダーがサービスを利用できない場合、SLAはサービス契約から取得されます。
これらの3つのインジケータは、SLAを上下に変更しました。 もちろん、各会社のSLAには独自のSLAがあります。ここでは、私の意見では、注意を払う価値のある役職について概説しました。
この理論的な部分に取り組んだ後、内部システム構成に進みました。 第二部でこれについて。