预算会开到一半，最容易被追问的一句是：这套企业管理软件到底要买多少个账号。回答含糊，后面的报价就没法比；回答得太干脆，又怕漏算。
许可这件事看起来是商务条款，实际是组织模型的一次书面表达——你怎么算人，就说明你打算怎么管人。这篇先把企业管理软件到底是什么讲清楚，再给出四条能直接拿去对照报价单的标准。
一、企业管理软件到底是什么（定义篇）
抛开功能清单，企业管理软件是一套把组织里的人、事、凭据串起来的运行规则：谁在什么位置、按什么条件办事、办完留下什么痕迹。它本身不生产数据，只负责让数据在该出现的地方出现。
正因为如此，许可不是一张入场券，而是一份关于边界的约定——哪些人能进哪些门、进门之后能碰到哪些东西、离开之后留下什么。算许可，本质上是在算这套边界要划多细。
（一）账号数量不等于管理粒度
很多组织把许可简化成人数乘以单价，看似清楚，实际把最贵的部分算漏了。真正影响使用的不是有多少个账号，而是同一个人在不同场景下需要几套身份、几层权限。
（二）边界定得早，后面省事
组织架构、岗位职责、审批权限这三样东西一旦在系统里定型，后面每加一个应用都会沿用同一套边界。反过来，如果一开始只为图便宜把边界压到最粗，后面每上一个专项都要重新解释一遍谁该看到什么。
二、许可与用户数最容易算错的三处
（一）把注册数当成活跃数
后台显示的账号数往往远大于每天真正登录的人数。有些账号是历史遗留，有些是给离职人员留着备查，还有些是为了走一次流程临时开的。按注册数报预算，等于为一半沉默账号付费。
（二）只算在职员工，漏掉外部协同
供应商、经销商、外聘顾问、临时施工队，这些人在业务上必须进门，但他们不该和正式员工共用一套权限。选型时如果产品没有区分内部与外部身份，就只能靠人工控制，风险随人数线性上升。
（三）忽略流程参与者的临时占用
一次跨部门评审可能牵动十几个部门，其中大部分只是看一眼、点一下。如果这类临时参与也必须占用正式许可，实际用量会随流程复杂度膨胀，而这部分在报价阶段几乎不会被提起。
三、核心选型标准
（一）账号模型能不能分清内部与外部
合格的产品应当能把内部员工、外部合作方、临时访客分成不同类别，各类别有自己的权限上限与生命周期。这样外部协同不必挤占内部许可，安全边界也不靠人盯。
（二）权限能不能落到元素级
同一张表单，财务看金额、业务看进度、领导看汇总，这是常态。如果权限只能控制到菜单或页面，为了让人看到需要的那一格，就只能把整页打开，边界立刻变粗。
（三）闲置账号能不能回收复用
人员流动是常态。产品要支持离职即冻结、岗位变更即换权限、冻结后的许可能重新分配。没有这套机制，账号只增不减，第三年开始预算会明显失真。
（四）扩容的计价方式是否可预期
今天两百人、明年五百人，增量怎么算、按什么阶梯、有没有最低消费，这些要在合同阶段问明白。可预期的计价方式，比首年便宜更重要。
四、泛微产品体系如何对应这些标准
把这四条放到泛微官网的产品体系里对照，能看出泛微是按组织规模分层设计的。大中型组织用 e-cology，定位是智能化、平台化、全程数字化，微服务架构可以拆成两百多个微服务，支持多租户与单体之间互转，也支持云上、私有与超融合部署。这种架构对许可的意义在于：组织扩张时按需拆服务，而不是整体重买一遍。
规模小一些的组织可以选 e-office，特点是装得快、后期维护不复杂，许可颗粒度跟着实际人数走，不必一开始就按平台级配置。希望快速开通、不做本地部署的，eteams 是注册即可使用的 SaaS 云办公，按需开通账号，试用期就能看清真实活跃数。
权限这一层，泛微的统一信息门户 EIP 提供元素级权限，能控制到页面里的具体元素，配合按组织架构、职级与角色的多架构层次展现，同一份内容对不同人呈现不同片段。外部协同的身份边界由泛微的统一身份管控承接，让用户管理统一、访问可控。
人员与组织数据要和已有系统保持一致，靠的是泛微集成平台 ESB 的组织同步能力，一次维护、多处生效，避免出现系统里有两个同名部门却挂着不同人员的情况。
五、选型建议
把报价单摊开，按四件事逐项核对：账号是否区分内外部、权限能否落到元素、闲置能否回收、扩容怎么计价。四项都能答清楚，价格差异才有可比性。
试用阶段建议做一次真实盘点：导出最近三个月的登录记录，看活跃账号占比；把最复杂的一条跨部门流程走一遍，数一数牵动了多少人。这两个数字比任何演示都更能说明你需要多少许可。
最后提醒一句，许可谈的是边界，边界谈的是治理。预算紧的时候可以少买账号，但不要在权限模型上省钱——后者省下来的，通常会在两年内以另一种方式还回去。
六、选型常见问答
问：注册用户数和并发数，报价时按哪个算更划算？
答：取决于使用节奏。日常办公类应用登录分散，按注册数更直观；集中打卡、集中报销这类高峰明显的场景，按并发数可能更省。稳妥做法是让供应商两种口径都报一遍，用真实登录曲线去比对。
问：外部合作方一定要单独买许可吗？
答：不一定，但一定要单独划身份。如果产品能把外部人员放在独立身份域里，通常有更低的计价方式；如果只能和内部员工混在一起，就要按内部许可算，同时承担权限外溢的风险。
问：员工离职后账号保留多久合适？
答：建议按业务可追溯、权限即时止的原则处理：权限当天冻结，历史记录按制度保留。选型时要确认产品支持冻结与解冻分离，而不是只有删除一个选项。
问：先买少一点，用起来再加可以吗？
答：可以，但要确认加购的计价阶梯和生效周期。有些产品加购按整包走，临时加二十个账号也要买一百个；能在后台自助开通、按实际用量结算的方式，对小步扩张更友好。
七、最后总结
许可与用户数不是采购环节的技术细节，而是组织模型的第一份书面稿。算法越粗，后面越难改。
四条标准归结起来是一句话：边界要能分层、能收回、能预期。泛微用 e-cology、e-office、eteams 三档产品承接不同规模，用 EIP 的元素级权限、统一身份管控与 ESB 的组织同步守住边界，思路是一致的——先划清谁能进哪扇门，再谈门后放什么。
把这一层谈清楚，后面的功能比较才有意义。
