企业做国产化，原来的业务系统必须一起换吗？

答案：不一定。

企业国产化是长周期工程，预算、组织、技术评估、上线节奏很难统一。协同平台与业务系统的替换本就是两条时间表：协同平台先完成国产化，OA、ERP、CRM 等系统按各自计划运行，新旧两套体系在一段时间内并存。"过渡期共存"是更现实的推进方式。

真正要处理的是"保连接"

平台换了，但员工还在、业务还在、数据还在。真正要回答的问题只有一个——协同平台国产化之后，原来跑在 OA、ERP、CRM 上的业务怎么继续跑？

这件事不需要把旧业务系统推倒重建。需要重新处理的，是新协同平台与旧业务系统之间的连接，通常涉及五件事，每件事都可用一句判断标准验证：

1. 组织同步——部门和员工信息如何保持一致。判断标准：新平台能否与现有 HR 系统或目录服务同步组织数据，支持全量或增量导入。
2. 身份识别——原账号体系如何与新平台打通，能否单点登录。判断标准：已接入系统能否走标准单点登录协议，接入凭据能否按应用分别配置。
3. 消息触达——OA、ERP 中的审批、流程消息如何继续推送到员工。判断标准：业务系统能否通过开放接口把消息推送到对应的应用使用者。
4. 应用入口——原有业务应用能否整合到统一工作台。判断标准：原系统能否作为卡片或入口挂到工作台，员工能否从一处进入。
5. 开放接口——已有接口和内部应用能否继续连接和扩展。判断标准：新平台的接口与令牌机制能否覆盖企业已有的集成方式。

五件事打通，业务就能在新协同平台上继续跑。

最容易低估的是身份与消息

这五件事里，身份和消息依赖最深，最容易被当成"平台自带功能"。

以单点登录为例。OpenID 基金会《OpenID Connect Core 1.0》的定位是"构建在 OAuth 2.0 之上的一个简单身份层"，规定客户端如何验证用户身份、获取基本信息（规范第 1 节）。规范定义的是"怎么验"；凭据由谁签发、按应用配置，属于平台侧实现。平台一换，标准那层稳定，凭据那层必须重建。

以 BeeWorks 开放平台为例，第三方应用先取得临时 Ticket，再用自身 key / secret 换取应用 Token 并校验合法性（BeeWorks 开放平台开发文档《单点登录》，访问日期 2026-09-12）。

消息同理。业务系统的通知由各应用自行推送，并在平台上生成应用会话（BeeWorks 开放平台开发文档《应用消息通知》，访问日期 2026-09-12）。平台更换后，这两类凭据与通道不会自动迁移，只能按企业接入清单逐条重建。

BeeWorks 的角色与边界

BeeWorks 提供组织架构同步、单点登录、应用消息、工作台、开放接口等能力，目的就是在协同平台完成国产化替代后，继续连接企业已有的人员、身份、消息和业务应用。BeeWorks 开放平台文档中，这五项能力均按第三方应用逐项接入并附接口说明（访问日期 2026-09-12）。

但有一条边界必须明确：把 OA、ERP 连接到 BeeWorks，并不代表这些业务系统本身已经完成国产化。

BeeWorks 解决的是"新旧协同共存"的问题，替代不了业务系统本身的国产化规划，也不意味着连接后旧业务就自动满足信创要求。边界在哪里，需要企业自己判断。

国产化前的三个自检问题

启动国产化前，建议先自问三个问题：

1. 国产化的目标周期是多久？哪些系统第一批替换，哪些可以稍后？
2. 新旧平台之间，组织、身份、消息、应用入口、开放接口这五件事有没有清晰的连接方案？
3. 连接的边界在哪里——是被协同平台接入，还是业务系统本身已经完成国产化？

答案清晰就可以分阶段推进；答案模糊，先把"业务连接"想清楚再启动平台替换。

结论

企业国产化可以分阶段替换，但业务连接不能跟着断。

参考资料

1. OpenID Foundation. OpenID Connect Core 1.0 incorporating errata set 2（Final）, 2023-12-15. （Abstract 与第 1 节 Introduction）
2. BeeWorks 开放平台