InfiniSynapse
What is demand planning software?什么是需求计划软件？
Demand planning software is a system for creating, reviewing, reconciling, and governing demand forecasts and plans across products, locations, customers, channels, and time periods. Depending on scope, it may support statistical forecasting, hierarchy planning, overrides, scenarios, collaboration, versions, exceptions, approvals, and downstream integration.
需求计划软件是一类用于跨产品、地点、客户、渠道和期间创建、审查、协调并治理需求预测与计划的系统。根据产品范围不同，它可能支持统计预测、层级规划、人工调整、场景、协作、版本、异常、审批及下游集成。
The category has no perfectly uniform boundary. Some products are forecasting engines with a planner interface. Others are modules inside ERP or integrated business planning suites. Some extend into inventory, supply, replenishment, sales and operations planning, or financial planning. Buyers should evaluate documented workflows and proof-of-concept behavior rather than assuming that the label guarantees a specific capability.
这一类别没有完全统一的边界。有些产品是带计划人员界面的预测引擎，有些是 ERP 或集成业务计划套件中的模块，还有些延伸到库存、供应、补货、销售与运营计划或财务计划。买方应评估书面工作流和 POC 行为，而不能假定产品名称天然代表某项能力。
Demand forecasting is an analytical input: an estimate of future demand under stated assumptions. Demand planning is the broader decision process that reviews that estimate, incorporates commercial intelligence and policy, resolves disagreements, records overrides, and publishes an accountable plan. The planned demand forecasting guide should remain a separate page when deployed because its search intent focuses on methods and prediction, not software selection.
需求预测是一项分析输入，即在给定假设下对未来需求的估计。需求计划则是更广泛的决策过程，包括审查预测、加入商业情报与政策、解决分歧、记录调整并发布责任明确的计划。计划中的需求预测指南部署后应保持独立，因为其搜索意图侧重方法和预测，而非软件选型。
When is dedicated demand planning software justified?何时值得采用专业需求计划软件？
Software is justified by decision complexity and process risk, not by SKU count alone. A controlled spreadsheet may be sufficient for a small team with few stable series, one owner, limited hierarchy, and a short review process. Replacing it too early can add configuration and maintenance without changing decisions.
是否需要软件取决于决策复杂度和流程风险，而不只是 SKU 数量。对于序列少且稳定、责任人单一、层级简单、审查流程较短的小团队，受控表格可能已经足够。过早替换只会增加配置和维护，却未必改变决策。
Conflicting versions, repeated manual consolidation, formulas breaking silently, weak approval history, slow monthly cycles, no baseline comparison, poor exception prioritization, or plans that cannot be traced to inputs and assumptions.
版本冲突、反复人工汇总、公式静默损坏、审批历史薄弱、月度周期缓慢、缺少基线比较、异常无法排序，或计划无法追溯到输入与假设。
Undefined ownership, inconsistent product and location masters, unclear demand history, no agreed planning grain, incentives that reward biased forecasts, and no process for commercial overrides.
责任不清、产品与地点主数据不一致、需求历史口径模糊、规划粒度未统一、激励机制鼓励偏置预测，以及缺少商业调整流程。
Write a problem statement before an RFP: which decisions are late or unreliable, who makes them, which data is missing, what business consequence occurs, and what measurable change would justify the investment. “Use AI” or “improve visibility” is not an acceptance criterion.
发布 RFP 前应写清问题：哪些决策延迟或不可靠、由谁负责、缺少什么数据、造成什么业务后果，以及什么可测变化足以证明投资合理。“使用 AI”或“提高可视性”不能作为验收标准。
Spreadsheet, ERP module, planning suite, or analytics layer?表格、ERP 模块、计划套件还是分析层？
| Option方案 | Useful when适用情况 | Typical tradeoffs to test需要验证的权衡 |
|---|---|---|
| Controlled spreadsheet受控表格 | Scope is small, process is stable, owners are clear, and flexibility matters more than automation.范围小、流程稳定、责任清晰，灵活性比自动化更重要。 | Version control, audit trail, hierarchy scaling, formula risk, security, and manual refresh effort.版本控制、审计轨迹、层级扩展、公式风险、安全及人工刷新工作量。 |
| ERP-native moduleERP 内置模块 | Transactional integration and one-vendor governance are priorities, and planning needs fit the module.交易集成和单一供应商治理优先，且规划需求符合模块能力。 | Forecast depth, scenario speed, usability, external signals, upgrades, and dependence on ERP data design.预测深度、场景速度、易用性、外部信号、升级及对 ERP 数据设计的依赖。 |
| Dedicated planning platform专业计划平台 | Multiple hierarchies, planners, markets, scenarios, workflows, and cross-functional reviews must scale.需要扩展多层级、多计划人员、多市场、多场景、工作流和跨部门审查。 | Integration effort, model governance, configuration ownership, implementation partner, licensing, and change burden.集成工作量、模型治理、配置责任、实施伙伴、许可及变更负担。 |
| Analytics layer分析层 | Teams need to connect data, investigate drivers, compare segments, or validate planning outputs around existing systems.团队需要围绕既有系统连接数据、调查驱动因素、比较分群或验证计划输出。 | May not own plan workflow, approvals, supply balancing, replenishment, transactions, or writeback.可能不承担计划工作流、审批、供需平衡、补货、交易或回写。 |
These options can coexist. The target architecture should name the system of record for actuals and master data, the planning system of record, the analytical environment, the workflow owner, the approved outbound plan, and every writeback path. Avoid duplicate master data and unclear ownership between overlapping tools.
这些方案可以共存。目标架构应明确实际数据与主数据的记录系统、计划记录系统、分析环境、工作流责任人、批准后的输出计划和每条回写路径，避免工具重叠导致主数据重复和责任不清。
Demand planning software capabilities to evaluate需求计划软件需要评估的核心能力
Naive baselines, statistical and machine-learning methods, intermittent demand, causal inputs, lifecycle analogs, outlier treatment, backtesting, bias, accuracy by horizon, and explanations planners can challenge.
朴素基线、统计与机器学习方法、间歇需求、因果输入、生命周期类比、异常值处理、回测、偏差、分预测期准确性，以及计划人员可质疑的解释。
Product-location-customer-channel combinations, aggregation and disaggregation, calendar choices, units and currency, reconciliation, new objects, sparse combinations, and performance at realistic scale.
产品—地点—客户—渠道组合、聚合与拆分、日历、单位与货币、协调、新对象、稀疏组合，以及真实规模下的性能。
Versions, what-if assumptions, promotions, launches, price changes, overrides, thresholds, materiality ranking, comparison, rollback, and clear distinction between forecast, unconstrained plan, and constrained response.
版本、假设场景、促销、新品、价格变化、人工调整、阈值、重要性排序、对比、回滚，以及预测、无约束计划与约束响应的明确区分。
Roles, comments, tasks, approvals, ownership, reason codes, freeze windows, audit history, version restore, segregation of duties, and a controlled route to consensus demand.
角色、评论、任务、审批、责任、原因代码、冻结窗口、审计历史、版本恢复、职责分离及受控共识需求流程。
ERP, warehouse, order, promotion, pricing, CRM, data warehouse, APIs, batch timing, error handling, lineage, monitoring, identity, access, environment promotion, and release management.
ERP、仓库、订单、促销、价格、CRM、数据仓库、API、批处理时点、错误处理、血缘、监控、身份、权限、环境迁移和版本发布管理。
How the approved plan reaches supply, inventory, finance, procurement, production, and commercial teams; which system acts; what happens when execution differs; and how outcomes return for learning.
批准计划如何传递给供应、库存、财务、采购、生产和商业团队；哪个系统执行；执行偏离时如何处理；结果如何回流学习。
Data and integration readiness before vendor selection供应商选型前的数据与集成准备
A proof of concept cannot compensate for an undefined demand signal. Decide whether history represents orders, requested quantities, shipments, invoices, point-of-sale, consumption, or another event. Mark stockouts, lost sales, cancellations, returns, substitutions, promotions, price changes, one-time orders, and channel shifts. Otherwise the software may learn operational constraints as if they were demand.
如果需求信号本身未定义，POC 无法弥补。应明确历史数据代表订单、请求数量、发运、发票、POS、消耗还是其他事件，并标记缺货、销售损失、取消、退货、替代、促销、价格变化、一次性订单和渠道迁移，否则软件可能把运营约束误学成真实需求。
| Data domain数据域 | Readiness checks准备度检查 |
|---|---|
| Demand history需求历史 | Stable identifiers, event definition, timestamps, quantities, returns, cancellations, censoring, missing periods, and enough history for the intended horizons.稳定标识、事件定义、时间戳、数量、退货、取消、截断、缺失期间，以及满足目标预测期所需的历史长度。 |
| Master data主数据 | Product and location hierarchy, customer and channel, units, currency, calendar, lifecycle, substitutions, packs, effective dates, and ownership.产品与地点层级、客户与渠道、单位、货币、日历、生命周期、替代关系、包装、有效日期及责任人。 |
| Demand drivers需求驱动因素 | Promotions, price, events, weather or external signals where justified; future availability, latency, licensing, revision history, and leakage controls.促销、价格、事件、天气或合理的外部信号；未来可用性、延迟、许可、修订历史和数据泄漏控制。 |
| Interfaces and controls接口与控制 | Source and destination, frequency, volume, schema changes, retries, reconciliation, lineage, access, retention, monitoring, and approved writeback.来源与目标、频率、数据量、模式变化、重试、核对、血缘、权限、保留、监控和批准的回写。 |
Prepare a representative extract and a data dictionary before demonstrations. Vendors should identify unsupported fields, transformations, hierarchy assumptions, and integration dependencies in writing. Treat an effortless demo on vendor-prepared sample data as a product tour, not evidence of fit.
演示前应准备具有代表性的数据提取和数据字典，并要求供应商书面说明不支持字段、转换、层级假设及集成依赖。供应商样例数据上的流畅演示只能算产品导览，不能证明适配性。
A practical demand planning software evaluation scorecard实用的需求计划软件选型评分表
The following 100-point example is a starting framework, not a universal ranking. Approve weights before seeing vendor scores. Define evidence for each rating, identify pass/fail requirements separately, and have business, data, IT, security, and procurement owners sign off.
以下 100 分示例只是起点，并非通用排名。应在看到供应商得分前批准权重，为每档评分定义证据，单独标记必须通过项，并由业务、数据、IT、安全和采购责任人签字确认。
| Evaluation area评估领域 | Example weight示例权重 | Evidence to request应要求的证据 |
|---|---|---|
| Data fit and integration数据适配与集成 | 20 | Mapped interfaces, refresh and reconciliation test, lineage, failure recovery, and realistic volume.接口映射、刷新与核对测试、血缘、失败恢复及真实数据量。 |
| Forecast quality and transparency预测质量与透明度 | 15 | Frozen backtest, baseline comparison, bias and accuracy by segment/horizon, method and override explanation.冻结回测、基线比较、分群与预测期偏差/准确性、方法及调整解释。 |
| Hierarchy and lifecycle planning层级与生命周期规划 | 15 | Representative aggregation, disaggregation, reconciliation, new item, supersession, and discontinuation tasks.代表性的聚合、拆分、协调、新品、替代和停产任务。 |
| Workflow, collaboration, and governance工作流、协作与治理 | 15 | Role-based planning cycle, comments, reason codes, approvals, audit export, freeze, and restore.基于角色的计划周期、评论、原因代码、审批、审计导出、冻结与恢复。 |
| Scenarios and exception management场景与异常管理 | 15 | Create, compare, prioritize, approve, publish, and roll back scenarios and material exceptions.创建、比较、排序、批准、发布及回滚场景与重大异常。 |
| Usability and decision cycle易用性与决策周期 | 10 | Planner task completion, training need, refresh latency, accessibility, and time to approved plan.计划任务完成、培训需求、刷新延迟、可访问性及形成批准计划的时间。 |
| Security, implementation, support, and TCO安全、实施、支持与总成本 | 10 | Architecture, controls, implementation plan, ownership, release process, service terms, and five-year cost scenarios.架构、控制、实施计划、责任、发布流程、服务条款及五年成本场景。 |
How to run a defensible proof of concept如何运行可核验的 POC
Hypothetical test design: select a representative set of product-location series covering stable, seasonal, intermittent, promoted, new, and discontinued items. Freeze a historical cutoff, preserve later actuals as unseen test periods, and define a simple baseline before the vendor runs models. Include realistic users and integration constraints.
假设测试设计：选择一组具有代表性的产品—地点序列，覆盖稳定、季节、间歇、促销、新品和停产类型。冻结历史截止点，把之后的实际值保留为未见测试期间，并在供应商运行模型前确定简单基线，同时纳入真实用户和集成约束。
- Pre-register tasks and success criteria.预先登记任务与成功标准。 Include ingest, cleanse, model, review, override, scenario, approval, export, recovery, and audit tasks. Separate mandatory controls from scored preferences.包括导入、清洗、建模、审查、调整、场景、审批、导出、恢复和审计任务，并把强制控制与评分偏好分开。
- Use a frozen comparison.采用冻结比较。 Compare vendor outputs with a seasonal or other appropriate naive baseline using the same cutoff, horizon, grain, exclusions, and actuals. Prevent future information from leaking into training.在相同截止点、预测期、粒度、排除项和实际数据下，将供应商输出与季节性或其他合适的朴素基线比较，防止未来信息泄漏进训练。
- Test decisions, not only forecasts.测试决策，而不只是预测。 Ask planners to resolve exceptions, add commercial intelligence, explain changes, build a scenario, reach consensus, publish a version, and recover from an error.让计划人员处理异常、加入商业情报、解释变化、构建场景、形成共识、发布版本并从错误中恢复。
- Record effort and failure modes.记录工作量与失败模式。 Measure data preparation, configuration, task time, latency, manual steps, unsupported cases, vendor intervention, and the skills required to maintain the result.测量数据准备、配置、任务时间、延迟、人工步骤、不支持场景、供应商介入和维护结果所需技能。
- Review the full architecture and cost.审查完整架构与成本。 Validate identity, security, environments, monitoring, interfaces, support, licensing units, implementation services, data products, and exit/export provisions.验证身份、安全、环境、监控、接口、支持、许可计量单位、实施服务、数据产品及退出/导出条款。
Do not declare a winner from one aggregate accuracy number. Results must be useful at the decision grain and horizon, stable across important segments, interpretable enough for governance, and achievable without unsustainable manual work.
不要凭一个汇总准确率选出赢家。结果必须在实际决策粒度和预测期有用，在重要分群中保持稳定，具有足够治理解释性，并且不依赖不可持续的人工工作。
A phased demand planning software implementation roadmap分阶段需求计划软件实施路线图
| Phase阶段 | Required outcomes必要产出 | Exit checks退出检查 |
|---|---|---|
| 1. Process and metric design1. 流程与指标设计 | Decision calendar, roles, planning grain, horizons, freezes, overrides, metrics, governance, and target architecture.决策日历、角色、规划粒度、预测期、冻结、调整、指标、治理及目标架构。 | Business owners approve current and target workflows and acceptance criteria.业务责任人批准现状与目标流程及验收标准。 |
| 2. Data foundation2. 数据基础 | Mapped signals and masters, quality rules, transformations, history, interfaces, reconciliation, lineage, and ownership.映射后的信号与主数据、质量规则、转换、历史、接口、核对、血缘及责任。 | Representative loads reconcile and data exceptions have owners.代表性加载完成核对，数据异常均有责任人。 |
| 3. Pilot process3. 试点流程 | Configured models, hierarchy, workflows, roles, scenarios, integrations, training, support, and parallel run.已配置模型、层级、工作流、角色、场景、集成、培训、支持及并行运行。 | Acceptance tests pass; planners can operate and recover without hidden vendor work.验收测试通过；计划人员无需隐藏的供应商工作即可操作和恢复。 |
| 4. Controlled rollout4. 受控推广 | Wave plan, cutover, access, monitoring, issue triage, decision continuity, adoption, and decommission plan.分批计划、切换、权限、监控、问题分级、决策连续性、采用及退役计划。 | Each wave meets service, data, process, control, and adoption gates before expansion.每一批在扩展前均满足服务、数据、流程、控制和采用门槛。 |
| 5. Continuous validation5. 持续验证 | Forecast monitoring, override value, exception effectiveness, drift, release governance, benefits review, and model retirement.预测监控、调整价值、异常有效性、漂移、版本治理、收益审查及模型退役。 | Owners review outcomes and change controls on a documented cadence.责任人按书面节奏审查结果与变更控制。 |
Avoid a big-bang rollout when planning definitions and data are still changing. A narrow pilot should still include end-to-end interfaces and actual decision work; a disconnected sandbox proves very little about production readiness.
当规划定义和数据仍在变化时，应避免一次性全面上线。小范围试点仍应包含端到端接口和真实决策工作；脱离生产链路的沙盒几乎不能证明上线准备度。
How to validate demand planning software after launch上线后如何验证需求计划软件
Measure adoption and forecast quality, but connect them to decisions and outcomes. Use consistent snapshots so forecasts are judged as they existed at each decision date. Report multiple horizons and meaningful segments; aggregate improvement can hide deterioration in critical products or regions.
既要测量采用和预测质量，也要把它们连接到决策与结果。应使用一致快照，使预测按当时决策日的真实版本接受评估，并报告多个预测期和有意义的分群，因为汇总改善可能掩盖关键产品或地区的恶化。
WAPE or other approved error measures, MAE at the decision grain, bias, baseline win rate, forecast value added by step, stability, and performance by horizon and demand class.
WAPE 或其他批准误差指标、决策粒度 MAE、偏差、相对基线胜率、分步骤预测增值、稳定性，以及分预测期和需求类型表现。
Cycle time, planner effort, exception volume and resolution, override frequency and value, approval timeliness, audit completeness, refresh failures, and adoption by role.
周期时间、计划人员工作量、异常数量与解决、调整频率与价值、审批及时性、审计完整性、刷新失败及分角色采用。
Service level or OTIF, stockouts, inventory, obsolescence, expedite cost, capacity changes, cancellations, margin, and working capital—interpreted with causal caution.
服务水平或 OTIF、缺货、库存、过时、加急成本、产能变化、取消、毛利和营运资金，并谨慎解释因果。
Data freshness, reconciliation, interface failures, runtime, user access, release defects, lineage coverage, restore testing, and support response against agreed terms.
数据新鲜度、核对、接口失败、运行时间、用户访问、发布缺陷、血缘覆盖、恢复测试及按约定条款衡量的支持响应。
A before/after trend is not proof that software caused the change. Promotions, assortment, service policy, supply constraints, prices, and market conditions can move simultaneously. Document changes, retain comparison groups or phased rollouts where feasible, and state what is observed versus inferred.
前后趋势不能证明变化由软件造成，因为促销、商品组合、服务政策、供应约束、价格和市场环境可能同时变化。应记录这些变化，在可行时保留对照组或分阶段推广，并明确区分观察与推断。
Total cost and demand planning software buying red flags需求计划软件总成本与采购风险红旗
Model total cost across implementation and steady-state operation: subscriptions and metric growth, environments, integration, data platform, external data, implementation partner, customization, testing, security review, training, internal product ownership, model monitoring, support tiers, upgrades, and exit or migration. Request low, expected, and high scenarios tied to business volumes.
总成本应覆盖实施和稳定运营：订阅及计量增长、环境、集成、数据平台、外部数据、实施伙伴、定制、测试、安全审查、培训、内部产品责任、模型监控、支持等级、升级及退出或迁移，并要求与业务量绑定的低、中、高三种场景。
- Demo-only evidence: the vendor will not run representative data, reveal preparation effort, or compare against a frozen baseline.只有演示证据：供应商不愿运行代表性数据、披露准备工作量或与冻结基线比较。
- Opaque “AI” claims: methods, training cutoff, leakage controls, fallback, monitoring, explanations, and human accountability are unclear.不透明的“AI”宣传：方法、训练截止、泄漏控制、回退、监控、解释及人员责任不清。
- Undefined ownership: every change requires consultants, or no internal role owns master data, configuration, releases, and model health.责任未定义：每次变更都依赖顾问，或内部无人负责主数据、配置、发布和模型健康。
- Workflow without control: overrides and approvals exist visually but lack reason codes, immutable history, export, role separation, and restore.有工作流但无控制：界面上有调整与审批，却缺少原因代码、不可变历史、导出、职责分离和恢复。
- Benefits without mechanisms: inventory, service, or revenue claims are not linked to a measurable decision change and necessary operational action.收益缺少机制：库存、服务或收入宣传未连接到可测决策变化及必要运营行动。
Analyze demand-planning inputs and outcomes across connected data跨关联数据分析需求计划输入与结果
Prepare demand history, forecast snapshots, approved plans, overrides, inventory, orders, promotions, product and location masters, and outcome metrics. InfiniSynapse can be used as an analysis layer to explore connected data, compare segments, and investigate changes around an existing planning process.
请准备需求历史、预测快照、批准计划、人工调整、库存、订单、促销、产品与地点主数据及结果指标。InfiniSynapse 可作为现有计划流程周边的分析层，用于探索关联数据、比较分群和调查变化。
Capability boundary: this page does not present InfiniSynapse as a dedicated demand-planning system. It does not replace forecast workflow approval, consensus-plan ownership, supply balancing, replenishment execution, production scheduling, purchasing, or ERP transaction writeback.
能力边界：本页不把 InfiniSynapse 描述为专业需求计划系统。它不替代预测工作流审批、共识计划责任、供需平衡、补货执行、生产排程、采购或 ERP 交易回写。
Open the InfiniSynapse analytics workspace打开 InfiniSynapse 在线分析工作区Demand planning software buyer FAQ需求计划软件买方常见问题
What is demand planning software?什么是需求计划软件？
It helps teams prepare, review, reconcile, and govern forecasts and demand plans across planning dimensions and periods. Actual capabilities vary, so verify planning, collaboration, integration, and execution scope.
它帮助团队跨规划维度和期间准备、审查、协调并治理预测与需求计划。实际能力因产品而异，因此必须验证计划、协作、集成和执行范围。
How is it different from demand forecasting software?它与需求预测软件有什么区别？
Forecasting software primarily estimates future demand. Demand planning software usually adds hierarchy management, overrides, scenarios, collaboration, versions, exceptions, governance, and connections to wider planning. Vendor boundaries still vary.
预测软件主要估计未来需求；需求计划软件通常增加层级管理、人工调整、场景、协作、版本、异常、治理和更广泛计划连接，但供应商边界仍有差异。
When should spreadsheets be replaced?何时应该替换表格？
Consider a dedicated system when planning complexity, version conflict, manual consolidation, weak auditability, slow cycles, or inconsistent decisions create material cost or service risk. Keep controlled spreadsheets when the process remains small and fit for purpose.
当复杂度、版本冲突、人工汇总、审计薄弱、周期缓慢或决策不一致造成重大成本或服务风险时，可考虑专业系统；如果流程仍小且适用，则可继续使用受控表格。
How should vendors be evaluated?应该如何评估供应商？
Use representative company data, a frozen baseline, predefined business tasks, measurable acceptance criteria, security and integration tests, planner usability, exception handling, implementation effort, and total cost. Do not rely only on scripted demos.
应使用企业代表性数据、冻结基线、预定义业务任务、可测验收标准、安全与集成测试、计划人员易用性、异常处理、实施工作量和总成本，不要只依赖脚本演示。
Is InfiniSynapse demand planning software?InfiniSynapse 是需求计划软件吗？
It should be positioned here as an analysis layer for exploring connected data and investigating planning results, not as the system that approves demand plans, balances supply, executes replenishment, purchases materials, or writes transactions back to ERP.
本页将其定位为探索关联数据和调查计划结果的分析层，而不是批准需求计划、平衡供应、执行补货、采购物料或向 ERP 回写交易的系统。
Official capability references and limitations官方能力参考与边界说明
The capability categories were checked against official product documentation rather than treated as universal promises. Microsoft documents aggregation and disaggregation, external signals, what-if analysis, version history, and collaboration in its Dynamics 365 demand planning overview. SAP documents forecast models, statistical forecasting, simulations, and consensus-demand use in its Integrated Business Planning demand-planning guide.
本页能力类别参考官方产品文档，但不把它们视为所有产品的统一承诺。Microsoft 在其 Dynamics 365 需求计划概述中说明了聚合与拆分、外部信号、假设分析、版本历史和协作；SAP 在其集成业务计划需求规划指南中说明了预测模型、统计预测、模拟和共识需求用途。
Product features, editions, licensing, integrations, security, and roadmaps change. Verify current vendor contracts and documentation. This page is an evaluation framework, not procurement, legal, financial, security, implementation, or forecasting advice. For monitoring principles, see the live InfiniSynapse guide to a focused data dashboard.
产品功能、版本、许可、集成、安全和路线图会变化，应核验当前供应商合同与文档。本页是评估框架，不构成采购、法律、财务、安全、实施或预测建议。关于监控原则，可参阅已上线的 InfiniSynapse聚焦型数据仪表板指南。