昨日の続きです。

さて、今回は「問題・障害・要望」の管理です。

少ない人数(3,4名程度)でASPを管理しなければならない関係上、思いきって諦める部分は諦めて、
締切、品質を妥当なレベルを維持していくということに関してはそれなりに経験し、苦悩してきたことなので、
多くの方の参考になれば幸いです。

そして、お客さんのところに行って、
「個人でやっているレベルかと思いましたが、だいぶ大人数でやっているのですねー」
と成果物を見て言ってくださった大手企業の担当者さんがいましたが・・・

このときは「してやったり」と思ったものです。

紙を使え・色を使え

1対1でサービスを提供しているケースでない場合、問題・障害・要望は、ぐちゃぐちゃで上がってきます。

「あーそれはバグだな」というケースも、お客さんは要望としてあげてくださるケースもあれば、
「使い方を間違えている」というケースも、「障害だー」と声を大きくしてくるケースもあります。

しかし、これらは調査の結果として「そうであった」ということなのですが、
「如何に顧客の意図を間違いなく早くつかむか?」
が、その後のスピードに大きく影響を与えます。
そして、それはお客様の満足度(心象も含めて)向上にも貢献していくのですから、重要です。

記入には紙を使うのが早いし、汎用的だ

お客さんから報告が上がったら、それを既定フォーマットの紙に記入します。
エクセルファイルや、システムだったりすると、ディスプレイが1つしかないのに、
お客さんと一緒に画面を見ながら、記入していくのに面倒です。

また、お客さんのところに行った時に渡される資料は紙しかもらえないかもしれません。

PC上のデータを紙にするのは簡単ですが、その逆は大変です。
まずは、紙でさばけるだけ、さばきましょう。

そして、それらのセットを2つ用意します。
1つは、種別管理(問題・障害・要望)毎と、もうひとつはお客さん毎です。

これで、お客さん対応の人も、問題解決部隊も、自分たちの軸で見ることができます。
あの情報はどこのフォルダだ!なんて、探す手間が省けます。
立場が違えば、視点も違います。営業中心だ、運用中心だと言わず、
双方で管理するにはコピーが簡単です。

そして、紙のいいところは、量があるということです。

このあと、それらをファイリングしていった時にも、
「結構問題があるなー」とか、このお客さんからは、意見がおおいなーなんてのも直観的にわかるので、

急に過去を引っ張り出したいときにも、データ検索に紙では問題(欠点)があるというかもしれませんが、
データ検索にはない様々なインデックが頭にあるという利点も考慮に入れる必要があります。
人間の記憶容量は意外に大きい物です。ただ、インデックス(思い出すきっかけ)がないので、小さいと思ってしまうだけです。

どんなお客さんなのかを、直観的に判断するには見た目感覚が重要

さて、紙で報告が上がってきても、言われていることが、「問題」なのか?「障害」なのか?「要望」なのか?
を判断する必要があります。

すぐにわからないような問題でも、言われている内容をよーく吟味しないとわからないかといえば、そうでもありません。
たいていは、今までの報告内容が重要なヒントをくれます。
しかし、お客さんにとっては1対1でも、こちらにとっては1対(大勢)です。
1つ1つの会社について機械のように覚えきれていることを求めるのは酷というものです。

ここでSI企業ならば、過去のお問合わせをDBから引っ張りだし、そこで画面に出すなんてことを言うでしょう。
でも、そもそも運用がこれで固まっているわけでもありませんし、
せっかく(?)少ない人数なのですから、「つーかー」で済ませられる部分に新たな負荷を設けたくありません。

と、ここで、「色」の登場です。
お客さん毎にバインダーファイル(コクヨとかの)があり、そこに「色」があります。
この色でなんとなく、お客さんの性質を管理します。

当然「赤」は要注意です。それは、重要顧客かもしれませんし、こちらのミスで非常にケアしなければならない顧客かもしれません。
また、「黄色」「青」とか、数色で管理します。
エクセルとかだと、自分たちで管理したい項目をたくさん作り、結局は管理する工数が大きくなってしまいがちですが、
もともと、曖昧で境界線がないものを、無理に境界線をつくるより、曖昧なままで管理する方が、
根拠のない数値の羅列よりは伝わる情報は多く、そして早いです。

状況が変わったと誰かが判断すれば、色紙を張るなり、差し替えるなりしましょう。
部分的にステータスが異なる事項ならば、付箋の色で管理しましょう。
付箋の色がたくさんつき始めたら、誰かがファイルの色を変えるでしょう。

枚数で、過去と現在の雰囲気を把握

紙でやっていれば、当然、古ければ古いほど、または、報告が多ければ多いほど枚数が増えてきます。
また、終了済みとそれ以外でバインダーを分ければ、

これで、「あー、結構この会社にはやっちまってるなー、まだまだ、完結していない報告があるのかー」とか、
「おいおい、最近障害が増えてきてるが、さばくのがおそいなー」とかもわかります。

よくつかわれるバインダーはそれだけ汚れるし、あんまり使われないのはきれいだし、
そして、何よりバインダーの場所からも各担当者がどのように考えているかも見えたります。
(資料のしたーの方にあるとか、いつもすぐ使えるところにあるとか・・・)

正しい数より、傾向や雰囲気がわかればいいのが管理者です。
ただでさえ少ない作業者の手間を割いて、報告を待つなんてことはあってはいけません。

それを意識して数と組織レベルにそってバインダーを作っていけば、
管理者が知りたい情報がおのずと整理されていくでしょうし、作業者は判断が単純明快になるのです。

こうして管理するだけでも数百クライアントは少人数でいけるので、それを達成してからでもIT化は遅くはないでしょう。
そのときには、管理もかなり洗練されているはずです。

それを根拠に管理ツールを作れば、製品化して売れるレベルだと思いますよ。

お仕事のご依頼・相談を承ります
この記事に関連するお仕事のご依頼やご相談をお待ちしております。 詳しくは、こちら

Leave a Reply

お仕事のご依頼・相談
この記事に関連するお仕事のご依頼やご相談をお待ちしております。 詳しくは、こちら
ソフトウェア&ライブラリ




ライブラリ
airxmail(en)
AIR版メール送受信ライブラリ
airxzip
AIR版ZIP圧縮・解凍ライブラリ
執筆書籍
本、雑誌等

WEB記事:CodeZine
執筆記事はこちら
カレンダー
2010年6月
« 5月   7月 »
 123456
78910111213
14151617181920
21222324252627
282930  

カスタム検索
RSS
Add to Google < !–adsense–>
アーカイブ
カテゴリ
にほんブログ村 IT技術ブログへ