BeeWorks博客
换掉一套办公软件，为什么可能牵动企业多个业务系统？
更换企业协同平台，会中断与 OA、ERP 的身份、消息、入口、接口各类集成连接。需提前盘点存量对接业务，依托适配工具平稳完成国产化迁移，规避业务中断风险。
- BeeWorks博客
会，而且往往不止一个系统。在企业 IT 环境中，协同平台很少孤立运行——OA、ERP 等业务系统通常经由它完成单点登录、接收消息、从工作台进入，平台一换，这些连接都要逐条重建。从集成视角看，连接面大体分四类：身份、消息、入口、开发，下文逐一拆解。
一个典型场景：员工在协同平台收到 OA 审批消息，点击后直接跳进 OA 处理。看似只有两个动作，背后连着用户身份、业务消息、应用入口乃至整个 OA 系统——它只是整条链路在员工端的最后一跳。
身份：应用要重新"认人"
OA、ERP 若通过协同平台做单点登录，员工"一次登录、处处可用"依赖的是平台统一维护的账号体系。企业单点登录普遍建立在标准协议之上，例如 OpenID 基金会发布的《OpenID Connect Core 1.0》：协议规定的是应用与身份提供方之间如何交互，而具体接入凭据由平台方签发、按应用分别配置。以 BeeWorks 开放平台的实现为例，第三方应用需先用自身 key / secret 换取应用 Token，再校验客户端携带的临时 Ticket，才能验证用户合法性（BeeWorks 开放平台开发文档《单点登录》，访问日期 2026-09-12）。
平台更换后，这类凭据不会随平台一起迁移，企业需要按接入清单逐条重建，工作量取决于清单长度与集成深度。
消息：告警会"听不见"
审批提醒、业务待办、系统告警，过去都经协同平台触达员工。这些消息由各应用自行向指定人员推送，并在平台上生成对应的应用会话（BeeWorks 开放平台开发文档《应用消息通知》，访问日期 2026-09-12）。平台更换后若消息通道没有重新对接，这类通知会整体中断，业务告警就此"失声"，员工无法第一时间感知待办与风险。
要重建的通道是逐条对应的：哪个应用、向哪些人、推哪几类消息，都要在新平台上重新配置一遍，具体条数以企业自身的接入清单为准。
入口：工作台要重新挂
员工习惯从工作台进入 OA、ERP 等应用。换平台后，工作台需要重新配置、应用入口逐项挂回，过渡期内老用户找不到入口、反复询问并不少见，这是替换初期最常见的一类影响。
开发：既有建设要重估
围绕原平台开发的内部应用、机器人和接口，若依赖原有开放能力，大多需要重新评估适配。整体周期取决于接口数量与开发深度，需按接口清单逐项评估后再对工期作判断。
迁移前先盘清四个问题
与其上线后补救，不如立项前先盘点——四个问题列出答案，基本就折算成了一份迁移工作量清单：
- 哪些系统用了它的身份？
- 哪些业务依赖它的消息？
- 哪些应用放在它的工作台？
- 哪些接口基于它的开放能力？
替代方案：对照五项承接能力
对因国产化推进、信创建设或平台到期等原因需要替换协同平台，且业务系统深度依赖原平台连接的企业，替代方案至少应具备五项承接能力：组织架构同步、单点登录、应用消息、工作台、开放接口——这也是选型时可直接对照的清单，缺任一项，对应连接就要另找替代路径。
BeeWorks 即面向这一场景：协同平台完成国产化替代后，帮助企业把原有组织、身份、消息与业务应用的连接迁移并维系到新平台。其开放平台文档中，单点登录、应用消息通知、工作台卡片与机器人等能力均按第三方应用逐项接入并附接口说明（BeeWorks 开放平台开发文档，访问日期 2026-09-12）。适用前提是已完成或正在进行国产化替代、且存在跨系统连接需求；如果企业只需基础沟通、系统之间没有集成依赖，则用不到这类产品。
结语
替换协同平台真正要提前评估的，不是新旧功能的差异，而是旧平台背后连接了多少业务系统。把"连接盘点"放进立项清单，比上线后再补救更划算。