Article body
正文
摘要： “数据找人”让重要变化在合适的时间抵达明确的责任人。HENGSHI SENSE 可围绕图表指标配置条件、检测频率与通知策略，也可将仪表盘按既定节奏推送给内外部用户；接收人收到信号后，可使用 Data Agent 继续开展对话式分析、创建指标和仪表盘。把这些能力与业务责任、处置记录和权限边界连接起来，企业能够把“发现—核查—处置—复盘”建设成可运营的工作机制。
一、把指标变化送到明确的责任人
许多团队已经有销售、运营、供应链或服务看板，但业务变化仍常常在周会或复盘时才被发现。原因并不一定是数据缺失，而是指标、接收人和处置动作之间没有形成稳定连接：业务人员不知道该看哪张图，分析人员不知道何时需要介入，管理者则在收到信息时缺少判断背景。
衡石的“数据找人”实践可以先从应用内可度量、可解释的业务指标开始。数据集成可对不同来源的数据进行抽取、过滤、转换、关联、合并和聚合，形成后续分析使用的数据基础；在应用中，团队再围绕图表中的指标配置预警或订阅。前者回答“指标是否满足我设定的条件”，后者回答“在这个时点，谁需要收到一份最新的业务视图”。两者服务的目标不同，不宜混为同一种通知任务。
| 机制 | 适合回答的问题 | HENGSHI SENSE 能力 | 团队需要补足的设计 |
|---|---|---|---|
| 指标预警 | 某个图表指标是否达到预设条件？ | 选择图表和指标，设置一条或多条规则，支持满足任一或全部规则时触发；检测可按小时、天、周、月或自定义频率执行。 | 指标口径、触发阈值、接收对象、通知一次或持续通知，以及异常任务的处理策略。 |
| 仪表盘订阅 | 谁应在固定节奏获得业务全貌？ | 应用中的仪表盘可立即或按计划推送；订阅可配置邮件、企业微信、飞书、Webhook、钉钉等方式，并可按受众设置不同内容。 | 周报、晨会、经营复盘等业务节奏，以及内外部接收人的数据权限范围。 |
| Data Agent 辅助排查 | 变化出现后，还应从哪些维度核查？ | 基于对话式交互，帮助用户对业务数据即时分析，并支持指标创建、仪表盘生成等任务。 | 允许分析的数据范围、优先核查的维度、结论复核人，以及何时升级为专项分析。 |
| 业务系统处置 | 确认问题后，如何创建工单或执行业务动作？ | 可通过 Webhook 把预警内容发送给企业自定义的 HTTP 服务；请求方式、请求头和请求体由企业配置。 | 外部系统接口、审批流、动作权限、回写字段和审计规则。这属于企业集成设计，不是预警功能默认执行的动作。 |
表1 指标预警、订阅、Data Agent 与业务处置的分工。
这一区分会直接影响使用体验。销售负责人每天早上需要包含多个核心指标的订阅摘要；区域经营负责人更关心定时检测发现某区域完成率低于警戒线时的提醒；分析人员收到提醒后，则需要进入关联看板，或通过 Data Agent 继续按区域、渠道、品类、时间等已建模维度核查。按阅读节奏设置订阅、按业务风险设置预警，有助于让通知保持清楚的优先级。
具体使用入口也要核对。当前公开手册说明，指标预警在应用发布态下暂不开放，租户场景则支持对平台方分享的应用配置预警。部署时应按实际版本、应用状态和账号权限检查入口，不能把“应用能够浏览”直接等同于“可在该状态配置预警”。
二、从“指标口径”开始设计一条可信的预警链路
预警的可信度首先来自指标，而非阈值。建议先确认用于图表的业务指标已经写清统计对象、时间范围、过滤条件和数据更新节奏。例如“日已支付销售额”与“日下单金额”是不同口径；“本区域销售额”还依赖区域归属的维护方式。若口径不稳定，即使规则配置正确，消息也会把不确定性快速扩散给更多人。
在 HENGSHI SENSE 中，一个图表可配置多条预警规则，并选择满足任一规则或满足全部规则时触发。这适合把业务语言翻译为可检查的条件：单一底线场景可使用“完成率低于目标”的规则；需要减少误报时，可用“完成率低于目标且同比下降”的组合条件。这里的规则是团队明确配置的业务判断，不能把平台预警描述为默认会自动学习阈值或自动识别任意异常模式。
| 配置项 | 推荐做法 | 示例 | 核查要点 |
|---|---|---|---|
| 业务对象 | 一条预警只对应一个明确的业务关注点。 | 华东区域昨日完整营业日已支付销售额完成率。 | 确认实际销售额与目标使用同一日期、区域和统计口径。 |
| 触发条件 | 先采用可解释的单条件或组合条件，再依据处置记录调整。 | 完成率低于 85%，且较上周同日下降超过 10 个百分点。 | 同比、环比或差值先计算为图表可用的指标，再设置规则；本例用“全部”触发。 |
| 检测频率 | 与数据刷新和业务决策窗口匹配。 | 昨日已结算数据每日 10:00 检测；小时指标另按小时检测。 | 不把未完成的当日与完整历史日直接比较；数据尚未更新时先排查时效。 |
| 通知策略 | 区分首次提醒与持续提醒，避免同一问题反复打扰。 | 首次达到条件通知一次；关键场景在每次检测仍满足时持续通知。 | 平台支持“通知一次”和“一直通知”两种设定。 |
| 失败处理 | 为任务本身建立可见的异常处理机制。 | 短暂故障时重试；连续失败达到约定次数时暂停并通知应用所有者。 | 确认重试间隔、次数和任务所有者，定期查看执行情况。 |
表2 预警规则与处置设计清单
平台支持按小时、天、周、月或自定义频率检测；对于连续满足条件的检测，可选择“通知一次”，使下次仍满足时不再通知，也可选择“一直通知”。任务执行出现异常时，可配置失败重试或失败暂停。这样的配置让团队能把“该不该提醒、何时提醒、任务失败谁知道”写进运行规则。
三、订阅负责“看全局”，预警负责“抓变化”
订阅与预警可以共存，但应有不同的发送逻辑。订阅面向周期性的业务阅读：管理者在晨会前收到经营看板，项目经理在每周例会前收到项目进度应用，外部合作方在约定时间获得自己权限范围内的报表。衡石订阅支持立即推送或设置计划；计划可按小时、天、周、月或自定义时间安排，并可设置任务优先级、重试次数及前置依赖等待时间。
预警面向值得中断注意力的变化：关键指标满足阈值条件时，系统才发出信号。预警消息中可使用应用标题、仪表盘标题、图表标题、预警条目标题、图表预览数据等模板变量；通过 Webhook 还可传递仪表盘链接。企业可以把消息写得更接近业务语言，例如“华东区域日销售完成率低于 85%，请查看区域经营看板”，再由接收人进入具体页面核查。
接收范围必须在设计阶段确认。订阅说明中，系统内用户收到推送的内容遵循应用的数据权限，系统外用户收到的内容则与应用作者权限相关；邮件预警还有使用预警创建者身份导出数据的配置。因而，向外部接收人发送含数据的内容前，应核对实际导出身份、应用数据权限模式、是否附加数据或公开链接。把消息交给外部 HTTP 服务后，也要由接收端继续控制访问范围。
四、Data Agent 用于辅助排查，不替代业务确认
一条预警告诉团队“哪里值得看”，却不必假装已经给出了因果结论。收到预警后，业务人员可以从预警关联的图表和仪表盘进入数据上下文，再向 Data Agent 提出清晰的问题，例如“按区域、渠道和品类拆分今天与上周同日的差异”“列出下降贡献最大的品类并展示订单数与客单价”“将这一分析保存为待复用的指标或仪表盘”。Data Agent 的价值在于缩短从问题到分析操作的距离，并不是把相关性自动宣布为根因。
在分工上，图表指标、规则与调度负责发现信号，Data Agent 帮助接收人继续查询与创作。需要活动、库存或外部环境信息时，应先确认对应数据已经接入、时间能够对齐，再进行比较；通过 Webhook 或其他企业集成对接工单和知识库时，还应约定接口、授权及回传方式。
对于复杂场景，可以把 Data Agent 的使用设计为一个轻量的排查清单：先核对数据更新时间与指标口径，再按已授权的业务维度展开，最后将观察、业务判断和后续任务记录下来。这样既保留了自然语言交互的效率，也让业务结论有可追溯的数据依据。
预警名称：华东区域日销售完成率提醒
触发时间：2026-10-22 10:00
统计周期：2026-10-21 完整营业日，对比 2026-10-14
预警条件：完成率低于 85%，且较上周同日下降超过 10 个百分点
示意结果：完成率 82%，上周同日 94%，差值为 -12 个百分点
初步核查：数据已完成刷新，继续按渠道与品类查看差异
待验证判断：库存变化是否影响订单履约，需要补充业务证据
处置动作：由区域负责人发起库存与订单核查任务
复盘安排：2026-10-23 核对处理结果，关联图表及复核记录上述记录不追求复杂，而是让每次提醒留下可用的团队记忆。连续几周后，团队就能判断哪些规则真正发现了问题、哪些场景应改为订阅阅读、哪些问题需要补充指标或数据集，而不是只根据是否“收到过消息”评价预警效果。
五、把业务处置反馈留在可追溯的边界内
预警可以通过 Webhook 将内容送达企业指定的 HTTP 地址，支持 GET、POST、PUT、DELETE 请求方式，并由企业自定义请求头和请求体。这为对接工单、协同或业务系统提供了连接点，但不意味着平台默认会执行折扣、冻结账户、修改订单等高影响动作。涉及客户、资金、账户或价格的动作，应由外部系统的权限与审批流程控制，并保留责任人、审批结果和回写信息。
实践中可将动作分成三类：信息类只负责把变化通知到责任人；核查类负责创建待办并要求补充原因；执行类则必须进入业务系统的明确授权流程。衡石负责提供数据、图表、预警、订阅和分析能力，企业则把本组织的责任边界、工单流程和外部动作权限设计清楚。这样做不会削弱主动化，反而能使主动化在真实业务里长期运行。
六、建议从一个小而完整的场景启动
首个场景宜选择指标口径清楚、数据更新稳定、责任人明确且可验证效果的业务问题，例如区域日销售完成率、关键项目交付进度或库存周转天数。先建设数据集和图表，配置一条可解释的规则，确定检测频率和接收人，再约定预警后的核查步骤与处置记录。运行一段时间后，结合推送记录、任务执行情况和业务反馈，调整规则、频率或订阅方式。
当这条链路稳定后，再逐步把更多指标、应用和外部协作接入。衡石的价值不在于代替业务做未经授权的决定，而在于把数据集成、指标分析、应用预警、仪表盘订阅和 Data Agent 分析连接起来，让团队在变化发生时更快看到同一份可信数据，并以更少的切换完成核查与协同。