フォト
無料ブログはココログ

Six Thinking Hats リンク

« クレームへの対応-総集編(3) | トップページ

2015年11月25日 (水)

クレームへの対応-総集編(4)

  合併後の混乱が落ち着いたのはそれから3年後であった。吸収された会社側の社員は海外転出組や営業部門を除いてそのほとんどが退職してしまった。理由は個人によって違うが、共通していたのは努力しても評価されないと将来を悲観したようだと何かの折に人事課長から聞いた。自分から積極的に仕事を探してキャリアを重ねてゆく会社にあって、上から指示された仕事を言われた通りにする会社で長年過ごした人間は何をしてよいかわかなかったのだろう。見よう見まねで覚えた仕事の知識が全く役に立たなかった。忙しかった毎日を振り返るとほとんどが無駄な会議と不要不急の仕事ばかりだった。営業は決められた顧客に挨拶に行くだけ、設計は同じデザインの焼き直しか他社のコピー、製造は不良が出ても全数検査で取り除くだけ、納期は守ったことがない・・・ブランドに惹かれて入社した社員は一流大学が多かったようだが無能な上司やマネジメントに「教育」されて数年もしないうちに日々出社するだけが仕事のような無気力人間になってしまった・・・合併前はそんな状況だったらしい。

  合併に先立って両社の社長は人材の活用や顧客満足度の向上、市場の拡大、製品群やサービスメニューの充実など相乗効果を掲げ、会長と社長(旧社社長)の経営体制になった。
ところがその意に反して、旧社長はヘッドハンティングで決まっていたらしく新社長になっても出社せず合併発表後に転出してしまった。在庫もなくなり旧製品すべて販売終了、スペアパーツがある保守サービスを残すだけとなり、相乗効果は立ち消えとなった。ブランド力があったので旧製品はバブルの時代には売れたかもしれないがそれがはじけたとき、すでに技術的に古く、高額なだけでコストパフォーマンスが低いため高いメンテナンス料をかけてまで使い続ける顧客はいなかった。ほぼ同性能で価格が半額の製品に置き換えて顧客を確保する方針へと変更をかけたが、旧製品を扱っていた営業部がかたくなに拒み続けた結果、他社の製品に置き換えられてシェアを奪われていった。顧客の要求に合わせて会社が変わっていかなければならない。その会社を形作っている組織も柔軟に変化して対応しなければ生き残れないー適者生存の法則が企業活動にも当てはまる。

  危機感を感じた会長は社長を兼務し、新製品の開発を急がせた。3つの開発チームが立ち上がり、コードネームは I,J,Kで呼ばれた。3か月で試作品が完成、コストと機能(価値)を見積もり、AHPによってコストパフォーマンスを評価して開発する製品をIに選定した。


Ahp


 
 


 
  新製品 I はその後主流となるインターネットを駆使して様々なデータのやり取りやネットワーク機器の制御を可能にした意欲作だった。海外派遣組のエンジニアも設計段階から参加して3か月で発売にこぎつけた。それというのもこの新製品 I を使って国内と海外拠点をネットワークで結んでプロジェクトを進め、通常は市場に出てから発生するであろう様々な問題点を洗い出し、リアルタイムで改善できたことが大きかった。このコンカレントエンジニアリングは開発期間を短縮する理想的な方法だがこの実績が後の開発設計の基本になった。くすぶっていた双方の軋轢も解消し、ようやくワンチームとして会社がまとまった。

    新製品 I はハードよりもソフトに特徴があった。顧客は月々一定の料金を支払えばインターネットに接続するだけで様々なアプリケーションを使うことができる。それまではバージョンアップするたびにパッケージソフトやライセンスを買い替え更新の費用負担が問題になっていたが、必要な期間だけ契約すればよいので運用費が安くなる仕掛けだ。他社からの乗り換えなら費用が半額になるというキャンペーン効果もあって新製品 I は発売後1週間で当初の販売計画を大きく上回り、バックログを抱えて3か月待ちとなった。

  ケース7.顧客の囲い込みすぎが起こした問題

     ところが、発売後2か月もたたないうちにキャンセルが相次いだ。ユーザーからのアクセスが予想以上に多く、サーバーが頻繁にダウンするようになったからだ。アクセスできないならまだよいが作業中にフリーズしてデータが消失する事態も発生した。販売量に応じてサーバーを順次追加していたが焼け石に水であった。セキュリティを確保することと、ユーザーの利便性を考えてネット環境の中だけで作業や処理が完結するように設計され、データやファイル形式をそのアプリケーションに最適化していたために従来製品と互換性が全くないことも問題だった。また、オプション購入や有料ヘルプデスクを使った場合の課金システムもわかりにくく、高額請求されたユーザーからのクレームもあった。

  ケース8.ウィルスによって情報漏えいした問題

     急遽、データに互換性を持たせたりエミュレーションソフトを提供して他社のアプリケーションでも処理できるようにしてアクセス数はそれから3か月後には落ち着いてきた。ところが、外部機器と接続できるようにしたことでウィルスに感染しやすくなり、全体を管理していたホストは無事だったがローカルサーバーのいくつかはシャットダウンしてメールやWEBの閲覧ができなくなった。バックアップしていたデータで完全回復までに1週間がかかり、業務の遅滞や停止で損害を受けたユーザーからペナルティを請求された。それで収まるかに見えたが、ユーザーから発信元不明のスパムメールが大量に寄せられているとの指摘で管理していた顧客名簿が流出していたことがわかった。すぐさま対策本部を設置して顧客と連絡を取りパスワードやメールアドレスの変更を依頼して対応した。

  こうして新製品 I の出だしは好調だったものの技術的にも、販売方法や運用にも課題が多かったので代替案としてAHP評価で順位が2番目だったプロジェクトJに開発を続けさせていて、ほぼ完成していた新製品 J へと社長は切り替える決断をした。製品 I ほどの画期的な機能はないものの扱いやすく必要十分な処理能力と操作性があったので目標の80%を維持することができた。

  予測や判断は結果が出てから正しかったかどうかがわかる。予測は同じ経験をした期間だけが可能だ。たとえば製品 I を3か月販売したらその後の3か月は経験した3か月のデータでほぼ正確な予測が可能だが3か月以降は判断するしかない。データに基づく推測は予測だが、経験が全く無く、データに基づかない推測は予想-当たるかどうかわからないがとにかく方向を決めるしかない。新製品 I はネットワークに特化することが他社の製品とを差別化し、新しい顧客を獲得するという「予想」に基づいて判断された。その予想は間違いではなかったが別の理由で売り上げ増という成果を上げることはできなかった。正しいかどうか何を基準にするかは議論の余地はあるが考え方が正しかったとしても結果的にビジネスが立ち行かなければ正しいとは言い難い。

  巷間、数多の経営(者)論があるがたまたま成功したビジネスを分析した結果、その成功の法則を見出しただけで、これから成功するビジネスの法則については予想するしかない。当たるか当たらないかはその企業の組織力と社長のリーダーシップにかかっている。経営論で確かなのはこの点だけではないだろうか。
Claim4

« クレームへの対応-総集編(3) | トップページ

ファシリテーション」カテゴリの記事

コメント

コメントを書く

(ウェブ上には掲載しません)

トラックバック

この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/1814389/62645852

この記事へのトラックバック一覧です: クレームへの対応-総集編(4):

« クレームへの対応-総集編(3) | トップページ