單位合并對IT系統的影響

一般情況下，在IT管理層獲知合并的消息時，其仍處于保密的狀態。因此IT部門應該迅速行動起來組成一個專門的項目組，利用這有限的時間，克服雙方IT系統相關信息不對稱或不全面的困難，充分發揮類似于“騎象人”的作用，層層把關、有條不紊地在前期做好各項可行性分析和準備工作，使兩頭企業級的“大象”能夠逐步靠近、首尾相連、并同步邁進。

那么在合并之前，用一句話概括就是：做好IT環境的調查。具體如下圖1所示，我們可以借用業界常說的“十倍準備”，來著手做到如下的各個方面：

圖1

首先，最基本的就是雙方各自清點、羅列出類似于如圖的IT服務與應用系統的清單。其范圍大體包括：網絡服務、主營業務、辦公郵件、電話移動、服務臺、用戶桌面、文檔庫管、協作通訊、視頻會議、市場開發、財務人事、IT工具和安全審計、以及虛擬化和云服務等領域。應當注意的是：無論要合并的兩家單位其業務是同領域還是不同行業，在填寫清單里的具體內容之前，需要IT管理層對清單條目的分類做好劃分，這樣在項目組成員填寫的時候才能做到有的放矢，生成的清單才具有可參照性和對比性。另外，由于每個人的角度和見解不同，因此在填寫的過程中對于“注釋和狀態”的描述信息是非常必要的。

針對這些清單，我們在統計造冊的時候還要特別注意幾點：

圖2

1、硬件設備系統的清單，要注意闡述系統的異構性和自身存在的兼容性以及備件等。

2、軟件服務系統的清單，則要注意厘清同質性、識別當前所使用到的功能模塊和軟件技術支持程度等。

3、而考慮到人員的流動性，關于從業人員的清單內容，不需要對應到具體的人，而是應該落實到角色，訪問權限以及其所對應負責的軟硬件模塊等方面。

4、與財務/行政部門合作，列出IT部門軟/硬件資產價值成本清單，以及為保證IT 環境日常運轉所涉及到的各種服務的費用支出清單等。

接下來，雙方企業就應該基于這些所收集和自查到的資料，進行進一步的“文檔梳理”和總結歸納了。具體包括：

a、三大圖：系統邏輯框架圖、網絡架構圖和應用之間數據流轉圖。我們可以參照那些在警匪大片里經常看到的辦案人員畫的思維導圖，并可進行分層、分級的局部細化展示。

b、IT相關的規章制度。比如說單位對于社交和即時通訊軟件的態度、使用以及發布/轉載/披露等方面是否有明確的監控與限制策略。

c、IT發展規劃。如近期需要更新的技術、替換的應用或模塊、將要采取的安全措施或方案等。

d、目前正在開發的技術、服務，或是正在實施中的IT項目所處的階段與成果。

e、與第三方合作參與的合同、委托第三方的SLA和MA等。對于IT外包比較多、或已有利用到了云服務提供商的情況，要生成服務與合同對應的列表。

f、重審 BCP 和 DRP。即：對網絡、服務及數據的災備方案、發生問題時的恢復流程、以及應急預案進行稽核，標注出MTD、RTO和RPO以及驗證和演練其有效性等。

g、對系統與服務的當前性能瓶頸、遺留問題以及投訴痛點等進行如實的記錄和詳盡的描述。當然也可以體現出關鍵業務部門和IT管理層的一些主要顧慮點。

h、IT合規和安全實務。確認自身系統的基線，羅列出近一、兩年發生過的網絡和安全的事件和問題。

i、與IT相關的知識產權狀況。比如說：那些并非直接使用了第三方的軟件，而是要求其按照單位需要所定制開發的軟件系統，其委托定制部分的知識產權就應當屬于甲方而非第三方所有。

j、對IT部門崗位進行諸如：職權范圍、薪酬水平、培訓發展等屬性的標記。

k、列舉企業日常運營以及從事項目活動中的IT相關資質認證的持有情況。特別要表明安全方面資質的范圍與年限。

所有這些IT相關的清單和文檔總結準備就緒之后，可以進行就“互動”環節了。

A、雙方的項目組成員進行實地互訪?；ピL的內容包括：對IT部門和部分業務管理人員進行詢問與座談、對數據中心或呼叫中心的實地參觀、以及運營與業務流程的模擬展示等。

B、相互交換所整理的清單和各種文檔，由一方牽頭草擬出點對點的雙方情況對照表（如上述表格的綠色與粉色部分所示）。

C、另外，收購方要特別注意被并購方的SLA、MA和NDA等合同里的條款，需協同法務部門對在并購后的可能出現的合規、以及法律風險進行考量。

根據上述各種主客觀相結合方式所調查獲得的數據，雙方項目組成員需要進一步坐到一起，合謀標記或直接對關鍵的系統、網絡以及服務進行重要程度的定級，并有效地識別出、和預見到并購后企業可能出現的各種風險、或碰到的兼容性問題了。本階段的“干貨”輸出就是：要共同制定出實施IT系統整合的路徑圖和具體的實施步驟，同時勾勒出并購之后IT系統的整體治理和發展方向。當然，項目組要最終形成的可行性報告要提交董事會報批。

圖3

一旦單位并購開始，IT系統整合進入實際操作階段，每個項目組成員都會感覺到“時間緊、任務急、頭緒多”的真諦。因此，這里我給大家羅列出自己的一些“前車之鑒”，請看圖3：

任何因素的不到位都會成為“那顆擊倒巨人的石子”。比如說數據庫對接或遷移時出現的不兼容問題等。因此項目組要提前制定好合并首日（Day One）的行動步驟和各種 Plan B、C、D，我們在這一點上可以參考平時服務發布時所用到的灰度或推/拉結合的方法，當然應該更為周密和詳盡些。

如果確實在并購過程中碰到了問題，其實我們應對的方法也有很多。比如說傳統的模式是：為了穩妥起見，可以雙方采用“雙活”戰略，即簽署諸如過渡服務協議（Transition Services Agreements）的來進行緩沖，規定在并購后的一段時間內能延續使用原來各方的一些舊的IT服務與系統。

另外，現在云計算與服務得到了廣泛運用，不少單位也可以臨時租用云空間來提供合并期的不間斷過渡服務，直至新的單位拿出更好的解決方案，再慢慢“擺脫”它們。

同時，一旦合并開始或者完成，用戶乃至客戶的問題會雪崩式的增長。相應的新單位的呼叫中心和其幫助系統的工作量也會急速增加。因此，只有提前制定好預案、分配好資源、以及做好現場技術支持（floor supporting）的準備工作，才能有效的避免投訴或災難的滋生。

此外，從業務安全的角度來說，IT系統整合之后，服務的所有者和使用者可能會相應的發生變動，進而產生相應的安全隱患和漏洞。因此要做到集中的、甚至是細粒度的控制。我們還是應該依托系統賦權基本原則，給予角色和組相對應的權限分配，以降低人員流動所帶來的權限積累或遺留所帶來的風險。

最后是IT組織團隊的問題。在合并之后，作為IT管理層要在保證團隊成員基本利益的前提下，重新定義他們的工作范圍與內容。而在降低人員的流動比率的同時，應適當地采取“末位淘汰制”，并提高整體的戰斗力來面對合并后新的任務挑戰。

由此可見，對于單位并購所涉及到的IT系統整合這類重大的項目，要想實現1+1不小于2的效果，我們一定要全局考慮、充分籌備，只有“做一步、看兩步、想三步”，才能避免產生現實版的敦刻爾克，從而平穩邁進“與象共舞”的狀態。