« 2009年7月 | トップページ | 2009年9月 »

2009年8月

利用者に待ち時間をどう過ごさせるか

数年前から、HP製ビジネスパソコンに「MADE IN TOKYO」と書かれているのが気になっていました。実はその拠点は昭島で、そこが10周年になるという事をニュースの記事で読み、初めてその意味を知りました。

■ITmedia +D PC USER「東京仕様は“漬け物石”──日本HPのPC生産拠点、HP昭島工場に潜入してみた」
http://plusd.itmedia.co.jp/pcuser/articles/0908/27/news017.html

社内ヘルプデスクをしていると、パソコンの再起動中など、どうしても待ち時間が発生してしまう事になります。利用者がパソコンを使わない業務をするからという事でその場を外してくれれば助かるのですが、興味津々で作業を眺めていたり、トラブルで機嫌が悪い時などは対応を行う側としてはなかなか背中に冷たいものを感じたりしてしまう事になります。

そんなとき、ちょっとした話題でその場を繋げれば雰囲気が随分改善します。話術は社内ヘルプデスクが求められる技能の代表です。技術をやりたくて社内ヘルプデスクに配属された人には高いハードルかもしれませんが、短い時間で話せるネタは常に幾つかポケットに忍ばせておくと良いでしょう。

冒頭に挙げたネタはここ最近私が具体的に使ったものです。少しパソコンに詳しい人であれば、「MADE IN TOKYOって何だろう?」というのは少なからず気になっているようです。しかし、それをわざわざ自分で調べるまでは至っていないというような人に対してはこのネタが狙い目で、その拠点が「昭島」にあり、「10周年」という事だけで、随分話を膨らませる事が出来るわけです。

話し方やネタを題材にしたビジネス本は沢山あるだろうと思いますので、その気になって勉強すればひとまずのハードルは越えられるでしょう。天気や地方、テレビ番組と言った万人が理解できるネタと、利用者自身の身の回りの情報を掛け合わせて、その場の状況がさらに悪くならないようにするぐらいの会話術を身につけるという事を意識するようにしてみましょう。

次回もよろしくお願いします。

| | コメント (0) | トラックバック (0)

問い合わせを受ける手段でのベストは何か?

社内ヘルプデスクが利用者からの問い合わせを受ける手段は色々考えられます。私はその中で良い方法は何かと聞かれれば、ローテクではありますが、「電話」だと思っています。勿論、社内であれば内線電話の事です。Skypeのようなものでも構いませんが、その場合はSkypeが使えない、もしくは、繋がらない時の問い合わせ受付手段は別に確保しておく必要があります。

たとえば、書き物である「メール」や「チャット」は社内ヘルプデスクとしては記録を容易にする方法として歓迎出来るかもしれませんが、利用者の説明力が大きく影響してくるため「何を問い合わせされているのかわからない。」という状況に陥ってしまうことになります。

勿論、電話を使ったからと言って、利用者が自分の状況を的確に説明出来るとは限りません。はっきり言って、利用者からすれば画面の状況を伝えることでさえ、非常に困難な場合も多々あります。社内ヘルプデスクとしても、「エラーが表示されています。」と聞いただけでは何も解決出来ないわけで、その状況をある程度以上詳しく伝えてもらわなければ対応する事が出来ません。

そういう場合、現場まで駆けつけるというのも1つの方法ですが、早い話が「利用者の画面が見えれば良い」と考えれば対応のハードルが一気に下がります。WindowsXP以降であれば、「リモートアシスタンス」という機能が提供されているため、それをうまく利用すれば利用者の画面を参照する事が出来ますし、シマンテック社のpcAnywhereというソフトウエアのように、古くから使われているものもあります。VNCのような、フリーで使えるソフトウエアを用いても良いでしょう。勿論、これらの方法を用いる場合は誰でも接続できる状況にならないよう、注意が必要です。

というわけで、社内ヘルプデスクが問い合わせを受ける手段としてベストなのは、「電話」と「画面を見る手段」の併用だと考えています。後者については多少の投資が必要になる場合もありますが、全体効率を考えればすぐ元が取れる計算になるのではないでしょうか。

次回もよろしくお願いします。

| | コメント (0) | トラックバック (0)

サービスメニューの明確化と開示方法

社内ヘルプデスクは様々なサービスを利用者に提供する事になります。サービスが少ない間は簡単で良いのですが、種類が増えてくると何を提供しているのかわからなくなってきますし、頻度が低い物はそれが一体どういうサービスだったのかが曖昧になってしまう事もあります。そうならないよう、常にサービスメニューを明確にし、利用者に開示しておく必要があります。

利用者に開示する方法は、以前書いた「社内における情報提供の方法」のような手段を使いましょう。ここでのポイントは、「表向きは利用者向けとしつつ、実は内部向けにも必要十分な内容を記載して公開する。」という事です。勿論、申請に対する審査条件であるとか、パスワード生成の方法であるとかを書こうというわけではなく、社内ヘルプデスクが利用者に提供しているサービスはこういうもので、このレベルまでです、という事を明示する、という事です。こうしておけば、情報を二重持ちしなくて済みますし、利用者に向けて発信している内容と、実際に提供する内容が食い違うという事もなくなります。

もっとも、これを成り立たせるためには、公開している内容に変更があった場合は即座に更新するという作業が必要になります。しかしそれは、そこでどういう情報を公開しているのかという認識と、常にそこを見て業務を行うという仕組みがあれば、更新の漏れが発生する事はありません。情報を1ヶ所にまとめて常にそれを使う、という方式の良さを活用しましょう。

次回もよろしくお願いします。

| | コメント (0) | トラックバック (0)

様々な用途でバーコードを活用しよう

社内ヘルプデスクで機器の管理や伝票処理(申請処理)を行うに当たり、バーコードを使うという方法が考えられます。バーコードは今となっては随分古典的な方法ですから、ラベルプリンタや各種ソフトウエアで簡単に作成出来ますし、それを読み込むためのバーコードリーダも安価で手に入ります。USB接続のタイプであればパソコンへの接続も容易ですし、キーボードとして動作するため特殊な設定やソフトは必要ありません。そのため、接続さえしてしまえば、自動入力の装置として何にでも使うことが可能です。さらには、ハンディタイプ(コードレス)の物を使えば、倉庫で在庫の一覧を作る作業を行ったりも出来ます。やや高価になりますが、プログラムを仕込むことが出来るハンディタイプのバーコードリーダであれば、バーコード読み取り&数入力を行うように設定する事も難しくありません。

バーコードリーダを使う利点は沢山あります。

1.入力が早くて正確
2.バーコードを安く作成出来る
3.簡単に貼れる、剥がせる

しかし、気をつけなければならない事もあります。たとえば、プリンタの印刷設定によっては、バーコードが十分な解像度にならず、読み取りにくい、もしくは、全く読み取れなくなってしまうという事です。伝票に印字するような用途で採用する場合には、プリンタの設定に注意しましょう。また、バーコードを作る際に内容を合わせて印字しておかないと、バーコードが読み取れなくなった時に解読出来なくなってしまいます。とは言え、所詮はその程度ですから、その効果を考えると障壁は大したものではないと言ってしまって良いでしょう。

まず、身の回りでコードのような物を読んで入力しているシーンがないか探してみて下さい。そして、そのコードにバーコードが付けられないかどうかを考えてみて下さい。すぐにでも可能なものがあれば、とりあえずやってみる、というアプローチで随分その後の幅を広げることが出来るだろうと思います。

次回もよろしくお願いします。

| | コメント (0) | トラックバック (0)

サービス監視と実際の発見

社内ヘルプデスクでサービスの監視をする事があります。システムを使って自動で監視を行い、何らかの現象が発生した時に発報させる、という事はよくある事です。たとえば、ネットワークのトラヒックが閾値を超えた場合であるとか、サーバの応答がない事が確認できた場合であるとか。方法は色々ありますが、最近はメールが多いでしょうか。勿論、重要なシステムの場合はパトランプや警告音という感じの方法を採用する事もあるでしょう。

この手のシステムによる監視で気をつけなければいけない事が、3つあります。

1.監視するシステムが動いているかどうかの監視
2.発報時にどうすれば良いかの明確化
3.監視間隔の把握

1番は監視するシステム自身が止まっていると監視出来ない、という、当たり前と言えば当たり前の事です。しかし、実際にはメールシステムが変更になって監視システムからの発報メールが届かなくなっていたであるとか、パトランプの線が外れていて有事の際に鳴らなかったとか、そういう状態になる可能性は必ず含まれています。最終的にそれらを確認出来るのは人間しかいませんから、日々の運用の中で監視するシステムが動いているかどうかを監視する役割を設定しておく事を忘れてはいけません。

2番は有事の際の備えをどこまでしておくかです。せっかく発報しても、その先どうすれば良いのかが分からなければどうしようもありません。特に、発報メールの宛先をメーリングリストにしてしまい、「よく分からないけど受信してるだけ」という人ばかりになってしまって、結局その内容が理解出来ないという状況になれば、せっかくの監視も無意味になってしまいます。必ず何がどうなった時にはどうする、という所を明確にしておきましょう。

3番は意外と陥りやすい罠です。監視するシステムの監視がリアルタイムではなく、何分間隔という場合がよくあります。そのため、実際に障害が発生した場合、発見は監視するシステムより先に利用者や社内ヘルプデスクのメンバであったりします。特に、社内ヘルプデスクが直接使わないシステムの障害を利用者が先に見つけてコールになった際、監視間隔を認識せずに「管理するシステムでは何も検知していません」という結論を出してしまわないように注意が必要です。

当たり前と言えば当たり前ですが、当たり前の事をきちんとやってこその社内ヘルプデスクです。日頃の準備はきっちり行っておきましょう。

次回もよろしくお願いします。

| | コメント (2) | トラックバック (0)

« 2009年7月 | トップページ | 2009年9月 »