さまざまなリクエストが寄せられる情報システム部門…。
情シスが「社内の便利屋さん」になっていませんか？
何かしら問題があると、すぐに連絡してきませんか？
大量にくるリクエストをきちんと管理できないと対応漏れが出てきてしまったり、優先度をつけないと現場に多大な迷惑をかけることになってしまうかもしれません。
リクエスト管理を行うためには、情報をとりまとめないといけない中、メール・チャット・口頭依頼など、リクエスト方法が統一されていないだけで、情シスの対応が適切に行えなくなってしまいます。
1リクエスト（問い合わせ）を
ワークフローでDB化！
メール・チャット・口頭依頼など、窓口がいろいろあると、仕事の管理が難しくなります。
現場部門からのリクエストをワークフローによる申請で統一しませんか！
- 調査依頼申請
- 口頭依頼の禁止
ワークフローで管理することで、リクエストがユーザー部門から登録→DB化でき、情報管理のスタートを切ることができます。
これらの情報管理をするときに、課題となるのが「誰が情報を登録するのか」という点にありますが、
その役割が情シスではなくなるため、負荷を軽減しDB化することができます。
またDB化することで情シス内での情報共有、複数人での対応、未対応状況の把握など、
メールやチャットとは異なるメリットが生まれます。さらに口頭依頼を無くすことで、
リクエスト内容の取り違えや認識差異を減らすことが可能です。
資産管理と紐づくことで、適切な状況判断！
Assetment Neo for 情シスでは、資産管理を行っていることで、さらなる付加価値があります。
まず現場部門がリクエスト（問い合わせ）をあげる際、どの資産に関する依頼なのか、明確にすることで、認識差異を無くすことができます。次に申請された情報はDB化されることで、過去の該当資産の状況を把握することができます。
右図の当社例では、申請されたパソコンの修理履歴が２度あり、今回で３回目の故障であることが分かりました。このケースでは３度目の修理依頼は諦め、該当パソコンは廃棄することとしました。
さらにこの例では１回目の修理後、利用者が変わっていました。メールなどの依頼だった場合では人を軸にしているため、資産を軸にデータ管理していなければ修理履歴などがわからなかったかもしれません。
2ワークフローで情シスの
作業管理を実現！
現場部門のリクエスト（問い合わせ）が１台のパソコンの問題ではなく、ネットワークシステムの問題だった
場合、事象 → 原因 → 対応 の範囲、必要性、重要度が大きく変わってきます。
例えば上記例では原因がDHCPサーバーの設定となり、対応は “システム設定変更” が必要となるケースです。
このときにありがちなのが、情シス担当者がその設定を変更することで問題解決とし、完了してしまうことです。
しかし担当者のケアレスミスを抑制したい場合、
「本番環境のシステム変更は、必ず手順書を作成すること」
「本番環境のシステム変更は、情シス責任者の承認が必要」
などの運用ルールを定義したくなりませんか？
これを可能にするのがワークフロー機能となります。
資産管理と紐づくことで、変更管理やインシデント管理に発展！
作業管理として、ワークフロー上に作業手順書を添付・蓄積すると、資産を軸にみることで、システムの変更管理が実現されていることとなります。
変更管理の蓄積はインシデント管理にもつながります。
例えばDHCPサーバーの変更履歴は、何か問題があって行った設定変更と分かることで、仮に次のDHCPサーバーを新設する際、重要な情報となり、同じトラブルを繰り返さない対応が可能となります。
社内ヘルプデスクが、「サービスデスク」としての対応に！
資産管理＋ワークフローで作業管理・変更管理・インシデント管理にもなりえると、もはや社内ヘルプデスクというよりもITIL（ITサービスマネジメントのガイドライン）におけるサービスデスクといえます。
特に資産を軸にデータを蓄積できるのは、他にない特筆すべき機能となります。
サービスデスクだけでなく、資産管理とクラウド契約の管理も
Assetment Neoなら簡単に実現できます！
IT資産の台帳を適切に管理することで資産情報を軸に、社内ヘルプデスクや
クラウドライセンス契約など、情シスの業務はつながります