読者です 読者をやめる 読者になる 読者になる

なからなLife

geekに憧れと敬意を抱きながら、SE、ITコンサル、商品企画、事業企画、管理会計、総務・情シス、再び受託でDB屋さんと流浪する人のブログです。

グループ会社間の人的リソース共有は部分最適のありがちな姿じゃね?

雑記

M&Aで大きくなった会社って、大概、似たような機能を持つ部門がいくつかの会社に散在してたりします。


で、だれでも思いつくのが、「一緒にしたほうが効率ヨサゲじゃね?」って話。
意外と簡単で、コスト削減に結びつくように見えるから、目に見えた成果に結び付けやすく、すぐに飛びつく傾向にあると思います。


プロセス改善なんかも、

  • Eliminate(やめる、捨てる、除く)
  • Combine(統合する、結合する)
  • Rearrange(並べ直す)―あるいはReplace(置き換える)
  • Simplify(簡単にする、単純にする)

というECRSのように、統合することはコスト削減効果が高いといわれています。


具体的なシーンでいうと、経理とか法務とか総務とか、まっさきに親会社に寄せてしまいますよね。
経理や法務はよりどころが法なのでどの会社でも同じ、ってのはわからんでもないですが。


現場との距離が離れてしまって、現場担当者に負荷がかかったりとかして。


で、その後にターゲットにされるのが、システム系の部門。


事業領域が違うと、必要とされるノウハウがぜんぜんちがうのに、統合されたりします。
どうせ、同じ言語、おなじプラットフォームのうえでシコシコ作る人たちでしょ?的な考え方もはびこりやすい。


ちょっとマテ。


もし、ノウハウ部分まである程度類似性があったとしても、統合してリソース共有とかすると、その先に何がおこるか予想つきますか?


統合するってことは、共有したリソースをどうやって活用するか、という判断まで、その複数会社で動く案件ひっくるめて優先度判断して割り当てることになります。


大概、親会社に寄せ、親会社の案件を優先してリソース割り当てが決まる。
つまり、リソースの割り当て優先度を下げられてしまった子会社のビジネスが、部門統合以前のスピードでは回らなくなる。


そりゃ部門レベルでミクロに見れば、リソース稼働率とか、以前よりあがってるかもしれませんよ。


でも、ビジネスとしてスピードダウンしてるところが出てくる。


全体最適のバイブル?である「ザ・ゴール」を紐解くまでもなく、
「鎖は、一番強度の弱いところで、全体の強度が決まる」
「隊列は、一番歩きの遅い人のスピードで、全体のスピードが決まる」
といわれているわけです。


それ、確実に劣化ですから。


そんな半端な部門最適ベースの効率化してどうするのと。
そこで削減したコスト以上に売り上げが落ちたりとか、してません?


半端に部門レベルのリソース統合なんかやるくらいなら、もっと根本から。
「統合される側がかかわってた事業って、そもそも、事業として続けるの?」


本気で続けるなら、事業単位での最適を考えなきゃね。
ただでさえ、ファンクション単位で部門を切ってしまって、プロセスのステップとステップのハザマが組織と組織のハザマとかになって、無用な壁とかできて非効率になってたりするところなのに、さらに会社をまたいで、親会社に一部門だけ吸収されたりとかしてしまったら、吸い取られたほうの会社は、リソースの自由すら奪われて、その事業は死に体になってしまいますよ。


そんなわけで、会社間の部門統合の話とか、真っ先に疑うタイプです。