2009年10月23日

[コンセプト]PDCAサイクルのあるべき姿

更新が不定期ですいません。

さて前回の話から明らかではあるのですが、PDCAで分析ができないのは、そもそもが分析すべき対象が存在しないからです。
つまり、PDCAは仮説検証のサイクルであるにも関わらず、仮説として設定されていないということです。
ならば話は簡単で、検証が可能なように仮説を設定するれば良いと言うことになります。

まず、目標は仮説になりません。
目標が不要であると言うのではなく、目標を達成できるように仮説を設定するのがマネージャーの仕事なのです。

こうした話になると、必ず今よりも広いマーケットを設定してという話が出がちですが、現実問題としてそれが上手く行ったという話はほとんど聞きません。
なぜならば、そうしたマーケットには強力な競合が既にいるか、そもそも需要がないからです。
こうした戦略が出来るのは、卓越したブランドを持っているか、業界トップの企業が周辺の領域へ進出するときぐらいでしょう。
要するに強者の戦略なのです。
世間の大半の企業にとっては関係がない話です。

では、製品力も価格もブランド力も何も差別化できていない場合はどうすべきでしょうか。
顧客が購入しているのが単純に製品そのものである場合は難しいのですが、大半の場合において顧客が求めているのは商品であり、商品とは製品+サービスです。
サービスは例えば支払方法であるとか、キャンセル可であるとか、相手が法人の場合は社内稟議の代筆など非常に幅広く考える事ができます。
明らかに自社製品が向かないが繋がりを維持したい場合は、あえて競合製品を推薦するというのも、サービスです。
つまり、マネージャーが設定すべき仮説は、目標を達成可能なサービスであると言うことになります。

と、ここまで書いてきましたが、大概の営業関係部署では大なり小なりこうした事をやっているはずです。
しかし、振り返ってみるとあまり変わり映えしないことを続けていると言うのも現実でしょう。
すなわち、こうした取り組みの結果が定着または積み重ねられていないと言う事です。
次回このあたりについて書きたいと思います。
posted by Senoh at 01:04| Comment(0) | TrackBack(0) | コンセプト

2009年09月01日

[コンセプト]上手く行かないPDCAサイクル

業務の改善手法としてPDCAサイクルがあります。
PDCAサイクル自体は有名なものなので、ご存知の方も多いでしょう。
しかしその一方で、営業活動などのホワイトカラー業務ででPDCAサイクルが上手く回っているという話はほとんど聞く事ができません。
もちろん全てがというわけではありませんが、ここではありがちな上手くいかないパターンについて考えます。

よくある、営業活動に対するPDCAサイクルは以下の様なものでしょう。

1. 予定として売り上げの目標を設定し、そのための顧客リストを用意する
2. 受注活動を行い、記録を残す
3. 目標が達成されたか確認する
4. 達成されていない場合は何が問題か分析し、改善案を立案・実行する

さて、目標が達成されているならば問題はありません。
問題になるのは達成されていない場合です。

では、目標が未達の場合は、どう分析すれば良いのでしょうか。
明らかな問題があるならば、それを改善すれば良いのですが、それはPDCAサイクル以前の話でしょう。
普段から鎬を削っているような場合は、そうした問題は既に潰されているため、「原因」を探るのは大変困難です。
そもそも営業マンの立場からすれば、「目標が高すぎる」と思わないわけがありません。
実際、無理なノルマを課しているだけという可能性はあるのです。

なぜ分析できないのか。その理由は簡単です。
目標が妥当である事を誰も証明できないからです。
会社を取り巻く環境は日々変化するのですから、過去の実績は根拠になりません。
本来、もっと目標は高くできるのに、なんとなく惰性で目標を低くしてしまっている事もあるでしょう。
会社が大変だから10%アップしろと言われても、それで売り上げが上がるわけもありません。
ベースになる数字に根拠がないならば、それをもとに分析できるはずがないのです。

次回、PDCAサイクルはどうあるべきかについて、自分の考えを書きたいと思います。
posted by Senoh at 20:57| Comment(0) | TrackBack(0) | コンセプト

2009年08月24日

[コンセプト]業務マニュアルとシステム

考えていた事を整理していたら、ずいぶん長い間更新が滞ってしまいました。すいません。

さて前回の続きですが、業務における「プログラム」とは何であるかと言えば、業務マニュアルが思いつきますが、これが妥当か考えてみます。

まず、プログラムは良く調査して該当箇所を変更することにより、システムの動作を変更することができますが、同じ事がマニュアルに対して行えるかと言えば疑問があります。

その理由は、マニュアルを変更しても、それだけでは誰も確認してくれないからです。
すくなくとも説明会も開かずに、運用ルールを変えられる会社はほとんどないでしょう。
マニュアルは参考にする程度のもので、組織はそれに基づいて動いているわけではないということです。

次にプログラムには、システムの全ての動作が記述されていますが、マニュアルはどうでしょうか。
例えば部門の社員を全員入れ替えて、マニュアルだけみせたとき、たとえ時間がかかろうとも前と同じように業務を遂行できるかということです。
これも常識的に考えて不可能でしょう。
現場には、マニュアルに書かれていない暗黙の運用ルールが必ず存在するものです。
なぜそうなってしまうのかと言えば、現場主導で業務を見直しているからです。
もちろん、そうした活動自体は良い事なのですが、その結果効率化が阻害されることがあるということです。

経営者の方々はこうした問題を普段から肌で感じているからこそ、運用ルールを抜本的に変える場合にシステム化の検討をされているのではないでしょうか。
つまり、システム化されれば、新しいルールを意識せざるを得ませんし、システムの指示に従うことでバラツキなく業務を遂行させることができるからです。
しかし、システム化は初期コストがかかるだけでなく、それを変更する場合にもコストが発生します。
これはマニュアルにはない欠点です。

マニュアルは柔軟であるが厳密性に欠け、システムは厳密ではあるが柔軟性に欠けると言うことになります。
ならば、システムの中にマニュアルの柔軟性を取り込めば良いのではないかと言うのがZiraffeのコンセプトです。

次回以降、もう少し具体的な形で検討をしたいと思います。
posted by Senoh at 03:26| Comment(0) | TrackBack(0) | コンセプト

2009年07月16日

[Tips]スナップショット

Ziraffeにはスナップショットと呼ばれる機能があります。この機能は、ある時点において表示しているデータをそのまま保存するものです。

例えば営業会議などで商談の進捗を確認する場合に、商談情報や社員の商談一覧のスナップショットを取っておくことで、前回からの変わった点を中心に確認することが出来ます。スナップショットの内容は(サーバ上の情報を直接変更でもしない限り)変更できないので、ある時点における証拠として保存しておくこともできます。

この機能を使う場合は、ページの右上に表示されている「スナップショット」をクリックして下さい。スナップショットが保存されます。スナップショットが保存されているページの場合、ページの左上の方(セルフリンクの右側)に「他のページ」が表示されます。スナップショットを表示する場合には、このリンクをクリックして、表示するスナップショットを選択してください。
posted by Senoh at 02:09| Comment(0) | TrackBack(0) | Tips

2009年07月13日

[コンセプト]ブラックボックス化について

ソフトウェア開発の世界においては、ブラックボックス化という考え方があります。これはシステムの各部分に対して、それが外部とどの様にやり取りをするのかさえ定義してしまえば、その内部構造は見えなくても構わないはずであり、ならば積極的に見えないようにしようと言う考えです。適切なブラックボックス化はシステムの構造を単純にし、効率よく開発が出来るようになります。これは業務に置きなおしてみると、仕事のやり方の変更も含めて、現場に権限移譲するイメージと言って良いでしょう。

ブラックボックス化は内部の実装方法に自由を与えるため、何か変更が必要な場合でも対応が容易であるとされてきました。しかし現実には、何か仕様変更をする場合は複数のモジュールにまたがって変更が必要な事が大半であり、結局内部の実装が分かっていなければ適切な対応を行う事はできません。

これを業務に置きなおすと、既存のサービスを一部変更するにあたり各部門の調整をしようとしたが、「その業務を自分の部署で引き受けるのは難しい」という言葉ばかりで出て、話がまとまらないような状況です。解決案を出そうにも部門内の詳細が分からないため上手く言えない、どうしても自分の考えを理解してくれない、そんな経験は数多くあるはずです。実際、部下の仕事を全て自分でも対応できる自信がある人は少ないでしょう。ほとんど方が、周囲に色々とやり方を聞きながら辛うじてといったところだと思います。自分が思っているほどには部下の業務の手順を理解できていないのです。

さて、では業務における「プログラム」は一体何なのでしょうか。次回のコンセプトではこれについて書きたいと思います。


posted by Senoh at 03:27| Comment(0) | TrackBack(0) | コンセプト