各位參賽者，我是你們今天的地獄主廚「小笠宏樹」，今天最好不要再給我看到牛排生到都在吃草了喔！！！

憂鬱的星期一就是要來首輕鬆的
熱寫生 heat sketch - 青元春朗

好的！今天要來討論的是併購～
假如各位讀者有看昨天那集討論外包的主題的話
應該能猜到今天的併購會向軟體裡面的什麼情況～沒錯！那就是不僅僅只是import library，而且還將library clone到自己這邊並且整合進專案！

整合這件事上，相信各位都會有很多血淚史，這也是會在市面上看到很多併購失敗的例子是一樣的，以下就來一一細數併購失敗的結果以及從工程角度去理解其原因。

失敗原因

1. 忘記初衷

   • 軟體方面 -> 在整合外部的library時如果沒有好好的做事前審視，很多的時候只是為了整合而整合，大多僅僅因為一點點難用就想將原本library的架構整個打散掉，結果忙活了半天才覺得當初幹嘛花這麼多時間整合，維持著原本import的方式不是好好的嗎？
   • 公司方面 -> 也會有一樣的問題，很多時候公司都會想說如果併購後就可以更加客製化原本外包的東西，溝通成本也會稍微低一點，或是可以讓客戶整個抓過來，但真的併購了之後才會發現，客戶數量也不是1+1=2，溝通成本跟客製化與併購時所花費的時間、金錢成本也根本不值得。

2. 整合不力

   • 軟體方面 -> 在整合外部的library時，很常會看不慣外部的做法跟程式碼原本的邏輯不同調，而因此想將自己的做法套入到外部的library中，結果就是改了一堆Class、程式邏輯，這時就會發現執行到最後根本跟自己重寫了一次library一樣，這樣子整合的意義就失去大半了。
   • 公司方面 -> 公司在併購的時候也時常發生因為管理的規則不一樣，導致強行要求被併購的公司要照自己公司的體制走，而導致許多部門重整，管理的方式全部改變，甚至是底下的員工受不了全部走光，這在於很多傳統產業都會發生類似的事情，並不是併購了一家品牌公司就可以做得出品牌，很多時候是文化、管理方式、人才才是養成品牌的土壤，忽略了那些，那最後甚至會人財兩失。

3. 沒有給予自主權

   • 軟體方面 -> 當是要整合一個外部的library來當作主要的功能時，還是會想保留著自己原本的做法跟邏輯，比如外部的library跟自身的程式碼都有一套傳Event的方式，這時候習慣性的會選擇舊的方式去把兩種傳Event的方式合成一種，而這種行為反而會去阻礙著主要功能開發的進行。
   • 公司方面 -> 當公司想要把某個新的商業模式併購進自己公司的時候，很常會想整合類似的部門，覺得這樣才能達到資源最佳化，但時常會事與願違，到最後還沒有把新的商業模式跑起來，競爭對手就又跟上了。

以上給了三種問題
主要的資料來源是來自於此篇文章
併購的三大敗因
其中提到的解法某部分也適用在軟體
比如第2點提到的整合經理人
在軟體裡面就像是多了一個介面層去處理外部library與內部程式碼，然後再慢慢的從這個介面層往外擴展去融合雙方的程式碼。
第3點提到的給與自主權也蠻有趣的
很多時候其實我們把外部的library clone下來後，幹嘛非得一直想要把它整合進來，有時候只是方便去改它一點東西做客製化就夠了，給他更多的自主權，只要雙方能合作就好。

以上我們講完了企業之間的併購
明天要來談談大家聞風喪膽的裁員