« 2008年12月 | トップページ | 2009年2月 »

2009年1月

機器のライフサイクルを定義しておく

社内ヘルプデスクで機器を管理するにあたり、導入(購入)から廃棄して物がなくなるまでのライフサイクルは、あらかじめきちんと整理しておく必要があります。また、物の廃棄後も、「廃棄済み」(リース物件の場合は厳密には「返却済み」)という管理情報は残さなければなりません。何故なら、情報漏洩が発生したような場合には、その漏洩元が廃棄済みの機器からである場合も考えられるからです。

極簡単に考えると、(導入)→「会社所有物」→(廃棄)→「廃棄済」という2作業、2状態です。(導入)と(廃棄)が作業、「会社所有物」「廃棄済」が状態です。

しかし、実際には社内ヘルプデスクが機器を管理する上では、もう少し詳細な作業と状態が必要です。パソコンを例にもう少し詳細にしてみましょう。

(導入)→「未セットアップ」→(セットアップ)→「出庫可能在庫」→(設置)→「使用中」→(撤去)→「未セットアップ」→(廃棄)→「廃棄済」

随分複雑になりました。実際には、撤去した後、再セットアップして使用する場合があるでしょうから、「廃棄済」への一方通行ではないはずです。また、不幸にも故障してしまったり、紛失してしまう場合もあるでしょう。社内ヘルプデスクではそれらを漏れなく無理なく管理しておこうと考えた場合、下の図で示すようなライフサイクルを考えることになります。

機器管理におけるライフサイクルの図

六角形が作業、四角形が状態(二重線は物がない場合)で、円形はトリガーです。導入直後の状態「初期」と、撤去した後の状態「未セットアップ」は、物としての扱いが異なるため、別の状態としてみました。「死在庫」という状態は、ロースペックで使えなくなったような物や、故障して修理する予定がないような物(修理する予定があるものは「故障」として管理する)です。

勿論、個々の会社により事情は異なるでしょうが、おおよそこれと似たような形で、殆ど全ての機器が管理出来るのではないでしょうか。ライフサイクルの定義が出来れば、各種作業のための帳票(作業指示書やチェックシート)や、台帳への反映ルールの作成、そして、それらを簡単にするための仕組みの構築が可能になります。これは、会社の大きさや機器の台数と言った規模の大小に関係なく実施する事が可能です。

次回は、機器を管理するための番号の振り方について紹介します。

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

機器管理について

社内ヘルプデスクを運用していると、必ず機器管理で壁にぶち当たってしまう事になると思います。それ は、機器は実際の「物」とその「管理情報」の2つの要素があり、「何処まできちんとやるか?」でかかる手間が大幅に変わってくるためです。正直な話、人間 は怠けてしまうところがあります。「きちんとやらなきゃ」と思っていても、ついつい手を緩めてしまい、気づいた時には管理が必要十分なレベルで維持できて いなかった、、、という事になり、それを取り戻すために大変な事になってしまうのです。

実際には、新しく始めた会社でもない限り、機器の 管理を全く新規に始める事は稀で、どこの会社でも既になんらかの運用を開始している事だと思います。そこで、今回からしばらくは、今までのやり方で良いの かどうかという事と、良くなければ何をどうすれば良いのかを考えるためのネタを書いていきたいと思います。

●管理する立場によって求める情報やレベルが違うという事を認識しておく
機 器を管理すると言っても、機器を管理する立場によって、求める情報やレベルは違います。本来であれば、会社の各部門で統一して機器に関する情報を管理する ような体制を作るのが良いのかもしれませんが、実際にはそうならない場合も多々あります。たとえば、経理系の部門であれば購入時の価格やリースの情報は細 かく必要でも、物に関しては「パソコン一式」のような管理で十分で、同時に購入した物には同じ「資産シール」のような物を貼りたいという要求があるかも知 れません。しかし、社内ヘルプデスクの立場では、パソコン本体とモニタは別物で、本体はさらにスペックの情報とOSと、、、と、細かい管理が必要になりま す。また、リース情報はリースアップ時に交換が必要になるため、経理系の部署の情報とリンクさせておかなければなりません。それぞれの情報をどう管理して いるかは会社により様々ですが、まずは、管理する立場によって求める情報やレベルが違うという事を認識した上で、どう管理していくかを考えなければいけま せん。

●社内ヘルプデスクで何をどこまで管理するか考える
社内ヘルプデスクが機器管理する際に何をどこまで管理するかを考えなけ ればなりません。最初にレベルを下げてしまうと、後から上げる事は非常に難しくなります。しかし、最初から高いレベルでやろうとすると、手間がかかって破 綻する羽目になってしまいます。たとえば、「LANケイブルの1本まで物の状態と台帳を完全一致させるんだ!」という事を掲げたとして、確かにそれが出来 れば素晴らしい事かもしれません。しかし、それを達成する事で何が得られるか、という事を考えて、本当にそれをやるのかどうかを決めなければなりません。 おそらく、会社としてはLANケイブルは「消耗品」として購入するため、その1本1本が何処でどう使われているのか、までを詳細に管理しなければならない 要求はないはずだからです。

これだけ書いたところで、何がどうというのはまださっぱりだと思います。そこで、もう少し具体的に考えを整理するためのネタとして、次回は、機器のライフサイクルについて書いてみたいと思います。

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

利用者へのお知らせ(周知)業務のポイント

社内ヘルプデスクは、社内システムのメンテナンスや障害情報を、利用者へお知らせするという仕事も担当します。社内ヘルプデスクは利用者からの窓口ですから、この手のお知らせを担当するにはもってこいです。そこで考えたいのは、どうやってお知らせを効率良く確実に行うか、という事です。

●考えられる手段
利用者へお知らせするとひとことで言っても、その手段は色々と考えられます。社内ヘルプデスクが何かするという切り口で考えると、「電話する」「メイルする」「FAXする」というような物もあれば、「社内のWebサイトに掲載する」「回覧する」「掲示する」「館内放送する」というような方法もあるでしょう。また、システムによっては、そのシステム専用のお知らせ機能を有しているものもあるかもしれません。

●どの場合にどの手段を用いるか決めておく
前述の通り、考えられる手段はたくさんあるのですが、社内ヘルプデスクとしては、どの場合にどの手段を用いるかをきちんと決めて、ある程度準備をしておく必要があります。たとえば、ネットワーク障害の時にはメイルでのお知らせは意味がないわけですから、その他の方法を採用する必要があります。さらに、障害であれば一刻も早くお知らせしなければならないため、連作先の情報は常に参照出来るようにしておかなければなりません。ここでも、名簿が電子データしかなく、ネットワーク障害発生時に参照出来ない、というような事になっては意味がないのです。

●利用者が知りたい事は何かを考えてお知らせする
システムによっては、社内ヘルプデスクがその中身の詳細を把握していない場合もあるでしょう。しかし、お知らせを社内ヘルプデスクが行う以上は、社内ヘルプデスクは利用者の立場で考えた際に知りたい事をきちんと伝えられるようにしなければなりません。つまり、「誰が」「何を」「いつ」「何をするから」「どうなるか(どうして欲しいか)」が明確かどうかを確認してからお知らせする必要があるわけです。

たとえば、会計系のシステムをメンテナンスするため一時的に使えませんというお知らせをする場合は、「会計のシステム“カイケイ君”に対し、システム開発業者が明日(2009年2月14日)の05:00AM-07:00AM)に勘定科目再設定(雑費:クリーニング費用新設)処理を実施するため利用できなくなります。その間はカイケイ君の操作が一切出来ません(画面を開くとエラーになります)のでご注意ください。なお、設定後の画面操作の詳細については、経理課が各部署に配布しているマニュアルをご覧ください。」というような感じになります。勿論、メンテナンスの中身なんて社内ヘルプデスクには関係ないよ、という場合もあるでしょうが、普段使える物が使えなくなるという事に対する案内をするわけですから、その概要だけでも伝える方が利用者の方に安心して頂けるのではないでしょうか。

以上のポイントをまとめると、以下の3点になります。

1.手段とシステムの関係を決めておく
社内ヘルプデスクとして使える手段とシステムを表にする
どのシステムの何(メンテナンス、障害)の時にはどの手段を使うか決めておく

2.連絡先の情報を把握、更新しておく
どのシステムの場合は誰に連絡すれば良いか?
連絡する相手が不在の場合はどうすれば良いか?

3.利用者が知りたいことをお知らせする
  「誰が」「何を」「いつ」「何をするから」「どうなるか(どうして欲しいか)」を明確に伝える

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

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

問い合わせ対応をどの時点で完了とするか?

社内ヘルプデスクで問い合わせや障害の対応をし、それを記録に残す事が軌道に乗ってきたとします。そこで気になってくるのが、問い合わせをどの時点で完了とするか、です。

とある利用者から、「印刷するとエラーで止まってしまう。」というコールがあったとします。調べてみたところ、「プリンタドライバにバグがあり、高繊細モードを指定して印刷するとエラーで印刷が出来なくなる。」という現象が発生する事が確認できました。それを根本的に解決するためには「新しいバージョンのプリンタドライバを入れる。」という方法しかありません。そのユーザに事情を説明すると、「高繊細で無理なら、普通で印刷するから良いよ。」と言われて新しいバージョンのプリンタドライバが入れ替えられませんでした。さて、この対応は社内ヘルプデスクとして完了という扱いにして良いのでしょうか?

これには、ITILの考え方を適用するのが良いです。まず、結論から書けば、「完了にして良い」です。この場合、問い合わせに対する回答は終わり、利用者もそれを納得しているという事で、社内ヘルプデスクとしての対応は完了なのです。しかし、それとは別に、「バグを含んだプリンタドライバを社内で使っている。」という「問題」を別途管理する事にするのです。

つまり、「問い合わせの対応」と「問題の管理」を切り離して考え、「問題」は問い合わせとは別次元で解決していく事にするのです。この場合、「全てのパソコンのプリンタドライバを入れ替える」(勿論、プリントサーバのプリンタを共有して使用しているのであれば、プリントサーバのドライバのみ入れ替えれば解決します。)という根本的な解決法があると同時に、今回のユーザが取った「高繊細で印刷しない」という暫定的な解決方法もあるのです。

そこで、社内ヘルプデスクとしては、問題に対し、「根本的な解決方法」と「暫定的な解決方法」を整理して認識しておき、その問題の内容や解決するために必要な手間(お金)を考えて、どういう方法で解決するのかを決めれば良いのです。今回の例のようなプリンタドライバの入れ替えであれば比較的容易ですが、問題によってはそう簡単に解決できない場合もあります。そういった問題に遭遇した場合は、利用者にきちんと事情を説明して「暫定的な解決方法」を提示し、社内ヘルプデスクとしての対応は完了とするのです。勿論、「暫定的な解決方法」には「諦める」というどうしようもないものも含まれます。問題が根本的に解決できるかどうかは会社の懐事情もありますので、利用者にそこをきちんと説明するのもヘルプデスクの大切な仕事です。

こうして対応を完了にして消し込んでいけば、未完了の対応がやたらと増えて精神的な負担が高くなって必要以上に疲れてしまう、というような事を防ぐ事にもなります。

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

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

社内ヘルプデスクで問い合わせを受け付ける時のポイント

社内ヘルプデスクは、システム利用者からの問い合わせに対応します。おそらくは、「電話」か「メイル」が殆どで、もしかすれば、「IM(インスタントメッセンジャ)」や「FAX」というのもあるかもしれません。問い合わせをする人は、システムを使う上で何らかの疑問を持っている、もしくは、機器がうまく動かないと言った現象に遭遇している場合や、「もっと綺麗に資料を作りたい」という感じの希望を抱いているかもしれません。いずれにせよ、問い合わせを行っているシステム利用者に対し、社内ヘルプデスクは何らかの対応を行う必要があります。

社内ヘルプデスクとして問い合わせを受け付ける時のポイントがいくつかあるので、それを紹介します。

●「ヘルプデスク」を前面に出す
規模が小さければ1人しかいないかもしれません。しかし、そうであっても、問い合わせをして下さった方に対しては、自分が「ヘルプデスク」であるという事をきちんと認識してもらうようにしましょう。理由は2つあります。1つは、「他のメンバでも対応可能になる」という事です。ヘルプデスクの仕事がうまく出来る人はつい指名されてしまいがちになりますが、常に対応が可能というわけではないのです。その際、「個人名」ではなく「ヘルプデスク」が前面に出ていれば、他のメンバでの対応がやりやすくなります。そして、もう1つは「異動した場合に説明しやすい」という事です。始める前から異動の話をするのもなんですが、とかく「社内の便利屋」として個人名が通ってしまえば、異動先での業務に支障が出るぐらい引き継ぎが大変になります。ましてや、同じ部署の中で違う役割になっただけの場合はもっと大変です。問い合わせをして下さった方には、常日頃から「ヘルプデスクとして接しているのです」という事を認識してもらえるようにしましょう。(社内ヘルプデスクとしての内線番号やメアド等、個人に依存しない受付方法が可能であれば、是非そうしましょう。)

●問い合わせに対して何らかの回答をする
社内ヘルプデスクに限らず当たり前のことですが、「回答をした」という事が、問い合わせをしてきた人との共通認識になっているという事が大切です。社内ヘルプデスクが回答をしたつもりでも、システム利用者はそう認識していない、というような事ではお話になりません。問題がきちんと解決していなければならないという事はないのです。問い合わせしてきた人に対して、その人の考えとヘルプデスクの考えが一致していること、これが重要です。

●記録を残す
「対応は記録を残す部分まで含める」が基本です。対応が重なると、記録が後回しになってしまう事があります。しかし、それではマズイのです。そうすると、記録しなければならない事がどんどん溜まっていき、あっという間に破綻してしまいます。記録があれば誰かに引き継ぐ事も容易になりますし、増員を会社に申し入れる際の根拠にもなりますし、。いかに簡単に早く、要点を押さえた記録を取ることができるかがポイントになってきます。社内では記録を残しやすい手段で問い合わせをして来て下さる方は殆どいないかもしれませんが、可能であれば、記録を残しやすい手段で問い合わせをして頂けるように工夫してみると良いです。

明けましておめでとうございます。
今年の前半で、広く浅く一通り書いてしまいたいと考えています。
その後は、狭く深く、より具体的な事を書きたいと思います。
本年もよろしくお願いします。

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

« 2008年12月 | トップページ | 2009年2月 »