结论先行：把协同这件事自己搭一套，起初往往既省钱又顺手：数据在自己手上、权限按自家组织设计、不用迁就外部产品的节奏。真正难的是后面那几年——功能要跟着业务改、权限要跟着组织调、外部的人要能进来。这三笔账在立项时几乎算不出来，却决定这套平台能不能长期跑下去。可行的判断方式只有两条：把长期维护折成年度成本再横向比，并先数清楚有多少协同场景需要跨出企业边界。
自建一开始确实解决的问题
自建的理由通常是成立的：流程按自家业务长出来，不需要为了通用产品去改动作；数据不出自家边界；也不用跟着外部产品的版本节奏走。对涉及核心竞争力的部分，这些理由足够支撑自建。
问题出在「协同」这个词本身。协同工具覆盖的是一批通用能力——开会、写文档、共享资料、审批流程、找人对事。这些能力使用频率高、涉及人广、还天然会往外延伸。把它们放在自建平台上，等于用一支内部团队去承担一批每个月都要见的公共基础设施。
三笔容易被低估的账
长期维护
上线只是起点。此后每年都要跟着终端系统版本、浏览器、移动端、账号体系的变化做适配；员工提的需求要靠排期接住，而这类需求的特点是零碎、无边界、随时来。公开的服务商方案资料里，一家服务型企业放弃自有办公应用给出的三条理由中，排在前面的正是「持续投入的运维与研发成本产出不理想」。
边界
协同天然会跨出企业：对客户、对上下游伙伴、对外部顾问。自建平台的账号体系通常止步于自家名册，跨出去要靠临时手段——把文件导出发出去、在外部平台另开一套群，或者干脆回到个人社交软件里聊。第二条理由「内外协作难、体验割裂」说的就是这件事：平台内部很好用，一到边界上就断。
生态
通用协同能力是所有企业都要的，所以它会在成熟平台上按季度演进：在线表格、会议、资料库、审批、对外分享，这些东西的更新速度取决于平台的用户规模，而不是某个企业自己的排期。自建平台只能跟着自家团队的排期走，第三条理由「平台封闭，无法及时跟上外部节奏」讲的就是这个差距会逐年拉大。
怎么算这笔账
- 把维护折成年度成本。首年投入只是一部分。要把「需要有人持续接需求、持续做适配」折成每年的人力与工时，再加上平台自身的许可与硬件占用。
- 把跨边界场景数出来。列出有多少协同动作要在企业与外部之间发生。数量大的话，自建平台的短板会被反复触发。
- 把迁移成本一起算。如果已经在自建平台上跑了几年，资料、群、权限关系都是迁移工作量，不能只比较「新建一套的成本」。
哪些该自建，哪些用现成
判断标准可以简化成一句话：这件事是不是我们的差异化。
- 涉及行业特有流程、特有数据模型的系统，自建或深度定制。
- 沟通、会议、文档协作、企业网盘、审批、对外共享这类通用能力，用成熟的协作平台。
- 两者之间的接口要有人管——谁能看到什么、数据往哪边流，这属于架构决策，不能默认。
边界与前提
自建与采购不是非此即彼，也不是「自建一定错」。更常见的现实路径是先上通用能力、保留与业务强绑定的部分，或者反过来：先把通用能力迁出去，再逐步收敛自建范围。另外，本文讨论的是决策依据，不涉及对具体平台或产品的评价。深圳市奇摩计算机有限公司在为政企客户做办公与协作平台落地时，通常先把通用能力与业务专有分开列，再决定各自放在哪一侧。
如果你正卡在自建与采购的取舍上，欢迎 预约咨询。