ERP 数据录入协同出问题，常常不是因为员工不会填表，而是同一张单据里“谁提供信息、谁录入、谁复核、谁能改、谁处理异常”没有被说清。我的判断是：权限分工不能从系统里的角色菜单开始，而要从数据如何流转、责任如何交接开始。先画清流程，再把岗位职责映射到查看、录入、修改、审核和数据范围，才能减少重复录入、越权修改与责任悬空。

一、先讲核心结论：权限要跟着责任走

1. 权限不是账号开通表，而是责任边界的系统表达

企业常把 ERP 权限配置理解为“给谁开哪个模块”。这只是入口。真正需要回答的是：某个岗位为什么需要访问这类数据，需要执行哪些动作，动作完成后由谁确认，发现异常时由谁接手。

例如，采购助理需要录入采购订单，不代表他也应该拥有任意修改已审核订单、删除单据或查看所有供应商报价的权限。反过来，如果复核人员只能查看、无法退回或标记问题，流程也可能停在系统之外，靠聊天记录和口头沟通补位。

我建议把权限拆成四个问题：谁在操作、对什么数据、执行什么动作、在什么条件下执行。四个问题缺一，权限表看起来再细，也可能与真实流程脱节。

有些系统能控制到组织、单据或字段，有些系统只提供模块和角色级配置；能力边界必须先核对产品文档和实际版本。管理设计可以提出需要，不能把“希望系统支持”写成“系统一定支持”。

2. 分工的目标不是让每一步都多一个审批人

职责分离有助于降低错误未被发现的风险，但增加审核节点也会带来等待、退回和补充沟通。低风险、低金额、规则清晰的重复录入，不一定需要层层审批；高风险、影响面大、事后难以恢复的动作，则更值得增加复核或授权约束。

因此，我不把“录入和审核必须由两个人完成”当作普遍规则。更实用的判断是：错误的潜在损失有多大、能否在下游及时发现、能否撤回或修正、团队有没有足够人手承担分离职责。风险高而人手有限时，可以通过抽检、金额阈值、日志复核等方式弥补，而不是机械地增加岗位。

3. 最小必要权限不等于权限越碎越安全

最小必要权限的核心，是员工获得完成岗位任务所需的访问与操作范围。它不是把每一个按钮都拆给一个人，也不是要求所有企业都配置字段级权限。过度细分会让角色数量膨胀，岗位调整后难以维护，临时替岗时还可能诱发共享账号或线下绕流程。

配置质量要同时看风险控制和可维护性。权限能否解释清楚、员工能否按它完成任务、人员变化后能否及时更新，比角色名称听起来多专业更重要。

二、背景和真实场景：数据录入为什么会变成协同难题

1. 一条业务数据通常经过多人，而不是只经过录入员

以采购订单为例，需求部门先提出采购需求，采购人员确认供应商与交付条件，录入人员把信息转成系统单据，主管可能检查价格或预算，仓库人员根据订单收货，财务人员再核对发票和应付信息。ERP 记录只是这条业务链上的一个节点。

如果需求部门用表格提供商品名称，采购人员另有一份供应商报价，录入员再从聊天记录里补交付日期，那么错误可能发生在任何一次信息转交中。只给 ERP 录入员一个账号，并不能解决源头数据不完整、字段含义不一致或审批条件模糊的问题。

我会先追问三个问题：数据从哪里来？录入前由谁确认它完整？提交后谁有权改变它？这几个问题的答案，通常比“系统里有哪些角色”更能暴露协同断点。

2. 权限冲突往往出现在单据状态变化之后

草稿阶段允许录入员改数量，可能是合理的；单据审核后，数量变化却可能影响预算、库存计划或供应商交付。若同一操作权限在所有状态下都开放，系统就把“补录一个拼写错误”和“改变已承诺的采购数量”当成了同一种动作。

因此，权限设计不能只看“能不能编辑”，还要看单据当前状态、修改内容的影响以及是否需要重新审核。若系统不支持状态级控制，企业也要明确替代办法，例如限制审核后直接修改、通过变更单处理，或者由授权人员留痕操作。

3. 业务团队会用线下方式填补系统缺口

当员工发现没有权限完成必要任务，常见做法是把账号借给同事、把数据发给管理员代录，或者先在表格里维护、月底再集中导入。这些做法看起来让工作继续了，代价却是操作身份不清、版本分叉、异常难追踪。

如果某个岗位经常需要“请管理员帮忙改一下”，我不会马上把它判断为员工不守流程。更好的做法是追查：这是偶发例外、岗位职责变化，还是权限模型漏掉了真实工作？频繁绕行通常是流程设计的诊断信号。

4. 先识别数据链，再决定权限颗粒度

可把数据链粗分为准备、录入、校验、审核、使用和更正六个阶段。每个阶段都要找到输入方、责任方和交接条件。这样做的价值在于，不会把“录入”误当成一项孤立动作，也能发现某些关键工作其实发生在系统外。

例如，商品主数据由谁创建、谁维护计量单位、谁确认停用商品，都会影响订单录入质量。如果主数据维护没有责任人，再严格的订单权限也挡不住同一商品出现多个名称或规格。

三、常见误区：看起来有权限，实际却没有管好责任

1. 误区一：管理员、录入员、审核员三个角色就够了

角色名称只是标签，不能自动说明责任边界。“录入员”可能录入订单、维护供应商、修改价格，也可能只负责某一个仓库的数据；“审核员”可能只看金额，也可能负责业务真实性和预算合规。角色名相同，实际动作和风险范围可能完全不同。

解决办法不是不断增加角色名称，而是把每个角色的工作对象、动作和范围写出来。若两个部门都叫“录入员”，但一个处理华东仓采购、另一个处理华南仓采购，可以用数据范围或不同角色组合区分，具体能否在系统中实现要以实际产品能力为准。

2. 误区二：只要有审批流，职责就清楚了

审批流能记录某些节点的提交与确认，但不一定涵盖数据准备、录入校验、驳回后的修订、临时授权和已审核单据的更改。流程图中有审批人，不意味着审批人知道自己需要核对什么。

审批节点应配套审核要点。例如采购主管关注预算、供应商与价格依据，仓库关注实收数量，财务关注票据与结算字段。没有审核标准时，审批容易退化为“点通过”，审批数量增加，却没有明显增加控制效果。

3. 误区三：录入和审核分开，错误就会减少

分岗能减少同一人录入并自我确认的情况，但不代表一定改善质量。如果录入来源本身不可靠，审核人只按录入员提供的信息复核；如果审核人没有业务依据，双人操作也可能只是重复输入同一个错误。

更值得关注的是控制点是否有独立信息源。例如核对采购价格时，复核者是否能看到已批准的报价或合同；核对收货数量时，数据是否来自实际点收。有独立依据的复核，比单纯多一个签字更有效。

4. 误区四：所有人都只给最小权限，系统自然安全

如果一线岗位没有足够权限完成日常工作，员工可能频繁找管理员代办。管理员为了让业务快速推进，可能长期保留高权限；表面上普通账号受限，实际上关键操作集中到少数共享或代操作账户，审计反而更困难。

因此，最小权限需要和任务设计一起落实。应先确保正常工作路径完整，再限制超出职责范围的操作。权限不足导致线下绕行时，应该复核岗位设计、系统限制和授权流程，而不是只提醒员工“不要违规”。

5. 误区五：审计日志存在，就一定追得回责任

日志是否记录用户、时间、对象、字段变化、变更前后值，取决于系统功能与配置。某些系统只记录登录或单据状态，并不一定记录每个字段的历史变化。账号共享、管理员代操作、批量导入也会降低日志对责任判断的帮助。

上线前要通过真实操作验证日志，而不是只在功能说明里看到“支持日志”。建议模拟一条单据：创建、修改、提交、退回、再次修改、撤销，检查系统能否回答“谁在什么时间改了什么，为什么改”。如果无法回答，便需要补充审批记录、业务附件或人工控制。

6. 误区六：权限越细，风险越低

权限切得过细，维护成本会随员工、组织和业务变化持续累积。岗位每调整一次，都可能涉及角色、数据范围、审批人和临时授权的同步修改。如果没有清晰的权限责任人，精细配置可能迅速变成没人敢动的“配置遗产”。

比较稳妥的起点是先控制高风险动作和敏感数据，再观察一线工作是否需要更细粒度。对风险较低的通用查看权限，未必值得拆成大量例外；对删除、批量导入、审核后修改等动作，则通常值得认真评估。

四、专业判断逻辑：怎样把业务责任翻译成权限配置

1. 第一步：列出数据对象，不从部门名单开始

先列出业务中真正被创建、修改和使用的数据对象，例如供应商档案、商品资料、采购申请、采购订单、收货单、发票记录。一个部门可能操作多个对象，同一个对象也可能由多个部门在不同阶段处理。

对象清单可以避免“采购部有采购权限”这种过于笼统的设计。供应商档案可能由主数据岗位维护，订单由采购人员录入，收货由仓库确认，三者虽然属于同一条采购链，风险和责任并不相同。

2. 第二步：把操作动作拆开

对每个对象逐一确认查看、创建、修改、提交、审核、退回、撤销、删除、导出和批量导入等动作。不要假设系统把这些动作分别控制，也不要默认每个动作都能独立配置。先定义业务需要，再核对系统能否映射。

其中，删除和撤销尤其需要区分。删除可能让数据不可见或不可恢复；撤销可能保留单据及操作轨迹，但会改变业务状态。系统叫法不同，实际效果也可能不同，必须通过产品文档或测试环境确认。

3. 第三步：明确数据范围与边界

数据范围可以按组织、地区、仓库、项目、客户、供应商或负责业务线划分。范围不一定越细越好，关键是它是否对应真实管理责任。例如仓库人员需要查看本仓相关收货任务，不一定需要看到所有仓库的全部库存调整记录。

要特别检查跨组织协作场景：员工临时支援其他区域、主管代班、总部集中审核、集团共享主数据。若常态工作依赖临时扩权，应把支援规则写进流程，明确审批人、授权范围、有效期限和收回方式。

4. 第四步：按风险评估是否需要复核

我通常从五个问题评估风险：一是错误会造成多大损失；二是错误能否被下游发现；三是能否低成本恢复；四是数据是否涉及资金、客户或合规责任；五是团队规模是否支持职责分离。回答越偏向高影响、难发现、难恢复，就越有理由设置独立复核或限制修改。

5. 第五步：把异常处理纳入主流程

流程设计常只描述正常路径，却把更正、退回、补录、重复单据、人员代岗当作例外。实际运行中，这些情况并不少见。一个可执行的权限方案必须说明异常由谁发起、谁判断原因、谁批准修改、修改后是否重新审核。

例如订单审核后发现交付日期录错，处理方式可能是由原录入员申请变更、采购主管确认、系统保留前后值；如果只是管理员直接覆盖，虽然问题修好了，业务责任却可能无法复原。具体实现方式要结合 ERP 是否支持版本记录、变更单或审批状态。

6. 第六步：把岗位职责落成权限矩阵

权限矩阵不是一张填完就永远有效的表。它是业务负责人、流程负责人和系统管理员共同确认的映射工具。业务负责人判断“谁应该负责”，流程负责人确认“前后环节如何衔接”，系统管理员核实“现有产品怎样实现”。

建议至少保留岗位、数据对象、操作动作、数据范围、审核责任、异常处理方式、系统实现方式和复核日期等字段。若某项业务控制只能靠线下制度实现，也应标注出来，避免误以为系统已自动控制。

7. 用“能否解释一次修改”检验权限设计

我会用一个简单的检验题：如果某张已审核订单的数量被改了，企业能否在合理时间内说明原值、现值、修改人、修改时间、修改原因、批准人及后续影响？如果只能查到当前数值，或者只能看到管理员账号做过修改，权限和留痕设计就还不够。

这项检验不要求所有企业使用复杂审计平台。小团队可以通过变更申请、必要附件和定期抽检建立基本追溯；业务规模扩大或风险提高后，再评估系统日志、版本留存和自动告警能力。

五、情景案例与数据观察：一张采购订单怎样被设计得可追溯

1. 先说明案例边界：这是流程推演，不是企业实测数据

以下以一个情景模拟团队为例：企业每月处理约200张采购订单，团队有需求部门、采购录入、采购主管、仓库和财务等岗位。这个规模与数据用于说明设计方法，不代表真实客户样本，也不能据此推断某种权限方案一定能带来固定比例的效率提升。

在没有现场数据时，最有价值的不是编造“上线后错误率下降多少”，而是把问题定义成可测量的过程指标：重复录入多少次、审核退回多少张、审核后变更多少次、管理员代操作多少次、异常从发现到关闭用了多久。

2. 先找到问题发生在哪个交接点

假设团队发现订单常因交付日期、计量单位或供应商信息不一致而退回。第一步不是扩大审核权限，而是记录每类退回的来源：需求信息缺失、主数据错误、录入遗漏、报价来源不一致，还是审核标准不同。不同原因对应不同控制动作。

如果大多数问题来自需求表字段不全，应改进需求提交模板或前置校验；如果问题来自商品单位混乱，应治理主数据；如果常在审核后改单，应定义状态变更流程。把所有问题都归结成“录入员不仔细”，会让真正的上游原因继续存在。

3. 用基线观察验证控制点，而不是只看审批数量

下表展示一组用于方案评估的模拟基线。它不是统计结论，也不是对任何企业的承诺。实施时应以企业自己的系统记录和抽样核对为准，并明确统计周期、单据范围和指标口径。

这些数字的作用是示范指标设计，不是行业平均值。企业建立基线时，最好先连续记录一个可比周期，再按问题类型拆分；若业务有明显季节性，还要避免拿淡季与旺季直接对比。

4. 先做小范围试点，再检查“权限是否阻碍业务”

对采购订单这类常见流程，可以先选一个部门或仓库试行权限矩阵。试点期间既观察控制效果，也观察正常任务是否被卡住。若审核退回下降，但管理员代操作暴增，说明控制可能只是把工作转移到了管理员手中，并没有真正形成可持续分工。

建议把试点观察分成三组：质量指标看退回、错录和审核后变更；效率指标看单据从提交到审核完成的时间；治理指标看代操作、共享账号和临时授权是否按期回收。三组指标要一起看，避免只优化速度或只追求严格。

5. 复核数据质量时，别把“系统里有记录”当成“记录正确”

系统数据能提供操作时间、状态和字段内容，但字段值正确与否仍要对照业务凭据。比如供应商名称正确，不代表合同主体正确；订单数量与申请数量一致，也不代表需求本身合理。权限治理可以提高责任可见度，却不能替代业务判断和数据源核验。

抽样复核应事先确定样本范围和判定规则。可以按高金额、审核后变更、临时授权、批量导入等风险信号抽查，而不是只抽“看起来正常”的单据。结果要记录问题类型、发现环节和改进措施，避免把一次抽检变成单纯追责。

六、不同情况下的行动建议：从盘点到上线复核

1. 如果企业还没有明确流程，先画责任链，不要先建几十个角色

流程不清时，先选一类高频数据，例如采购订单、销售订单或库存调整，沿着数据来源到最终使用画出交接链。把每个节点的输入、输出、责任人、退回条件和异常处理写出来，确认部门之间对“谁负责确认”理解一致，再进入系统权限设计。

此阶段不必急着追求复杂配置。先解决职责重复、没人接手和线下绕行三类问题，往往比一开始精细到每个字段更有价值。若不同部门对同一字段含义存在争议，先统一业务定义，再配置权限。

2. 如果业务量不大、团队人数少，重点放在高风险动作与追溯

小团队可能无法让录入、复核、审核各由不同的人承担。此时可以按风险设置抽检、主管复核或金额阈值，并限制删除、批量导入、审核后修改等高影响操作。关键不是假装实现了完全职责分离，而是诚实识别单人兼岗带来的风险并设计补偿控制。

共享账号尤其不适合作为解决人手不足的办法。确有临时支援时，应尽量使用个人账号并记录授权范围；若系统无法支持临时授权，至少要在操作记录或审批单中保留执行人、授权人、原因和处理时间。

3. 如果是多仓、多组织或多业务线，先治理数据范围

组织复杂时，常见问题不是“谁能录入”，而是“能录入哪一块数据”。建议先明确组织、仓库、业务线和人员负责范围之间的对应关系，再检查系统能否按这些维度限制查看和操作。

跨区域代班、总部集中审核和共享主数据要单独设计。不要因为少数人需要看全局，就给整个团队开放全局数据；也不要为了数据隔离，让跨组织协作只能依赖导出表格。应区分常态职责与临时支援，分别配置稳定权限和例外机制。

4. 如果审核后常改数据，先追原因再收紧权限

审核后变更频繁，可能是前置数据不完整、审核标准不明确、业务条件变化，也可能是系统没有提供合适的变更路径。直接锁死修改权限，可能让真实纠错变成线下沟通；完全开放修改，则会削弱已审核状态的意义。

建议把变更原因分类，并区分录入差错、业务变化、主数据问题和紧急处置。不同原因对应不同批准人和留痕要求。若系统支持版本或变更单，可以验证其记录完整性；若不支持，就要评估人工变更记录是否足够可靠。

5. 如果经常需要管理员代录，先判断是权限缺口还是职责错配

管理员代操作可能是合理的运维任务，也可能是流程缺陷。连续记录一段时间的代操作内容，按操作类型、申请岗位、发生原因和重复频率分类，才能判断是需要补一个岗位权限、优化表单，还是管理员承担了本该由业务部门完成的确认。

系统管理员应尽量承担账号、配置、故障与技术支持职责，不应默认替业务岗位承担数据准确性责任。若确实需要代操作，应留下业务授权依据，并区分“技术上代为执行”和“业务上确认内容正确”这两种责任。

6. 如果准备换系统或上线新模块，先验证权限模型再迁移流程

选型或上线阶段，应拿真实业务场景做权限测试，而不是只看销售演示里的角色管理页面。至少验证：角色能否组合、数据范围能否限制、审核后能否控制变更、日志记录到什么粒度、临时授权如何处理、离职或调岗后如何收回权限。

如果关键控制必须依赖外部表格或人工提醒，应把它视为系统边界和运维成本，纳入评估。不要只比较功能清单，还要比较配置复杂度、管理员依赖程度、日常复核工作和异常处理是否可执行。

7. 上线后要把权限复核纳入人员与流程变更

权限不是一次性项目。人员入职、调岗、离职，组织调整，新增仓库或业务线，都是重新检查职责映射的触发点。企业可按自身风险设定复核节奏，也可以对高风险权限采用更频繁的检查；不宜无依据地宣称存在适用于所有公司的统一复核周期。

复核时不只看“账号是否还在”，还要看账号对应的岗位是否改变、数据范围是否仍然合理、是否保留长期未使用权限、临时授权是否过期、审批人是否已离岗。复核结果要有负责人和处理状态，否则盘点表容易只留下记录，没有实际整改。

1. 导出或整理当前用户、角色、权限和数据范围清单。
2. 让业务负责人确认每个岗位当前承担的真实工作。
3. 标记高风险动作、跨组织权限、管理员代操作和长期未使用权限。
4. 确认差异后由业务负责人提出调整，系统管理员执行并记录。
5. 用代表性账号复测正常任务和异常路径，确认没有误封关键工作。

七、不同方案的取舍：控制强度、维护成本与业务速度

1. 方案一：按模块给权限，适合起步，但边界较粗

按模块授权的优点是上手快、角色容易理解，适用于人员少、业务简单、系统刚上线的阶段。短板是同一模块中查看、修改、审核等动作可能难以区分，跨部门数据也容易出现过度开放。

如果企业规模小、风险较低，可以先采用模块级权限，但应优先关注删除、批量导出、审核和审核后修改等动作，并通过业务制度补足系统无法细分的部分。随着业务复杂度增加，再按岗位或数据范围拆分。

2. 方案二：岗位角色加数据范围，适合职责稳定的团队

岗位角色能把常见任务归类，数据范围能区分不同组织或业务线，二者结合通常比单纯按模块授权更贴近实际协作。适用前提是岗位职责相对稳定，人员能够明确归属，系统也支持相应范围控制。

代价是角色和范围需要随组织变化持续维护。如果员工一人兼任多个岗位、跨组织支援频繁，就可能出现组合复杂、授权难复核的问题。此时应先简化岗位模型，再决定是否把例外做成临时授权。

3. 方案三：按状态和动作控制，适合审核后变更影响较大的业务

状态控制可以区分草稿、待审、已审核、已执行等阶段，动作控制则限制每个阶段可做什么。对于采购承诺、库存调整、价格变更等影响较大的流程，这种设计有助于把“可以录入”和“可以改已审核数据”分开。

它的维护与测试成本相对更高，也需要业务状态定义清晰。如果员工无法理解单据为何锁定、怎样申请更正，系统会促使他们转向线下。配置前要把正常路径和异常路径都测试一遍，并为紧急业务保留有审计的处理方式。

4. 方案四：全部精细到字段，只有明确风险差异时才值得做

字段级权限适用于确实存在敏感字段、岗位职责差异明显且系统支持成熟的场景。但如果只是为了追求“颗粒度更细”，可能导致权限规则难以解释，表单升级和岗位调整时的维护成本也更高。

判断是否需要字段级权限，可以问：这个字段泄露或被误改会造成什么后果？是否能用数据范围、流程审核或脱敏查看达到相近控制效果？系统是否能留下足够审计记录？只有风险收益足以覆盖维护成本时，精细授权才有必要。

5. 不要用“控制更严”掩盖总成本上升

评价权限方案时，除了误操作风险，还要计算维护与协作成本：管理员处理授权花多少时间、员工等待授权多久、业务绕行多少次、权限复核是否能按计划完成。若方案减少了风险，却让所有日常单据都排队审批，它未必是整体更优的方案。

同样，追求速度也不能把控制责任留给事后追责。更合理的做法是按风险分层：低风险操作尽量自动校验或抽检，高风险操作增加授权和复核，特殊例外保留可追溯的快速通道。取舍依据应来自企业自己的业务损失和处理能力，而不是照抄别人的角色模板。

八、权限上线前检查清单与下一步行动

1. 用五个问题检查职责是否闭环

• 数据从哪里来：每个关键字段是否有明确来源，录入人员是否需要自行推断？
• 谁确认完整：提交前由谁检查必要信息，缺失时退回给谁？
• 谁能做什么：查看、创建、修改、审核、撤销和删除是否被区分？
• 谁能处理哪些数据：组织、仓库、业务线等范围是否与岗位责任一致？
• 出错后怎么追溯：是否能确认修改人、时间、前后值、原因和批准责任？

只要其中一项没有明确答案，就先不要把权限表当成最终方案。特别是“谁确认完整”和“出错后怎么追溯”，往往在系统配置讨论中被忽略，却直接决定数据质量能否持续管理。

2. 用一轮小测试确认系统能力和岗位可用性

上线前至少选取一个代表性岗位，测试从创建单据到审核、退回、更正、撤销的完整路径。既用正常账号测试，也用不应拥有权限的账号测试；既检查按钮是否出现，也检查通过接口、导入或其他入口是否能绕过限制。

测试结果要区分三类：系统已支持并验证、系统不支持但可用流程控制补足、目前没有可靠控制。最后一类要由业务负责人决定接受风险、改流程还是更换实现方式，不能默认交给管理员临时处理。

3. 形成可维护的权限台账

权限台账不必一开始做得复杂，但要能说明每种权限的业务理由和责任人。建议记录岗位、人员、数据范围、操作动作、批准人、授权起止条件、最近复核时间和变更原因。临时授权到期后应有回收确认，而不是只在申请时写一个日期。

如果企业员工数量较少，可以用受控表格维护；如果人员、组织和权限组合很多，再评估系统报表或自动化审计能力。工具形式不是重点，关键是台账与系统配置一致，并有明确的人负责修正差异。

4. 发现异常时，先区分配置错误与流程错误

员工无法完成任务，可能是权限缺失，也可能是岗位责任没有定义；错误数据可能是录入问题，也可能是主数据或上游申请的问题。处理时应先还原数据来源与操作路径，再决定改权限、改流程、补培训还是治理数据标准。

如果每次问题都靠给员工加权限解决，权限范围会不断扩大；如果每次问题都归咎于员工，则真正的流程断点会被忽略。建议把异常关闭时的根因分类和改进责任一起记录，定期检查重复问题是否下降。

5. 下一步：先挑一类单据做一张可验证的矩阵

不必一口气重做整个 ERP 权限体系。先选一类高频或高风险数据，梳理它的来源、状态、岗位、操作动作和数据范围；再与系统管理员核对功能边界，形成权限矩阵；最后用真实账号完成正向和反向测试。

我的核心判断是：权限分工不是把人分成更多角色，而是让每一次关键数据动作都能对应到明确责任，并且在业务变化后仍可解释、可复核、可维护。从一张单据、一条流程开始，把“谁能录、谁能改、谁来确认、异常找谁”写清楚，再逐步扩大范围，通常比先追求一套看起来完备的权限体系更稳妥。

免费注册

咨询方案

扫码咨询方案