サービスデスクを導入する際の業務範囲の判断基準と質の向上について

近年、基幹システムが成熟を迎えＩＴ部門は、専ら維持管理、保守業務が主な活動になっています。<経営層からは、ビジネスに貢献できていないといった嘆きの声も聞かれます。もっとＩＴ部門がビジネスに貢献できるような企画に携わっていくことが今後のＩＴ部門の課題ではないでしょうか。

そのためには、維持管理や保守業務を省力化し新しいことにチャレンジできる時間を創出していく必要があります。業務を省力化していくための手段として、類似する業務プロセスを共通化しシェアード化していく方法があります。

システム運用・サポート業務を主業務としている組織では、システム毎に担当グループが形成されており、業務が属人化されているがゆえに部分最適に陥っているケースが多く存在します。サービスを受ける側の事業部門から見ると、属人化ゆえに解決が早い場合もありますが、受付窓口が複数あり煩雑であることと、担当者が捕まらないと課題が解決しない等の問題を抱えているのも事実です。また、組織面から会社全体の業務を俯瞰した場合、似たような業務を行っているグループが複数点在することになり、非効率な組織構造、ムダが多い状況となります。

これらの問題を解決する為、シェアード化の１つの施策としてサービスデスクを設置する事例が増えてきました。しかしながら、サービスデスク自体の成熟度や品質の問題でなかなか上手くいっていません。

今回は、サービスデスクを導入してサービスの質も上げていく成功要因について考察を行っていきます。

サービスデスク担当者の観点で見ていくと、他組織が開発したシステムをサービスの質を落とさずに運用しなければならないという非常に難しい業務を強いられることとなります。今まで通りの考え方でサポート要員を配置しても、サービスデスクが担当しなければならない業務範囲は広く、自身で解決できない範囲はすぐに横（従来のシステム保守担当者）に渡してしまい、サービスデスク自体が機能しない、単なる取次窓口化してしまう場合があります。

このような事態に陥らない為にも、計画性を持ってサービスデスクの成熟度を上げていかなければなりません。実際のところ、多能工なスキルや専門性が深いスキルを持った要員を配置すればサービスの質は上がるのですが、経済性を考えるとそういうわけにはいきません。また、システムが安定稼働しており問合せや障害が月数件程度のものに、サービスデスク要員の教育やドキュメント類の充実を図る為の費用は捻出できないのが実情かと思います。

そこで、サービスの質を向上させながら、経済性も考慮したサービスデスク設置の施策を簡単に説明します。採算ラインを下回るサービス（システム）の対応は、サービスデスクでは受付のみとすることで、教育等に係る負担を減らします。採算ラインを上回る対応に関しては、ドキュメント化の整備や教育計画を立ててサービスデスクで対応可能な範囲を徐々に拡大していきます。

図1. サービスデスクでの適応範囲の考え方

① 財務管理の観点で、適応業務範囲を決める
まずは、提供しているサービス（システム）毎にどれくらいのコストがかかっているかを素早く把握できる仕組みを導入します。その上で、サービスデスクで対応したほうがよい業務範囲を見定め計画を立てます。業務ＫＰＩ等を設定し日々の活動量を分析できるようなサービスマネジメントツールを用いることで、定量的に業務量が素早く把握できるようになります。

② 専門性の高いサポート業務と、普遍的に対応可能なサポート業務を切り分ける
専門的なスキルに頼ったサポートは、初期段階のサービスデスク要員には期待できません。そのため、専門的なスキルでの対応が必要なものに関しては、短期間でエスカレーションできるように予めルール化します。

③ ドキュメント化を徹底する
サービスデスクの業務範囲を広げていく為には、ドキュメント化が欠かせません。事業部門の課題を解決し、必要に応じて開発保守部門に連携する等、ＨＵＢとなるのがサービスデスクの役割ですので、場合によっては用語変換しなければならないケース等が発生します。事業部門と開発保守の両視点でのドキュメントが必要となってきます。

ドキュメント化に関しては、事業部門と会話ができるように業務プロセスを理解しておく必要がありますし、原因究明の為にシステム構成を理解し影響範囲の特定や早期解決に向けた対策の検討ができる必要があります。サービスデスク業務では、このような情報に短期間でアクセスでき、また早期理解につながる為のドキュメントが必要となってきます。

ドキュメント整備にはコストがかかりますが、長期的なスパンで経済性を検討し、どこまでのレベルでドキュメント化するか検討し実施していくことが重要となります。本来であれば、開発時に設計書として存在するはずのドキュメントが、更新が滞っていたり、継接ぎだらけの設計書であったりと、システム運用フェーズで使用できる状態では無いケースが多いです。

図2. リアルな企業活動の設計図

業務設計、システム設計、運用設計が１つのドキュメントとして関連性を持って閲覧可能(図2)であるならばこういった問題も起きないですが、現実的にはドキュメント種類も、更新ルールもバラバラであるかと思います。弊社で取り扱っているARISは、企業に存在するあらゆる設計書をモデル化しリポジトリ管理することで、このような課題を解決します。気になった方は是非コメントをお寄せください。