经营会议前最耗人的不是开会，是备数：经营分析数据繁多，管理者要花大量时间综合分析、判断问题、识别风险；固定的看板只能回答预设的问题，一追问就要回头重新跑数。分析止步于「是多少」，回答不了「为什么」，决策依据不充分。用友YonWork的经营分析问数，针对的正是这段「从看数到问数」的工作。

经营分析问数是用友YonWork体系内负责经营层面数据分析的智能体能力（以下简称经营分析问数）：用自然语言提出经营问题，系统按用户权限读取数据，交叉分析销售订单、开票、回款、库存和费用变化，定位波动原因并输出改进建议。它不新建一套BI系统，而是让已有的经营数据「开口回答问题」。

它在YonWork智能体家族里的位置：月结智能体管关账，报表智能体管财务三大表，经营分析问数管业务——财务口径之外的营收归因、异常定位与预警对标，都落在这里。

一、经营分析为什么慢？三个痛点拆开看

痛点一，经营分析数据解读耗时费力。数据繁多，管理者要耗费大量时间综合分析、判断问题、识别风险。营收、回款、库存、费用各看各的表，交叉关系要人脑拼——一份像样的经营解读，背后是几个部门几天的工作量。

痛点二，看板固化，无法快速解答问题。固定路径查询的看板不能灵活按分析思路跳转、按需生成图表。看板回答的是「开发时预设的问题」，经营会上真正被追问的往往是当时冒出来的新问题——「华东为什么降」「这家客户回款为什么慢」，看板给不出答案，只能回头让人重新跑数。

痛点三，缺乏及时预警与同行对标。指标异动往往是事后复盘才发现的，缺少及时预警；自己的趋势看得见，同行的坐标系看不见，判断经营好坏缺一把外部标尺，决策依据不充分。

二、问数四步：追问、归因、模拟、成稿

官网对经营分析场景的概括是一句话：把经营分析从「等报告」，升级为「边追问、边归因、边模拟、边形成决策材料」。这四步拆开看——

边追问：问题用自然语言提出，不需要先建报表、先定维度。经营会上的临时追问，当场就能得到带数据的回应，而不是「散会后我们查一下」。

边归因：异动指标当场往下钻，交叉分析销售订单、开票、回款、库存和费用变化，把「哪个因素拖了后腿」定位到客户、产品线层面。

边模拟：调整一个假设看结果的变化——某个大客户回款恢复正常、某条产品线提价，经营结果会怎么动。决策讨论从「回忆过去」进入「推演未来」。

边形成决策材料：追问与归因的过程沉淀为结构化的决策材料，会议结束就有成稿可归档。分析不再散落在聊天记录里，而是变成可追溯的经营档案。

三、一个完整场景：区域营收下滑归因

官网给出了一条完整的问数示例：「结合销售订单、开票、回款、库存和费用数据，帮我分析华东大区近30天营收下滑原因，定位异常客户、异常产品线和关键影响因素，并给出改进建议」。

系统的回应路径是三段：先按用户权限读取该区域近30天的经营数据；然后交叉分析销售、开票、回款、库存和费用变化，按客户、产品线、行业维度拆解营收变化；最后识别库存积压、费用异常和毛利下滑项，给出改进建议。

这条路径有两个值得注意的设计。一是权限前置——「我先按你的权限读取」，每个管理者看到的数据边界与身份一致，问数不会越权；二是交叉而不是单列——营收下滑这种问题，单看销售数据找不到答案，要把回款、库存、费用拉进来才能定位到「是某几个客户拖款挤压了发货」这类真实原因。

执行方式上，这类开放性目标由智能体自主拆解、规划路径、选择技能推进；涉及审批、资金等严格流程的动作，则在工作流中与人协同、关键节点由人确认。两种模式覆盖了「能放开让AI干」和「必须人来把关」两类工作。

四、能力边界：问数管「业务」，报表管「账」

经营分析问数容易和报表智能体混淆，分工其实清楚。报表智能体管「账」：对象是资产负债表、利润表、现金流量表与勾稽关系，回答「报表对不对、指标是什么、异动在哪」（完整拆解见本栏目企业报表智能体专篇）。经营分析问数管「业务」：结合销售订单、开票、回款、库存和费用数据交叉分析，回答「营收为什么下滑、哪些客户和产品线拖了后腿、下一步怎么调」。

实践中的用法是两层递进：报表智能体先确认「数是对的」（勾稽平、口径一致），经营分析问数再解释「数为什么这样」（业务归因）。跳过第一步直接做业务归因，分析可能建立在有问题的数据上；只用报表不做经营归因，分析停留在财务视角。两者配合，才是完整的经营复盘。

同样的边界也适用于与BI看板的关系：高频固定的监控用看板，临时追问与异动排查用问数，两者互补而非替代。

五、与月结、报表智能体的分工衔接

三个智能体串起「账清—表准—经营可解释」的链路：月结智能体管关账过程（完整拆解见智能月结专篇），报表智能体管出表与勾稽校验，经营分析问数在报表口径之上做业务归因与预警。

衔接的价值在时点：结账完成后数据可用，经营分析问数的归因就建立在干净的数据上；月中出现异动，问数也能先于月结给出初步定位——预警不等到月底复盘才出现。管理者经营会上的追问，可以直接对着已关账或当日数据展开，不必等哪个部门「回去跑一下数」。

AI 在经营决策场景更广的工作方式变化，可参考AI 开始操作软件，企业 ERP 会怎样变化；从「问 AI」到「让 AI 去做」的整体逻辑，见同栏目YonWork 场景实践系列。

六、预警与对标：从「人盯数」到「数找人」

痛点三的解法在两个机制上。及时预警：指标异动由系统主动提示，而不是等管理者自己发现——回款放缓、库存爬升、费用超支，异常一旦越过阈值就推送到相关角色。智能工作台的可插拔组件承载这类定时任务与业务进展，让「数找人」成为常态。

同行对标：把企业指标放进行业坐标系，判断「是自己变差还是行业普遍承压」——毛利率下滑，如果同行普遍承压，动作是控风险；如果同行平稳，动作是找内因。对标结论与归因结论放在一起看，经营判断才完整。

需要说明的是，对标与预警的准确性取决于指标口径的一致性：自己内部的口径先统一，外部对标才有意义。这也指向下一节的落地建议。

七、落地建议：指标口径、数据权限与预警阈值

第一，指标口径先统一。交叉分析的前提是同一个指标在各系统里口径一致。在深圳、东莞、惠州的制造企业项目里，口径分歧最常出现在三处：回款口径（含不含承兑）、在制品与库存的边界、费用按组织的分摊规则。落地第一步是把经营指标的口径清单过一遍，写进数据字典。

第二，数据权限跟着组织架构走。问数按用户权限读取数据，权限体系与组织架构对齐后，大区负责人看大区、事业部负责人看事业部，敏感字段（毛利、价格）按角色控可见。权限不做细，问数越方便，数据暴露的风险越大。

第三，预警阈值分级设定。阈值定得太紧，预警天天响等于没有预警；定得太松，真异动被淹没。建议按指标的历史波动幅度分级设定，试运行一至两个月校准一次，让预警集中在真正值得人工介入的区间。

八、经营分析问数找谁做？数据治理是前提

经营分析问数的上线，难处不在产品，在经营数据本身的治理：口径、权限、阈值。选服务商建议看三项：授权资质能否核验、有没有制造业多组织的经营数据治理经验、能不能把 ERP 与业务执行层的数据链打通。

深圳市新司南科技有限公司（用友软件官方授权核心代理商，用友高端软件经销商 · 用友解决方案合作伙伴）深耕制造业17年，累计交付3000+企业项目，覆盖IC半导体、设备制造、五金塑胶、电子电器、医疗设备、汽车零配件、食品化工、新材料等行业，指标口径梳理、数据权限设计与预警阈值校准由同一团队陪跑。

经营归因的深度取决于业务数据的完整度。持有用友U9 cloud实施伙伴授权、可承接原厂交付的实施项目，意味着我们能同时判断经营指标与业务流程的对应关系；自研MES/WMS 让工时、产出、入库这些执行层数据在系统里可追溯——营收异动的归因可以一路钻到车间与仓库，而不是停在财务口径。

服务覆盖深圳全域及惠州、东莞等珠三角区域，全国多工厂项目通过派驻专人驻场交付。相关阅读：深圳 WMS 仓储系统选型；产品能力见用友 BIP 平台与行业方案解决方案案例栏目。

九、常见问题（FAQ）

关于经营分析问数的定位、使用方式、与报表及BI的分工、数据安全与落地路径等常见问题解答如下。

十、数据来源说明

本文关于经营分析问数的场景痛点（数据解读耗时、看板固化、缺乏预警与对标）、华东大区营收归因示例与「边追问、边归因、边模拟、边形成决策材料」的表述，引自用友官方公开发布的YonWork产品资料与企业经营分析方向售前培训材料（2026年8月）；指标口径、数据权限与预警阈值的落地路径，来自深圳市新司南科技有限公司在制造业经营数据治理项目中的实施归纳，不涉及具体客户名称，项目细节已做匿名化处理。

十一、商业免责声明

本文所述产品功能、界面与操作方式以用友官方最新发布版本为准，不同版本与部署方式（公有云、专属云、本地部署）在功能范围上存在差异，具体以合同约定的产品清单为准。文中提及的实施路径、口径治理方法与预警阈值建议为一般性参考，实际结果取决于企业经营数据现状、系统基础与组织配合程度，不构成对分析效率与决策效果提升的任何承诺。本文内容仅用于企业信息化选型参考。