{{item.title}}
{{item.text}}
{{item.title}}
{{item.text}}
2022-03-09
デジタルトランスフォーメーション(DX)を推進するにあたり、新システムを導入するケースが多いですが、導入する以上多くのユーザーにシステムを利用してもらうことが重要です。そのためにはユーザーがシステム利用の障害となるような問題に直面した場合に、それを解消するようなサポートをストレスなく受けられるような仕組みが必要です。本稿では効率的なユーザーサポートの仕組みの構築について、実例を紹介しながら解説します。
DXを推進する際には、新しいシステムの導入も伴うことが多いです。しかしシステムを導入するだけではDXの目的は達成されません。大きな成果を得るためには多くのユーザーにシステムを使ってもらうことが重要となります。
そのためにはシステム利用の障害となるような問題が生じた際に、それを解消するようなサポートをストレスなく受けられるような仕組みを構築する必要があります。満足なサポートが無い場合、ユーザーはシステムを利用することによるメリットを過小評価してしまったり、利用負荷を過大に評価してしまったりすることで、システムを利用しなくなってしまう恐れがあります。
ユーザーをサポートするには、大きく分けて2つの方法があります。1つはヘルプデスクと呼ばれる、ユーザーからの問い合わせを直接受けつけて解消する窓口を設ける方法です。もう1つはユーザーが問題を自己解決できるようにシステム自体を改善したり、マニュアルやFAQの公開といったサポートドキュメントを拡充したりする方法です。
DXを推進する際には複数のシステムを多数のユーザーに向けて導入することが多く、サポートに要する工数はシステム数やユーザーが増えるに伴い増加します。2つのサポート方法を有機的に組み合わせることで、効率的かつ持続性のあるサポート体制を構築することが重要になります。
PwCあらた監査法人(以下、PwCあらた)全体のDXを推進する部署であるアシュアランス・イノベーション&テクノロジー部(以下、AIT)での事例を元に、効率的なユーザーサポートモデルを紹介します。
AITではユーザーサポートを主に2つのチームで提供しています。1つはプロダクトチームです。こちらはシステム企画、導入および保守開発といったプロダクトマネジメント全般を行うチームであり、サポートドキュメントの提供主体です。このチームは会計士やITの専門家で構成されており、現在30名程度のメンバーで多数のシステムを運営しています。
もう1つがヘルプデスクチームです。こちらのチームはユーザーからの問い合わせ窓口を担っており、マニュアルやFAQに記載されている内容や過去の問い合わせ事例を元に、問い合わせの一次対応を行います。ヘルプデスクチームで解決できない問い合わせについては、プロダクトチームの担当者に対応を依頼します。チームは現在、5名のメンバーで運営しています。
図表1はサポートフローの概要を記載したものです。
プロダクトチームは毎年複数の新システムをリリースしており、今後も同様のペースでリリースを続ける見通しです。サポート範囲も年々拡大する見込みであり、ユーザーに必要なサポートを効率的に提供することが課題になります。
ユーザーサポートには2つの方法があることを前項にてご紹介しました。1つはヘルプデスクによる対応、もう1つはユーザーが自己解決できるような仕組みによる対応になります。効率的にサポートするためには、この2つの方法の特色を理解したうえで上手く組み合わせる必要があります。
ヘルプデスクではユーザーに寄り添ったサポートを提供できるため、自己解決にゆだねる場合と比べて、ユーザーがシステムを利用しなくなることを防ぎやすくなります。また、問い合わせ内容からシステムの改善点を把握することもできます。一方、問い合わせを受けるたびにヘルプデスクチームおよびプロダクトチームの人的リソースが必要になるため、問い合わせ件数の増加に比例してサポートコストが高まるという課題があります。
ユーザーが自己解決できるようにする方法は、資料作成などの対応を1回でも実施してしまえば、追加のサポートコストはほぼ必要ありません。一方、ユーザー自身にも自己解決をするITスキルが必要となります。また、ヘルプデスクでの対応と比べるとユーザーが抱えた問題を正確に把握できないため、問題点が分からないままユーザーがシステムを利用しなくなってしまう恐れがあります。
|
ヘルプデスク |
ユーザーによる自己解決 |
---|---|---|
メリット |
|
|
デメリット |
|
|
リソースが潤沢にあるならばヘルプデスクでのサポートを手厚くすることが理想的です。しかし、システム数や利用ユーザー数が年々増えていく現状では、ユーザーによる自己解決を促し、新システムのリリースを継続して行えるようにサポートコストを下げることが重要です。
では、ユーザーによる自己解決ができるような施策を進めるにはどのようにすればよいでしょうか。実は、ヘルプデスクに寄せられた問い合わせ内容が重要な役割を果たします。
ヘルプデスクに問い合わせが寄せられるということは、システムの操作性やサポートドキュメントが不十分であったと考えることができます。その問い合わせをもとに、ユーザーが自己解決できるように検討することで、問い合わせの件数を減らすことができます。このような取り組みを継続することで、サポートコストは逓減していくのです。
図表4は、ヘルプデスクで問い合わせを受け付けてからサポートコストの削減につなげるまでの流れを示したものです。起点はヘルプデスクへの問い合わせ受付となります。問い合わせがあった際、その場では解決までに多くの時間をかけられない場合も多く、問い合わせたユーザーの問題を解決できるならば、暫定的な方法も含め問題解決に努めます。その後、問い合わせ内容を振り返り、ユーザー自身で問題が解消できる方法を検討し、実際に改善します。その上で、ヘルプデスクに同様の問い合わせが来なければ適切に改善できたと判断します。
ユーザーが自己解決できるようになるためには、どのような施策を検討すれば良いでしょうか。まずはユーザーが問い合わせにたどり着くまでのステップを見直し、改善可能なポイントを特定することが重要です。
ユーザーはまずシステムを操作します。問題が生じた際にはマニュアルやFAQを参照します。それでも解決しない場合にはヘルプデスクに問い合わせを行います。つまり、ヘルプデスクに問い合わせるまでに、ユーザーが触れるシステム内、もしくはマニュアルやFAQなどのサポートドキュメントのいずれかで問題を解消できるような情報を提供できれば、ユーザーは問題を独力で解決できるようになります。
改善すべきポイントを絞り込む際には、問題の内容がヒントになることがあります。例えばシステムの不具合が原因である場合、システムを改修するのが良いでしょう。また、マニュアルやFAQの誤りが原因である場合には、その部分を修正すべきです。
ただし、多くのケースでは複数のポイントを改善する余地があります。そういった場合には、どのように判断するのが良いでしょうか。考え方の1つとしては、特に発生頻度が多いものや重要度が高いものについてはシステムでの改善を最優先し、次にマニュアルを充実させ、最後にFAQを拡充させることが考えられます。これは問題が解決するまでの速さとユーザーが目にする頻度を軸とした改善方法です。システムそれ自体はユーザーが必ず触れるものであるため、システム自体の使いやすさを向上させることが最も効果的です。ユーザーはシステム外部の資料を参照する必要がないため、問題の解消も最も速くなります。ただし、システムを変更するための追加コストが高くつく場合や、SaaSなどのように外部システムであるためそもそも修正できないものもあります。
その場合はマニュアルを充実させることで対応します。マニュアルはユーザーが初めてシステムに触れる際に参照する可能性が高く、ユーザーに内容を覚えてもらうことも期待できます。SaaSなどの外部システムであっても自社向けのマニュアルを用意するケースは多く、改善の余地がある場合が多いです。ただし、マニュアルに情報を詰め込みすぎると読みにくくなり、ユーザーがマニュアルを敬遠してしまう可能性もあります。そこでマニュアルに反映するほどではない些末な問題についてはFAQに記載するようにします。
改善を行うポイントや優先度は、発生した問題の内容やシステムの特性、自社のユーザー特性によっても変わるため、優先度の高低は一概には言えません。ただし、どこを改善するかによってその効果も異なるため、改善すべきポイントは慎重に検討することが重要です。
これらを前提に、具体的な問い合わせ内容と改善例を紹介します。
これら3つのケースが示す通り、ユーザーが問題を自己解決できるような改善は小さな修正で達成できることが多くあります。そこで求められるのは、特別な技術や知識ではなく、問題の原因を整理し、適切な方法を検討することです。
なお、ユーザーが問題を自己解決できるようにするためには、ユーザーにも一定のITスキルが必要となります。PwCあらたでは、全職員に向けたデジタル研修を行うことでスキルアップを図っています。デジタル研修に関する詳細は、コラム「AI時代の社員教育(4)役員・新人が同じ机で研修」をご参照ください。
このように効率的かつ持続的にユーザーサポートを提供することで、DXがより進んでいくと考えています。