公司易主后，谁来负责业务系统？

公司换了新老板后，新老板需要知道由谁来维护软件。先找现在了解系统的人谈谈，商量谁继续负责日常工作、谁能批准变更，以及换人接手时要交接哪些内容。

假设你买下了一家使用定制系统处理订单和发票的企业。员工还能登录，订单也照常进来。目前看起来一切正常。

接着，一张发票没有成功送到会计软件。谁知道该从哪里查起？那个人还可以修改系统吗？他们是否同意为新老板提供帮助？

趁相关人员还在时，把这些问题问清楚。

谁能批准，谁懂系统，谁会提供帮助？

这可能是三个人。

运营经理可能负责批准订单系统的变更。开发人员可能了解系统如何连接会计软件。支持公司可能同意在约定时间内响应请求。

给经理一个管理员账户，并不能回答另外两个问题。你仍需要懂这套软件的人，也需要明确双方约定由对方提供哪些帮助。

先和现有团队或供应商谈谈。问问哪些人会继续参与，以及需要做哪些调整。澳大利亚网络安全中心的公司和组织变更指南提出了一个实用要点：关系发生变化时，要核实人员身份和权限。知道一个熟悉的名字，并不代表你清楚这个人现在可以批准什么。

为接手的人写下必要信息

不必一开始就写一大本手册。先从企业必须完成的工作写起，例如接收订单、发送发票、支付员工工资或制作月报。

对每项重要工作，记下：

• 谁负责业务决策？写明可以批准工作的负责人，包括涉及支出或变更时是否还需要他人批准。
• 谁维护软件？写下联系人，以及对方无法解决问题时该联系谁。
• 系统依赖什么？列出系统需要的账户、服务和连接，由谁管理，以及如何让合适的人获得访问权限。
• 接手的人需要了解什么？注明操作说明的位置，以及哪些人能解释内容。也要写下棘手情况的处理方法，例如发票卡住时该怎么办。
• 实际约定了哪些帮助？记录支持涵盖的事项、可提供支持的时间，以及如何提出请求。
• 还有什么没解决？把每个未答问题交给具体负责人，写明解决日期，以及它可能影响哪些工作。

小型系统或许只需要一份列出联系人和链接的简短文件。密码应放在合适的受保护密码管理器或访问管理系统中。这份文件只需说明如何安排访问权限。

让接手的人试做一项实际任务

有操作说明很有用。让接手的人照着做一次，才能更清楚地知道他们是否会操作。

以订单系统为例，可以请接手人员在测试环境中追踪一张样例发票。他们能找到问题出在哪里吗？如果问题超出他们负责的系统部分，他们知道该联系谁吗？

先取得适当授权，并在安全环境中安排这项练习。如果不方便演示，也可以请对方口头说明步骤。除非确有必要，练习时不要使用真实客户数据，也不要影响日常运营。成功完成一项任务只能帮助确认对方理解了这项工作，并不能证明所有可能的问题都已覆盖。

Google介绍其团队如何承担软件运营责任的文章提到，通过文档、培训和逐步交接来转移责任，同时由开发人员提供后援。小公司也可以这样做：给接手的人时间熟悉系统，并在他们学习时安排好可以求助的人。

现有人员或许就合适

新老板不一定要换开发人员。只要大家同意对方要做什么、听从谁的安排，继续使用现有供应商也说得通。

如果由新团队接手，他们可能需要培训，或需要一段时间和熟悉系统的人一起工作。商定这类帮助持续多久、相关人员何时有空，以及遇到约定范围之外的问题时该怎么办。

企业也可能计划以后把软件接入另一套公司系统，或换掉现有软件。应把这些计划与维持当前订单和发票正常处理分开考虑。NACD和互联网安全联盟关于收购的指南讨论了交易各阶段的访问权限和系统整合。日常运营交接只是更广泛工作的一部分。

也请顾问检查交易和相关协议。不要以为公司出售后，软件权利、合同、源代码、许可证、账户或客户数据就会自动转移。能够访问某项内容，和获准使用它，是两回事。

交接完成前，你应该能说清谁批准变更、谁知道如何实施变更，以及谁已同意提供帮助。如果有答案还不清楚，就指定一个人负责查明。

我们开发定制业务软件，也可以商定持续维护或协助交接。如果你需要有人维护现有系统，可以告诉我们系统的用途和你需要哪些帮助。