多仓调拨项目最容易失败的时刻，往往不是系统上线当天，而是某个仓库明明显示有货，订单却仍然缺货；调出仓已经扣账，调入仓迟迟没有收货；月底盘点时，业务、仓库和财务各自拿着一套数字。要让库存管理系统真正管住多仓调拨，关键不是先配置“调拨单”，而是先把库存口径、调拨规则、在途责任和异常处理定义清楚，再用一组可验收的业务场景验证它们。

一、先讲核心结论：调拨落地的难点不在单据，在规则闭环

1. 系统上线不等于调拨流程已经跑通

我判断一个多仓调拨项目是否真正落地，不先看系统有没有调拨按钮，而看一笔货能不能从需求产生，一路追踪到调出、在途、签收、上架和差异关闭。单据能创建，只代表系统提供了一个入口；库存能准确流转、责任能明确交接、异常能找到处理人，才代表业务闭环成立。

实际实施中，团队常把“调拨”理解为一张仓库间的出入库单。但一笔跨仓货物流转至少涉及三个不同事实：调出仓何时失去可用库存，运输途中货物由谁负责，调入仓何时确认实物和账面数量一致。如果系统只记录首尾两端，中间的在途库存就会成为盲区。

我的核心判断是：先定义业务状态，再选择系统功能；先把异常跑通，再追求自动化。否则，自动化只是把未经确认的规则更快地执行一遍，错误扩散也会更快。

2. 把“落地”拆成可以验收的四件事

实施团队可以把项目验收拆成四个可观察结果：同一商品在不同系统中的编码与单位能对应；调拨规则有明确的触发条件和审批边界；货物在途时库存状态不会被重复承诺；发生短收、错发、破损或取消时，账、货、单据能够按规则收口。

这四项比“调拨效率提升”更适合做上线门槛。效率是业务结果，口径没统一之前很难公平比较；而流程状态、单据字段、权限和异常时限都可以在上线前逐条检查。

我通常会让业务负责人选一笔近期真实调拨，要求项目组在系统中还原它从申请到收货的全过程。若团队说不清某个状态何时变化、由谁确认、影响哪种库存，就不要急着扩大试点范围。

二、背景和真实场景：为什么“仓库有货”仍然会缺货

1. 一个常见的多仓业务画像

下面用一个情景模拟说明实施逻辑。设想一家经营工业耗材的企业，在华东、华南和华北设置三个仓库，约有4,000个有效商品编码。订单来自电商、销售和经销渠道，部分商品在多个仓储地点都有库存，另外一些长尾品只放在中心仓。这里的规模和后续数字都是为了讲清方法而设计的模拟数据，不代表任何真实客户的实施结果。

业务团队提出多仓调拨，是因为华南仓经常出现畅销品缺货，而华东仓账面上有库存。过去，销售人员先在群里询问，仓库人员导出表格确认，主管再判断是否能调。问题并非“没有货”，而是大家看到的“有货”定义不同：有人看账面数量，有人扣除已分配订单，有人还要减去质检冻结和安全库存。

如果华东仓账面有100件，其中20件已被订单占用、10件处于待检状态、20件是安全库存，那么可调数量就不一定是100件。没有统一口径时，系统自动选仓也可能选出“数量正确、实际不能发”的仓库。

2. 多仓调拨至少要同时回答五个问题

• 调什么：按商品编码、批次、效期、规格还是包装单位识别货物？
• 从哪里调：按距离、库存可用量、履约时效、调出仓保护线，还是综合成本排序？
• 调多少：按目标仓缺口、补货周期、最小运输量，还是一次性补到目标库存？
• 谁批准：小额高频调拨是否可自动通过，大额、紧急或跨法人调拨由谁审批？
• 何时算到货：承运交接、目标仓签收和完成上架，分别对应什么库存状态？

这五个问题没有标准答案，答案取决于经营模式。区域零售企业可能更关注门店不断货；制造业可能更关心批次、质量状态和生产齐套；电商企业则可能把订单承诺和发货截单时间放在优先位置。实施的专业性不在于套一个通用流程，而在于让规则与业务目标一致。

3. 库存状态必须能解释“能不能承诺”

“现存数量”与“可承诺数量”不是同一个概念。项目组至少要分清可用库存、已分配库存、冻结库存、待检库存、在途库存和报废或待处理库存。具体字段名称可以不同，但每种状态都应有进入条件、退出条件和操作权限。

例如，调出仓完成出库复核后，货物已经离开可拣货货位，却尚未被目标仓签收。若系统直接把这批数量记入目标仓可用库存，会产生虚拟库存；若调出仓仍保留可用数量，又可能被第二张订单重复占用。因此，更稳妥的做法是将其转入“在途”或等效状态，等目标仓按收货规则确认后，再转为目标仓可用库存。

这也是我不建议项目组一开始就讨论“系统能否一键调拨”的原因：如果库存状态没有定义，一键操作只是跳过了本应发生的判断。

三、拆解常见误区：看起来省事，往往把问题推到上线之后

1. 把调拨单当成完整流程

调拨单解决的是“要从一个地点移动到另一个地点”的记录问题，不自动解决拣货复核、物流交接、在途跟踪、收货差异和库存可用时点。若业务仅配置了调出单和调入单，调出仓出库后到目标仓确认前就可能出现状态空档。

更完整的过程至少需要区分申请、审批、已分配、待拣货、已出库、在途、部分收货、已收货、差异处理中和关闭等状态。并非每家企业都要把状态拆得一样细，但每个状态都必须能回答两个问题：现在货在哪里，下一步谁负责。

2. 把自动选仓当成规则设计

系统依据“最近仓”或“库存最多仓”自动推荐调出仓，听起来简单，却可能忽视调出仓自身的订单需求、安全库存、批次限制和运输成本。只按当前可用量排序，常见后果是区域仓被抽空，随后该仓不得不再从别处补回，形成来回调拨。

我会先把自动推荐拆成可解释的排序规则。例如，第一层先过滤商品状态、批次和仓库资质不符合的候选仓；第二层剔除调拨后低于保护线的仓库；第三层再按运输时效或综合成本排序。若业务不能解释系统为何选择某仓，就先保留人工确认，不要为了“自动化率”牺牲可控性。

3. 把“在途”视为一个备注字段

在途不是备注，而是有数量、责任人、预计到达时间和库存属性的业务状态。没有在途库存管理，仓库可能重复发货，客服可能把未签收的货承诺给客户，财务也可能无法解释两地账面数量暂时不相等。

企业还要明确在途起点和终点。常见选择是调出仓完成出库复核后进入在途，目标仓完成实物收货后退出在途；如果运输交接点有独立扫描或第三方物流回传，也可以再细分责任区间。关键不是状态数量越多越好，而是每次状态变化都有证据。

4. 把所有异常都交给线下沟通

短收一件、整箱破损、批次不符、途中退回、目标仓拒收、临时取消，这些不是极端例外，而是多仓运输中的常见边界场景。若系统没有对应的差异原因和处理路径，人员往往用备注、群聊或临时改单解决，月底再靠人工拼接事实。

异常机制不需要一开始就复杂，但至少要记录异常类型、发现环节、实收数量、责任归属、处理决定和关闭时间。对需要财务审核或质量判定的情况，系统应把处理责任交给对应岗位，而不是由仓库人员直接覆盖原始数量。

5. 把“数据看板”误当成系统集成

库存看板能帮助管理者发现仓间差异、在途积压和异常趋势，但看板本身不能替代库存交易系统。若上游业务数据没有稳定的编码、时间戳和单据状态，分析工具只会更快地汇总不一致的数据。

以九数云为例，更适合把它放在经营分析和过程监控的位置：在库存、订单和调拨数据来源明确、字段口径经过核对后，整合数据观察仓间库存、调拨时长或异常分布。它不应被写成自动承担仓库作业、库存记账或运输交接的替代系统。是否适用，要看企业现有系统能否提供稳定数据、业务是否需要跨系统分析，以及数据刷新频率能否满足管理决策。

四、专业判断逻辑：从业务规则到系统配置的实施顺序

1. 先盘清主数据，再讨论流程自动化

多仓项目中，商品和仓库主数据质量会直接影响调拨判断。项目组要核对商品编码是否唯一，基本单位与采购、销售、仓储单位之间是否有固定换算，条码是否对应正确包装层级，批次和效期是否强制采集，以及仓库、货主、组织和库存状态是否有一致定义。

我建议先抽取一批真实商品做“穿透核对”，而不是只检查字段是否非空。可以选择高频品、批次管理品、存在多包装规格的商品和历史差异商品，沿着采购入库、库存查询、调拨出库、目标仓收货和销售出库走一遍。能否从一个编码追踪到每个环节，比主数据表面完整率更有价值。

2. 把补货需求与调拨需求分开

调拨并不等于补货。补货回答“企业要从供应端增加多少库存”，调拨回答“现有库存应该在仓库之间如何重新分布”。若调拨频繁发生，是为了弥补采购预测偏差、区域库存参数不合理，还是订单网络设计有问题，应该在分析层面区分。

一个实用判断是：如果某仓持续向另一仓输送同一类商品，且方向长期固定，这可能不是临时调拨，而是仓网配置或补货策略有结构性问题。用调拨单解决短期缺口可以接受，但不能把长期仓网失衡永久包装成“灵活协同”。

3. 设定调拨规则时，优先可解释而非复杂

规则可以从简单版本开始：目标仓低于补货触发线时产生建议；调出仓扣除已分配和保护库存后仍有余量，才进入候选；候选仓按时效或成本排序；超过数量或金额阈值时走审批。试点阶段不必一上来就引入复杂预测模型，规则能被业务人员复核，比模型看起来先进更重要。

库存保护线应基于业务周期和风险，而不是凭空填一个百分比。至少要考虑日均需求、补货提前期、需求波动、供应中断风险和仓库之间的替代能力。即使企业暂时缺少高质量历史数据，也应把初始参数标记为试运行值，规定复核日期和责任人。

4. 把系统配置映射到流程责任

审批流不是为了增加控制感，而是为了让不同风险由合适的人承担。小额、常规、低风险调拨可以由系统按规则建议并由仓库执行；跨区域、大数量、突破安全库存、特殊批次或高价值商品则可能需要业务主管或供应链负责人确认。

配置前应逐步核对每个角色：谁提出需求，谁确认库存，谁审批，谁拣货，谁复核，谁交接运输，谁收货，谁处理差异。职责可以因企业规模合并，但系统权限不能因此变成所有人都能改数量、改状态。

5. 设计数据指标时，先定公式和时点

“调拨时长”有多种口径：申请到审批、审批到出库、出库到签收，或申请到目标仓上架。若不同团队使用不同的起止点，周期对比没有意义。调拨准确率也需要明确分母是调拨单数、商品行数还是数量；少发一件与整单错发是否按同一方式计数，都会改变结论。

五、具体案例拆解：三仓企业如何用小范围试点跑通闭环

1. 案例边界与问题定义

继续使用前述情景模拟：企业有华东、华南、华北三个仓，华南订单增长时会临时向华东调货。项目启动时，业务反馈是“调拨慢”，但把历史问题拆开后，发现至少有四类原因：调拨申请信息不完整；可用库存口径不统一；出库后运输节点不可见；目标仓收货差异靠线下处理。

由于这是假设性案例，以下方案和对比数字仅用于说明如何设计试点，不代表九数云或任何真实企业的客户成绩。真实项目中，应从原始单据、库存快照和时间戳计算基线，获得授权后再对外发布客户案例。

团队没有一次性覆盖全部商品，而是选了一个常调拨的商品组，挑选华东到华南这一条路线先做验证。这样做的好处是能把商品属性、运输线路、仓库协作和订单需求限定在可控范围内；坏处是不能据此推断所有仓、所有品类都能同样顺利上线。

2. 试点前先冻结口径和边界

试点前，项目组把“可调数量”定义为账面现存减去已分配订单、质量冻结和最低保护库存，并要求系统输出参与计算的明细。遇到批次管理商品时，不允许只按总量判断，还要核对批次状态和效期规则。

调拨申请需要注明目标仓、商品、需求数量、需求原因、期望到货时间和关联订单或补货计划。系统可以依据规则生成建议数量，但试点前期保留仓库和业务负责人复核，避免把规则错误直接自动执行。

流程状态则明确为：申请待确认、已批准、待拣货、已出库、运输在途、部分收货、已收货、差异处理中和关闭。每个状态都绑定操作角色和时间记录。状态并不是越细越好，只有当它能帮助定位责任或解释库存变化时，才值得保留。

3. 试点测试不只测正常路径

不少项目只测“申请，审批，出库，收货”的顺利路径，结果上线后遇到部分收货就停住。试点应覆盖至少一组正常流程和一组边界流程，尤其要验证库存是否被重复占用、在途数量是否可追踪、差异能否保持原始记录。

• 正常调拨：目标仓需求确认，调出仓可用量充足，按计划发货并足量收货。
• 部分收货：调拨数量与实收数量不一致，系统是否保留差异数量和待处理状态。
• 调出仓库存变化：申请后、拣货前出现新订单，系统是否重新校验可调数量。
• 重复申请：同一目标仓对同一商品重复提交时，能否提示已有未完成调拨。
• 运输超时：超过预期到货时间后，是否能识别长期在途并通知责任人。
• 取消与退回：出库前取消和出库后退回必须区分，不能用同一种撤销逻辑覆盖。
• 批次或效期差异：实物批次与单据不一致时，目标仓是否能够拒收或转入待判定状态。

4. 情景模拟数据：先看过程，再谈收益

为了展示如何复盘，假设试点前通过抽样记录得到以下基线：从申请到调出仓出库的中位时间为30小时；出库到目标仓签收的中位时间为32小时；有完整时间戳的调拨单占70%；试点目标设为把时间戳完整率提高到95%以上，并减少因库存口径不一致造成的退回处理。

假设试运行四周后，模拟测算的申请至出库中位时间降到14小时，运输签收中位时间为29小时，时间戳完整率达到96%，调拨行差异率从3.0%降到1.2%。这些数值只用于演示复盘写法，不应引用为公开的行业平均水平或真实项目业绩。

更重要的观察不是总时长下降了多少，而是变化发生在哪个环节。假设申请至出库明显缩短、运输时间变化不大，说明流程配置改善了需求确认和仓内执行，但无法证明承运效率也提高了。假设差异率下降，则还要排除商品组合变化、样本量不同或试点人员更熟悉流程等因素。

如果分析工具需要跨系统汇总申请、出库、运输和收货数据，先检查各系统单号映射、时区、时间戳定义和重复记录规则。九数云可作为数据分析的一种选择，用于将业务数据整理为可追溯的运营指标与趋势视图；是否接入，应由数据源质量、刷新频率、权限控制和分析需求共同决定。关于产品能力、接口方式和当前版本，应以其官方资料及实际演示验证为准，可从 九数云官网 了解相关信息。

5. 复盘时要保留反例和不确定性

一个可信的案例不只写改善，还要说明什么没有改善、为什么暂时无法判断。比如，若运输时长变化不明显，可能是承运商线路、发车班次或交接窗口限制，并非系统流程可以单独解决。若试点样本少，差异率变化可能受偶然波动影响，应延长观察周期，而不是立刻对外宣传效果。

还要检查有没有“改善一个指标、恶化另一个指标”的情况。审批变快可能增加错误调拨；增加保护库存可能降低调出仓缺货风险，却提高整体库存占用；提高调拨频率可能减少目标仓缺货，却增加运输和收货成本。只有同时观察服务、风险与成本，才能判断方案是否真的更优。

六、不同情况下的行动建议：按业务复杂度分层推进

1. 仓库少、交易量不高：先让人工判断有据可查

如果企业只有两三个仓，调拨量不大，第一阶段不必追求复杂自动分仓。先统一商品编码、库存状态和调拨单字段，让申请、审批、出库、收货和差异处理留痕。对人工决策保留解释空间，但要求写清调拨原因和目标仓需求。

这一阶段的目标不是降低到零人工，而是让人工工作可复核。管理者可以先通过固定报表观察各仓可用库存、未完成调拨、长期在途和收货差异，再决定哪些规则值得自动化。

2. 仓库多、订单密集：先做候选仓过滤，再做排序

当仓库数量增加、订单承诺时效变短时，人工逐仓确认会成为瓶颈。此时应先建立候选仓过滤条件：商品是否可在该仓储存，库存是否处于可用状态，扣除订单分配后是否高于保护线，批次和效期是否满足订单要求。

通过过滤之后，再讨论候选仓排序。排序可以参考预计到货时间、运输成本、当前库存压力、仓内处理能力和目标仓缺口，不建议只用一个简单的“最近仓”指标。自动推荐结果应保留可解释理由，业务人员才能判断系统有没有误选。

3. 批次、效期或质量要求高：先完成可追溯，再谈效率

食品、医药、化学品、关键零部件等对批次、效期或质量状态敏感的业务，调拨规则不能只按数量判断。应确认调出和收货环节是否采集批次、效期、质量状态及必要的追溯信息，目标仓能否拒收不符合条件的货物。

这类企业上线初期可以接受流程比普通商品更慢，但不能为了缩短处理时间允许无记录的替代批次。先把追溯链条跑通，再逐步优化审批和扫描动作。

4. 多系统并行：明确交易系统和分析系统的边界

企业可能同时使用ERP、仓储执行系统、订单系统、运输管理系统和数据分析平台。实施前要确定哪个系统是库存数量的权威来源，哪个系统负责仓内作业，哪个系统生成分析视图。相同库存字段在多个系统中重复维护，会让“谁的数据正确”变成日常争论。

数据分析平台适合帮助管理者发现趋势和异常，例如对比不同路线的调拨时长、查看长期在途分布、按商品组分析收货差异。但交易状态应由业务系统按照实际操作更新，不能依赖看板刷新来代表货物已出库或已收货。

5. 数据基础薄弱：缩小试点，不要先购买复杂功能

如果商品主数据重复、仓库编码不统一、历史单据缺少时间戳，优先处理基础数据和流程记录。可以先选少量商品、单一路线和有限角色试点，补齐关键字段后再扩大。系统功能再丰富，也无法可靠地从缺失信息中推导出真实库存状态。

如果企业尚未建立明确的库存责任人，也应先明确主数据维护、盘点差异处理和库存冻结权限。否则上线后每次差异都会演变成“业务说系统错、系统团队说数据错”的循环。

七、不同情况下的取舍：自动化、速度、成本与控制不能同时拉满

1. 自动化程度与异常可控性

自动化适合规则稳定、数据质量较高、异常类型可预测的场景。若商品和库存状态经常变化、仓库执行不一致，先用系统生成建议、由人员复核，通常比直接自动审批更稳妥。待连续运行一段时间，确认推荐规则可靠，再逐步扩大自动处理范围。

我更愿意把自动化设计成分级授权：低风险常规调拨自动通过；超过数量阈值、突破保护线或涉及特殊批次时转人工审批；系统无法判断的情况进入待确认队列。这样既减少重复劳动，也没有把不确定性藏起来。

2. 更低库存与更高履约弹性

跨仓共享库存可能减少某些仓库的冗余，但不等于全网库存必然下降。企业若为了快速响应而提高每个仓的备货量，可能增加总库存；若把库存集中到少数中心仓，则可能增加运输时间和调拨频次。是否优化，必须看全网库存占用、缺货表现、运输成本和服务水平，而不是只看某个仓的库存数字。

安全库存也不是越高越安全。较高保护线会降低调出仓因调拨而缺货的概率，却可能让其他仓长期看得到库存、实际无法调用。较低保护线则提高共享效率，但需要更可靠的需求预测和补货响应。参数应按商品重要性、需求波动和供货提前期分组管理。

3. 单据细分与操作负担

把流程拆得更细，有助于定位每次交接和状态变化，但也会增加扫描、确认和培训负担。若仓内没有稳定网络、人员流动高或扫描设备不足，过多节点可能导致补录、代操作和漏扫，最终记录质量反而下降。

最合理的颗粒度，是能支持责任划分、库存计算和问题定位的最小状态集合。先在试点中观察现场操作是否自然，哪些字段总被漏填，哪些状态无法提供新信息，再决定保留或合并。

4. 标准功能与定制开发

标准功能通常有利于控制实施周期和后续维护成本，但未必覆盖企业特殊的审批、批次和组织结算规则。定制开发可以贴合现状，却会增加测试、升级和交接成本。项目组应先问“这个差异是否影响业务控制或合规”，再决定是否开发，而不是把所有既有习惯都固化为系统逻辑。

若需求只是报表展示或跨系统趋势分析，先评估数据整合方案；若需求改变库存状态、库存归属或出入库交易，则必须在交易系统层面设计和验证。分析展示与交易控制的边界越清楚，后续维护越容易。

八、上线验收与长期运营：把例外变成持续改进的输入

1. 上线前用清单验收，不用口头确认代替

正式扩大范围前，项目经理可以要求业务、仓库、财务和系统团队共同签署验收结果。重点不在签字形式，而在每项规则都有负责人、测试证据和未通过处理方式。没有证据的“已经确认”，很容易在真实业务压力下被重新解释。

• 商品编码、仓库编码、单位换算和批次规则已经核对。
• 可用库存、已分配、冻结、待检和在途状态有统一定义。
• 调出仓过滤和排序规则能够被业务人员解释。
• 审批阈值、权限范围和紧急调拨流程经过测试。
• 正常调拨、部分收货、短收、错发、取消和超时场景已验证。
• 单据号、时间戳和关键字段能够跨系统关联。
• 培训材料覆盖实际操作与异常处理，不只展示标准路径。
• 上线后的异常联系人、响应时限和复盘周期已经确定。

2. 上线后按周期看三个层面的变化

第一层看执行：申请到出库、出库到签收、签收到上架分别花多久，超时集中在哪个节点。第二层看质量：收货差异、重复申请、长期在途和库存调整是否变化。第三层看经营结果：目标仓缺货、整体库存占用、紧急运输费用是否出现预期变化。

这三层不能混成一个“调拨效率”总分。执行更快但收货差异上升，说明流程速度可能以准确性为代价；差异下降但库存占用明显增加，则要检查保护线是否设得过高；目标仓缺货减少但紧急运输费增加，则要重新评估补货节奏。

3. 用异常复盘修正规则，而不是只追责

异常发生后，先保留原始单据和状态，不要直接覆盖数量或删除记录。再确认问题发生在哪个节点：需求判断错误、库存数据滞后、拣货复核遗漏、运输交接不清，还是目标仓收货标准不一致。只有找到流程原因，才能判断应调整系统规则、现场操作、培训还是承运安排。

对于频繁出现的异常，可以设定固定复盘周期，例如每周查看超时和差异，每月回看仓间库存分布与调拨成本。若某条路线长期高频往返，可能需要调整仓网或补货参数；若某类商品总因批次不符被拒收，则应先修正批次规则与供应端信息，而不是只要求仓库提高速度。

4. 给不同角色一张不同的管理视图

仓库人员需要看到待拣、待复核、在途和待收货任务；供应链负责人关注跨仓库存、调拨频次、超时和服务缺口；财务人员关心库存归属、单据链条和差异处理结果；系统团队需要监控接口失败、重复消息和字段缺失。把所有人塞进一个看板，常会让关键任务被无关信息淹没。

如果使用数据分析平台辅助复盘，应保留指标定义、过滤条件和数据更新时间。管理者不仅要能看到一个数字，还要能追溯它由哪些仓、商品、单据和时间范围构成。任何无法追溯来源的漂亮曲线，都不适合作为调拨策略调整的唯一依据。

九、总结：先让每一次交接可解释，再让调拨越来越自动

1. 下一步先做三个动作

多仓调拨真正落地，靠的不是一次性把所有功能打开，而是让库存口径、业务规则、单据状态和异常责任形成闭环。系统是承载规则的工具，流程是组织协作的约定，数据则是检验规则是否有效的证据。任何一环缺失，调拨都可能退回到群聊、表格和月底对账。

1. 抽取一笔真实调拨：从需求提出到目标仓上架逐步还原，标出每个状态的负责人、时间和库存变化。
2. 选一条可控路线做试点：优先选调拨频率高、商品规则清楚、仓库配合度较好的场景，同时覆盖部分收货和超时等异常。
3. 先定义指标再上线：统一申请至出库、在途时长、差异率和异常关闭时长的公式与统计边界，保存上线前基线。

2. 最重要的取舍判断

如果你的团队还无法解释“这批货现在算哪个仓的库存、由谁负责、何时可承诺”，就先不要追求全自动调拨。如果流程已经稳定、数据能追溯、异常能及时关闭，再逐步把低风险场景交给系统自动处理。

我对多仓调拨实施的最终判断很简单：好的系统不是让每一笔调拨都更快，而是让企业知道哪些调拨应该发生、哪些不应发生，以及发生偏差时如何及时止损。下一步不必从全仓上线开始，先拿一条路线、一组商品和一笔真实业务做穿透演练；跑通规则和异常，再扩大范围，通常比一次性追求“大而全”更可靠。

免费注册

咨询方案

扫码咨询方案