ここで言う問い合わせは
問い合わせに対してマネジメントとは、大袈裟なイメージかもしれませんが、問い合わせから派生する課題認識は、問題の発見や事業の改善点へのヒントとなり得ますので、着目すべきものです。
よくある問い合わせに対してFAQを作成したり、それをAIチャットが答えたりという対応がなされています。そのような比較的定型的な質問に対する答えの効率さは重視されています。
ここでは、PC操作やID管理などの定型的なものでなく、ITスタッフが非定型的な問い合わせをユーザから受ける問い合わせを対象としたマネジメントを解説します。
場合によっては、問い合わせを発端としてプロジェクトを起こすという大袈裟な対応をとることもあり得ます。
それでいて、ITスタッフが対応できるとは限らないため、マネジメントされていない可能性があります。
ここで言う問い合わせマネジメントとは
ITに関わる問い合わせは多岐に亘ります。その大多数はＰＣやネットワークなどに関することなので、業者に対応してもらっているかもしれません。
そのような比較的定型的なものではない問い合わせを受けるということは、ややややこしい案件が発生したことになります。
IT導入プロジェクトにより稼働したITに対して、一定期間後に何か間違っている等の問い合わせであれば、既にテスト段階ではないため、特別なことが起きていると思うのが普通でしょう。
あるいは、新たな取引ケースが発生したがどのようにITに登録すればいいか、ということに対しては、想定していなかった要求が発生したことになります。今ある機能で問題なく対処できればいいですが、そうでない時は一工夫必要であり、対処に苦労することでしょう。
このようなトラブルっぽいことであっても、あるいは追加要求っぽいことであっても、すぐに対処できることも多いのでマネジメントということは特に行われないことのほうが多いかもしれません。しかし中には重要な要素が含んでいることもあります。
よって、問い合わせを受け付け、リスト化などを行い、処理を確実にするということをマネジメントしていけたほうがよいです。
問い合わせの種類
問い合わせは、先にも述べたように多岐に亘りますがが、ここでは以下のように種類分けします。
問い合わせを行うということは、何らかユーザが困ったことがあり、解決したいという趣旨で発生しています。
困っていることが何に対してか、また時系列に考え分類します。
問い合わせ例
| 観点 | 現在 | 過去 | 未来 |
| 利活用 | やり方がわからない | 過去にどうだったか | 新しいことをやりたい |
| トラブル | 普段と違う | 違う数値が蓄積された | これやったらNGか |
主に利活用上で困っている時と、何らかトラブルが発生し困っている時があります。
利活用における問い合わせ
まず今まさに困っていることに対して、問い合わせが起きます。そもそもやり方がわからないというものです。
これはマニュアルで対応できるものが多いです。マニュアルがあっても問い合わせが来るということは、マニュアルを見ていないかマニュアルでもわからないかということになります。
ITの一般的な操作マニュアルではわからない不親切なことがよくあります。実務的な対処をわかるようにしておく必要があるのかもしれません。
次に、過去に対しては、過去導入した時のプロジェクトに関することであったり、過去に取引を追加したときの話であったり、過去のデータのことであったりと、表面的にはわかり得ないことが問い合わせとして発生します。
そして、未来という観点では、新たな取引を行ったり、ルールを追加したりする際にどうすればいいか、ということが問い合わせとして発生します。未来については、利活用に関することですので、ITの仕組みをかなりよく理解していないと場合によっては対処できません。
トラブルに対する問い合わせ
まず、今何らかITを利用している上で、思った状態と違うということが発生し、ユーザがトラブると認識した際に問い合わせが発生します。
トラブルは、実際は障害起因かもしれませんし、仕様どおりかもれません。仕様どおりの場合は、ユーザの使い方が悪いのかもしれません。
今まさに起こっていますので、対応を取らないといけない状態です。
次に、過去に起因するものです。ITに蓄積されたデータがどこかの時点からおかしく、例えば、月次で集計した際に請求金額が違っているといった事象です。過去起因のものは厄介です。その時点で何が起きたのかは、過去のことですので手掛かりが少ない可能性が高いです。
そして、未来のトラブルに関してですが、未来にトラブルを発生しかねない問い合わせというのは、何なのでしょうか。
それは、今何かユーザがITを使って新たなことを行おうとしていますが、その操作は、うまくいかない可能性あるというものです。
うまくいかないかもしれないと薄々感じているため問い合わせしてきているということです。
ITの利用面に関してもすべてをわかっていればいいですが、問い合わせを受けたとしても、ITスタッフが例外的な利用についてすべてわかっているとは限りません。このケースも厄介な問い合わせと言えます。
問い合わせへの対処としてのあるべき姿
ここで言う問い合わせについては、かなり厄介なものも含まれているため、対処が難しいケースも多々あります。
すべてに真面目に取り組むと工数がかなりかかります。よって結果コストが掛かってしまうということになります。
だからと言って、放っておいたり、いい加減な対処を取るわけにはいきません。事業そのものへ影響が出る可能性もあるからです。
それでは、問い合わせに対する対処としてどうあるべきかということとなると、マネジメントされている状態にすべき、ということになります。
あるべき姿とは、何らか発生してしまったものではありますが、今後に活かし、よりよい方向に向かわせるということになります。
まずは、一定数発生することは否めない前提で、発生したものを認識できるようにします。
認識されたものをリスクを踏まえて正しく対処します。
対処経緯および結果について、今後活かされるべきものを抽出し、しかるべき対策を打っていきます。
問い合わせマネジメントの手法
問い合わせに対するマネジメントの手法は以下のとおりです。
受け付けシステムを構築する
受け付けシステムとは少し大げさですが、ITとしてのシステムを導入するということだけを言っているのではなく、仕組みを構築するということです。
まず、問い合わせとして認識し、受け付けるという行為を明示的に行うというところから始める必要があります。明示的ではなく、なんとなく対応していて、工数は掛かっていても、何の成果にもなっていないことがよくあります。
そのため、まず受け付けるという行為を明示的にし、受け付けたからには対応するということも義務化されるようにします。
受け付けした案件をリスト化する
ここで問い合わせを案件としました。明示化され受付されたものは、案件として対応していくことを正式化するために、案件と表現しています。
案件を受け付けシステムの中でリスト化し、一つひとつを解決していける土台を作ります。
リスト化された案件の優先順位をつける
リスト化されると今抱えている案件を比較してみることができます。
その中で優先順位をつけるようにします。
受け付けたものから順番に対応していくと、急ぎ案件が後回しになっていたり、逆に期限のないものが先に行われてりして、非効率になります。
優先順位のつけ方には、熟練が必要です。よく知っている人にしてみると、特に決めていなくても対応できますが、そうでない人のために、順位をきちんと決めたほうがいいでしょう。
順位のつけ方の基準は、まず、急ぎかどうかということがあります。急ぎだと言われたからと言って本当に急ぎかどうかはわかりません。本当に急ぎのものとそうでもないものを見極めて順位をつけます。
次には、影響度を考えます。その問い合わせ案件が何に起因しているか、そして何に影響するかにより、影響度を決めます。
優先度の例
| 優先順 | 重要度 Ａ | 重要度 Ｂ | 重要度 Ｃ |
| 緊急度 Ａ | 1 | 2 | 4 |
| 緊急度 Ｂ | 3 | 5 | 7 |
| 緊急度 Ｃ | 6 | 8 | 9 |
案件の対処方法を検討する
案件の対処方法は様々になります。
ここではややこしい案件を取り扱っていますので、すんなり答えられないことが多いと思います。よって、何らか計画を立てるところから入る必要があるでしょう。
対処方法を探るために調査が必要であれば、調査の計画を立てます。
優先順と解決までの許容期間を考慮したうえで、調査の期間を設定します。
場合により過去の情報をひっくり返して調査しなければならないこともあるでしょう。
対処を実行し、経緯も記録する
対処方法が決まればあとは実行することになります。
この時に、経緯を記録しておきたいです。ややこしい話であるがゆえに、同じようなことがあれば参考にしたいです。
案件の対処状況を定期的に把握する
案件リストは常に最新にされていなければ有効なものとはなりません。
定期的に把握することを習慣化する仕組みを導入したほうがよいでしょう。
もし、優先順位が高いにも関わらず、既に期限が過ぎていたなどということは避けたいです。
案件は状況次第で対応方法を検討しないといけません。
優先度が高いものが未実施であればとっとと実施しなければなりません。調査のまま解決策が見出せていないものについてもテコ入れが必要です。
案件から見て取れる今後に活かされるべきことを抽出し、しかるべき対応を取る
案件リストを後から見ると、血の滲むような努力が見えることが望ましいです。
それほど簡単ではないことに対処してきたのですから、その記録は何かに活かせないはずがありません。
今後に活かされる意味では2面あります。
一つは、問題への予防です。トラブルを対処した記録の中には、類似したトラブルを想起させるものもあるはずです。
トラブルはいつ起きるかわかりませんし、何が仕込まれているかは事前に想定することはできません。しかし、似たようなことをが起きないように、予防策を考えることができます。
もう一つは発展の種としてです。
ある顧客との取引で、Ａ商品とＢ商品の組み合わせにおいてのみ取引条件が異なってくることに対して、ITが対応がしておらず、なんとか今ある機能の組み合わせで対処したとします。
この取引条件というのは、取引を継続することや取引金額を上げることに寄与するものなのでしょう。そうであれば、ITとしての機能をつければ、顧客を増やせる手段になります。あるいは顧客を増やせる手段のヒントになることもあるでしょう。
問い合わせへの対処でありがちな問題
無理やりねじ込まれる
問い合わせ元となる人は、意図しているかどうかに関わらず、無理やり押し付けてくることがあります。
ユーザの仕事であるにも関わらず、ITの仕事として、結果仕事代行になっていようなこともあるでしょう。
ユーザからすると、ITがうまく使えるのは当たり前で、少しでも問題と認識すればITに問い合わせという名の代行業務を押し付けるようなこともあるでしょう。
それも事業上必要なことであればいいですが、本当に必要などうかは、見極めて対応しないといけないのでしょう。
受け付けシステムが厳しすぎる
受け付けシステムが厳しいというのは、ルールをガチガチにしてしまったり、対処できていないと怒られたりすることです。
そうなってくると、ただでさえややこしい問題への対処なので、水面下での対処になりがちです。
受け付けシステムの有効化には、習慣化が必要です。徐々に慣れていけば、かなり有効な状態にそれほど工数を掛けずになっているはずです。
後ろ向きに考えてしまう
問い合わせを受けるほうであるITスタッフは受け手として仕事が増えるので、率先して実施する側に回りにくいかもしれません。
そうするとマネジメントとしての運用を開始したとしても、結果的にはあまり運用されなくなります。
実施した結果、ややこしい案件がさばけていきますから、マネジメントされずに、なんとなくやるべき仕事が積み上がってしまうよりはいいはず。
しかしなかなか未来は想像しにくいですから、後ろ向きに捉えてしまうことはあります。
問い合わせマネジメントで本当にやるべきこと
ここでいう問い合わせは、比較的定型的なものではなく、非定型なものという話をしました。
非定型であるがゆえに、対処も簡単でないにも関わらず、突然湧いて出てきます。場合によっては重たい事案もあります。
緊急度や影響度も様々であるがゆえに、まずは本当に対応を検討すべきかの入り口を作るところから始めたいです。
突然割り込みで時間を奪われることもありますので、後ろ向きにもなりがちです。
しかし習慣的に対処する仕組みとすることで、何も苦痛を感じずに、次々に対処できている状態とすることも可能です。
そして、さらなる未来を考えてマネジメントされれば、問題の予防や事業発展に寄与できるようにさえもなっていくものです。
コメント