单位合并对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、双方的项目组成员进行实地互访。互访的内容包括：对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的效果，我们一定要全局考虑、充分筹备，只有“做一步、看两步、想三步”，才能避免产生现实版的敦刻尔克，从而平稳迈进“与象共舞”的状态。