政企 OA 选型：招标文件里没人告诉你的几件事
评标现场看到的、演示里看到的、参观时看到的，是三套不同的东西。选型的难点不在写参数，在于分辨这三套东西。
选 OA 这件事，最难的从来不是把需求写清楚。需求写得再细，最后拿到的几份方案看起来都差不多——都是六大模块、都支持流程自定义、都有移动端、都能对接统一认证。
真正的差别藏在别的地方：藏在演示没打开的那个页面里，藏在案例单位一线员工的抱怨里，藏在报价单里被压缩掉的那部分人天里。
下面这几点，是我在评标席上和在投标席上都遇到过的情况。写出来不是为了讲哪一方不老实，而是因为这两件事同时成立：甲方怕选错，乙方怕被误解。信息对齐了，双方都省事。
一、技术分通常拉不开差距，别再指望它
大多数政企 OA 招标的评分结构，技术分占比在三到五成之间，其中还有相当一部分是资质、案例数量、认证证书这类「有没有」的硬指标——这些是打分项，不是区分项，够格的家家都满分。
真正能拉开差距的往往是三类：
- 商务条件——付款方式、质保期、响应时限、违约条款；
- 价格——但价格低不等于总成本低，后面会讲；
- 实施团队——但这一项在多数评分表里只占很小权重，甚至不单独评分。
这带来一个后果：评标评出来的往往是「最会写标书的那家」，不是「最会做项目的那家」。标书写得好是一项真实能力，但它和交付能力不是同一件事。
如果想让评分更贴近真实交付能力，一个有效的改法是把「项目团队」拆成独立评分项，要求投标方列出拟投入人员的姓名、角色、同类项目经历，并约定实施期内人员变更需报批。这条要求会筛掉一批「中标后再找人来干」的投标方。
二、演示为什么会失真
演示环节几乎是所有选型里最容易误导决策的一环，原因不是演示方造假，而是演示环境本身就是一份精心准备的样本。
演示库里通常只有几十条造好的数据，流程是最顺畅的那条，附件是最小的那个 PDF，组织架构是简化的三层。在这个环境里，任何系统都跑得飞快、界面都清爽。
有三个办法能看到真实情况：
| 做法 | 能看到什么 |
|---|---|
| 要求演示用本单位的数据 | 拿十条真实流程、真实附件、真实组织架构导进演示库。数据一进去，列表页的加载速度、附件预览的兼容性、复杂组织的权限树，全是原形。 |
| 要求演示一个复杂流程的修改过程 | 现场让实施顾问改一条既有流程：加一个条件分支、改一个审批人、加一个字段。改得快不快、要不要开发、会不会影响在跑的实例，当场就看清了。 |
| 要求演示出问题时的样子 | 问「如果这个节点的人离职了，流程卡住怎么处理」。能立刻答出具体操作路径的，说明真做过；含糊其辞的，说明没遇到过。 |
三、案例参观：看一线，不看汇报
参观案例单位是选型里最有价值的一环，也最容易走成形式。走成形式的标志是：坐在会议室听对方信息中心主任讲四十分钟 PPT，讲完吃饭。
真正有信息量的做法是要求看一线员工的电脑。哪怕只看十分钟。
看什么？看这三件事：
- 待办列表长什么样。一个用了一两年的系统，待办列表里堆着多少条、多少条是超期的、用户怎么在里头找当前要办的那一条。这个页面骗不了人；
- 他们用不用手机端。如果一线员工说「手机端装了但基本不用」，要追问为什么。多数情况是审批体验差——要点开附件才知道在批什么，手机上根本没法看；
- 有没有在系统外走流程。问一句「有没有哪些事先在微信群里说定了，再补录系统」。这一问通常会得到真实答案，而那个答案就是这套系统真实的使用深度。
案例参观的核心不是「他们用了没有」，而是「他们用到什么程度」。系统上线不等于系统被使用，被使用不等于被依赖。
四、参数写成这样，等于锁死自己
招标文件里的技术参数，如果不小心写成了某一家产品的功能描述，其他家要么直接放弃，要么在中标后提出变更。两种结果对甲方都不利。
常见的锁死写法有三类：
- 把实现方式写成要求。比如「支持通过 XX 协议与 XX 系统对接」，如果这个协议只有一家支持，就等于指定了厂商。合理的写法是描述结果：需要与某系统实现单点登录和数据同步，具体方式由投标方提出；
- 把专有名词写进需求。某些厂商的产品模块有独特命名，写进需求就等于点名；
- 要求提供「某功能截图」作为响应证明。截图最容易定制，也最容易变成形式主义——真正该验证的是功能能不能在演示环境里跑起来。
反过来，参数写得太松也不行。「支持流程自定义」这句话，从拖拽式配置到必须写代码，全都算支持。合理的做法是加一句限定：「普通管理员经培训后可自行完成，无需开发介入」。这一句能把范围收得很实。
五、低价中标之后，钱从哪里省出来
这一点在评标时几乎不会被讨论，但它决定了项目两年后的样子。
一个 OA 项目的报价，通常包含三块：软件许可、实施服务、质保期内的运维。实施服务是按人天算的，而人天是最容易被压缩的部分——软件许可有成本底线，运维有合同约束，只有实施人天的弹性最大。
报价被压到很低时，压缩的通常不是利润，是实施投入的人天。表现出来是：需求调研做两天而不是两周、流程梳理让甲方自己写、培训做一场而不是分角色做三场、上线后的问题响应从一天变成三天。
这些都不违约，合同里通常也没写调研要做多少天。但体验上的差别巨大。
在招标文件里要求投标方按工作项报人天：需求调研多少天、流程配置多少天、集成开发多少天、培训多少天、上线支持多少天。
这样评标时能看出各家的投入假设是否合理，也能在合同里把这些数字固定下来。总价比不出来的时候，人天结构能比出很多东西。
六、选型的本质是选人
说了这么多技术细节，最后还是要回到一句很朴素的话：OA 这类项目，选的不是产品，是做这个项目的那几个人。
同一款产品，不同的实施团队做出来，可以是两套完全不同的系统。差别不在配置水平，在于实施顾问懂不懂业务——他能不能在你描述完一个流程之后，反问一句「那这个环节超时了怎么处理」，这一问就能看出他做过多少个类似项目。
所以如果只能加一条要求，我会加这条：投标文件里明确写出项目经理和实施顾问的姓名，并承诺实施期内不更换；确需更换须经甲方书面同意，且继任者资历不低于原人员。
这一条不增加任何成本，但能挡掉相当一部分「中标后临时组队」的情况。
关于本文：内容基于我们在政务与企业信息化项目中的实施经验，不涉及任何具体客户信息，也不含无法举证的量化结论。如果你正在做类似的事，欢迎就文中的判断标准与我们讨论。
常见问题
政企 OA 选型，技术分和价格分应该怎么分配？
没有通用比例，但有一个原则值得参考：技术分的区分度要落在能验证的项上（现场演示、真实数据测试、团队人员），而不是落在资质证书和案例数量上。后者是门槛项，够格的都是满分，放在评分表里只增加纸张不增加信息。
要求投标方提供真实数据演示，会不会没人来投？
通常不会，但需要在招标文件里提前写明并提供测试数据。规范的做法是在答疑阶段统一发放脱敏数据包，给各家同等的准备时间。这样既保证公平，也能筛掉那些连数据导入都不愿做的投标方。
案例参观怎么安排才有意义？
关键是脱离会议室。要求看点开的一线电脑、看真实的待办列表、问「有没有在系统外走流程」这类问题。安排充裕时间给一线员工单独交流，管理层在场时得到的答案往往不一样。
OA 项目报价差距很大，怎么判断哪个合理？
要求按工作项拆解人天，对比各家在需求调研、流程配置、集成开发、培训、上线支持上的投入假设。总价低但人天明显偏少的，通常意味着实施深度会被压缩。同时确认报价是否包含质保期内的运维和后续的流程调整支持。