ITは組織形態をかえるか

Kさん。メールをいただいたのに、ご返事が遅れて申し訳ありません。ITは組織形態をかえるか、というご質問ですが、ちょっと考えはじめてみたところ、意外に奥の深い問題なのに気付き、どうご返事しようか迷っていたのです。私自身、まだ頭の中で完全に答えが整理しきれたとはいえません。

この問題が難しいのは、「組織の変化」を考える際に、それが構造の変化なのか機能の変化なのかを区別する必要があるからです。企業組織に限らず、どんな仕組みであれ、それが目的に対してはたすべき機能があり、その機能を実現するために諸要素を組み合わせて構造をもたせます。組織を論じるとき、ふつうの人はすぐ「組織図」を連想しますが、これは目に見える構造の面をあらわしているだけです。しかし、構造は機能とあわせて、しかも現実の制約条件の下でみないと、正しく理解できません。

ちょっとわかりにくいと思いますので、例を挙げましょう。A社は全国に販売網をもつ、耐久消費財とサービス部品のメーカーです。組織は営業部門、物流部門、生産部門といった縦割り型です。ところでA社では少し前に、サプライチェーン・マネジメントの実現のために生産システムの改革を行ないました。ここは、全国各地の営業所・デポで製品在庫や部品在庫を持っています。以前は、営業所単位で販売動向と在庫量を見て、出荷依頼を工場に対して行なう形でした。

ところが、各営業所の在庫をオンラインで結ぶとともに、A社では営業の出荷依頼業務自体をやめてしまいました。かわりに物流部門が毎週、オンラインで各営業所の在庫量を見て、ある定数から減った分だけ補充輸送するようにかえたのです。工場としては、各地からバラバラに出荷依頼(=生産指示)がくるかわりに、ある程度まとめられた形で物流部門から依頼が来るので、計画がやりやすくなりました。それも在庫が切れる前に前向きにアクションできるので、緊急オーダーが少なくなったのです。物流部門も、いくつかの補充品種の混載などを考える余地が出てきました。

さて、この会社はITで組織が変わったと言えるでしょうか? 組織図上は、何もかわっていません。しかし、機能的には大きくかわりました。営業部門から補充手配業務を減らしたことは、『使用者と補充者の分業』(「コンサルタントの日誌から」 2007/02/12)の観点からいうと、はっきりと進歩です。

そればかりではありません。物流部門は、以前はただ「言われたとおりのことをする」だけの部門でした。しかし、(1)NOという権限が無く、(2)成功して当たり前で失敗すると怒られ、かつ(3)付加価値がないから外注化でコストを下げるだけ、と思われている部署で、だれが喜んで働けるでしょうか。それが、少しながら采配の自由度をもつ部署に生まれ変わったのです。

組織論は、勤め人の最大の関心事でしょう。それは自分の評価と直結しています。できれば大きな部門の、上の階層になって、花形として責任ある仕事をしたい。みな、そう思っています。だから組織図の方ばかりに目がいく。機能はどうあるべきか、という話には、なかなかならない。なっても、自分のささやかな権限を少しでも拡大したい、という方向にばかり願望は向かいます。

Kさん。あなたが「ITは組織をかえるか」という問題を立てられたとき、その底には、“今の組織はかえるべきだ”という潜在的な意識があったことと思います。しかし、現状のどこに問題があるのか。それは機能の問題なのか構造の問題なのか。かえるとしたら、何の理由で、何を目的にかえるべきなのか。そこが大事です。まさか、栄達や権力がほしいから、という理由ではありますまい。

組織をかえると言うとき、たいていの人はフラット型を空想します。ますますピラミッド型に、管理階層を高くする方向にかわってほしいという人は、めったにお目にかかったことがありません(本社の上の方の人は別として)。

しかし注意すべきなのは、ITが組織のフラット化をもたらすか、というような問題の立て方をしないことです。「組織のフラット化」は、ビジネス・ジャーナリズムが外資系の高級経営コンサルと一緒に、一種のマジック・ワードとして宣伝したおかげで、それ自体が目的化したきらいがあります。「二大政党制」だの「国際化」だのと同じ、是非の議論が忘れられた思考停止用語と化しているので、気を付けなければなりません。

ITの発達はほぼ確実に、中央集権化をうみます。これまで地方や現場が自律性をもてたのは、状況が本社からすぐ見えなかったからです。組織のトポロジーは、指示命令形態と情報伝達速度によって決まります。情報と意思決定の関係がこれを左右するからです。そして、意思決定(権限)範囲は、原則的には「責任」の範囲(これをスコープと呼ぶ)に対応するわけです。

Kさん。私は、すべての企業に共通な、理想的組織像など存在しないと考えています。ITが、その理想像を「ベスト・プラクティスとして」提供してくれる、などと思わないことです。まず目的があり、必要な機能がある。そして制約条件を満たすように、構造を決めていく--これが「設計」というものではないですか。ならば、制度設計も同じです。エンジニアならおわかりでしょう。どうか、その視点を忘れないでください。
by Tomoichi_Sato | 2007-05-21 23:21 | サプライチェーン | Comments(0)
<< プラント業界のリスク・オーバービュー プロマネのハードスキルとソフトスキル >>