移动 BI 项目最容易出现的误判，不是图表选错，而是把“手机上能打开”当成“业务流程已经移动化”。一张桌面看板缩小后放进手机，如果用户仍然不知道该看哪项指标、异常出现后该找谁、处理完如何确认结果，它只是多了一个访问入口，并没有真正进入工作流程。设计移动查看，我通常先问的不是“首屏放几张图”，而是“用户看完以后要做什么”。
移动 BI 的设计起点，应是一项具体工作任务，而不是桌面报表的既有布局。先界定用户在什么时机查看、需要回答什么问题，再决定数据、页面和后续动作。这样才能判断哪些信息应该留在首屏，哪些应该下钻，哪些根本不需要搬到手机上。
我把移动查看拆成四个连续环节：用户找到信息、理解信息、据此判断、完成下一步。移动页面只负责其中一部分时，也要明确它与其他系统或岗位之间的交接边界。BI 看板可以呈现异常和上下文，但不能默认它已经替代了任务分派、审批或业务处理系统。
这四个环节并不要求全部由 BI 平台承担。设计工作要做的是把断点显露出来：看板提供异常信号，业务系统承接操作，负责人完成处理，BI 再提供复核依据。流程边界清楚，才有办法评估移动 BI 是否值得建设。
桌面端的空间常常让团队倾向于“多放几个维度，方便分析”；手机端则必须更明确地排序。首屏不应为了看起来丰富而塞进所有指标，而应优先回答当前场景的核心问题，例如“今天是否偏离目标”“偏离发生在哪个区域”“我是否需要采取行动”。
屏幕越小，信息排序的后果越明显。一个不相关的图表会挤占关键数字的位置；一个没有基准的红色数值会制造紧张，却不一定代表真实异常。移动设计要把“看见数据”推进到“理解数据”，因此目标差距、更新时间、比较口径和数据范围，往往比增加一张装饰性图表更重要。
移动 BI 是否有效，不能只用“页面已上线”或“访问量增加”来证明。访问可能来自误触、试用或临时检查，并不代表用户完成了判断。更有用的评估问题是：用户找到关键数据需要多久？异常是否有明确责任人？处理状态能不能追踪？复核时是否还要重新拼表？
如果团队目前没有这些数据，不必先编造上线收益。可以在试点前记录基线，例如抽取一周的异常核对时间、人工催办次数、从发现问题到责任人确认的间隔，再与试点期间采用相同口径观察结果。基线不必完美，但口径必须前后一致。
“管理者随时随地看经营情况”听起来合理，但还没有说明管理者何时会打开页面、要回答什么、判断之后要不要处理。场景定义至少要包含角色、触发时机、待回答问题和后续动作。缺少其中任何一项，设计团队都容易用“把所有重要指标放上去”填补空白。
例如，区域负责人晨会前查看昨日经营情况，和门店主管营业中收到缺货提醒，虽然都通过手机访问数据，使用任务却不同。前者可能需要跨门店比较和趋势判断；后者更需要定位商品、确认库存状态以及联系补货责任人。两者不适合共用同一套首屏排序。
| 场景 | 触发时机 | 核心问题 | 移动端优先内容 | 看完后的动作 |
|---|---|---|---|---|
| 区域经营复盘 | 晨会前或经营例会前 | 哪些门店偏离目标，偏离来自哪里 | 目标差距、区域排序、趋势和可下钻门店 | 确定复盘对象和责任人 |
| 营业中异常处理 | 异常提醒或巡店过程中 | 异常是否真实，影响范围多大 | 异常对象、发生时间、影响程度、更新时间 | 核实原因并联系处理人 |
| 销售跟进 | 客户拜访前或跟进间隙 | 客户进度是否停滞，下一步跟进什么 | 目标进度、近期变化、待跟进客户和负责人 | 进入业务系统记录跟进 |
表中的内容是场景设计示例，不代表某一企业的普遍做法。实际项目中，我会先让业务人员讲清楚最近一次真实的查看过程，再观察他们目前如何找数据、用什么口径核对、最后把结果发给谁。相比直接开需求会收集“想看哪些指标”，回忆具体任务更容易暴露真实流程。
移动端有一个容易被忽略的特征：它适合在碎片时间触达用户，但不代表每项指标都应该即时推送。提醒太少，用户可能错过重要异常；提醒太多，用户会把消息当噪声，甚至关闭通知。提醒设计应围绕决策窗口，而不是围绕数据刷新频率。
我会追问三个问题：异常发生后，用户多快需要知道？延迟多久会影响业务结果？接到提醒的人是否有权限和能力处理？如果答案是“必须马上处理”，消息需要明确对象、影响、时间和入口；如果只是例行观察，日报或主动查看可能比即时提醒更合适。
还要把“数据刷新快”与“业务可行动”分开。源系统每几分钟更新一次，并不自动意味着用户每几分钟都需要收到通知。刷新频率、提醒阈值、接收对象和处理时限是四个不同的设计决策，应该逐项确定。
设想一个连锁经营团队希望通过手机查看每日门店表现。最初的需求可能是“把销售额、订单数、客单价、库存、毛利率都放进移动看板”。我会先把需求改写成可验证的问题：区域负责人早上能否判断哪些门店需要关注？门店主管营业中能否定位某项异常？问题发现后，谁负责跟进？
改写后，至少会出现两类不同入口：一类是汇总复盘，回答“整体是否偏离”；另一类是异常处置，回答“哪一项出了问题以及怎么办”。这两类入口可以共享数据模型，却不必共享页面结构。把它们硬塞进同一张首屏，通常会让两种任务都变得不清楚。
缩放解决的是尺寸适配，不是阅读优先级。桌面端常见的多图表布局在手机上可能变成一列很长的页面，用户要反复滑动才能找到关键指标。更严重的是，首屏没有结论，用户看见数字后仍然要自己判断哪些值得关注。
更稳妥的迁移方式是重新筛选内容：首屏呈现与当前任务直接相关的信息；次级页面提供必要的对比和下钻；低频、探索型分析保留在适合长时间阅读的桌面环境。移动端不是把桌面页压缩，而是为特定任务重新编排信息。
图表多不等于上下文完整。只呈现一个销售额，用户可能不知道它是累计值还是单日值；只显示同比下降，用户可能不知道去年同期是否有特殊事件；只标红低于目标的门店，用户可能不知道目标值是否按门店规模进行了合理设定。
每个关键数值至少要交代口径、时间范围、比较基准和更新时间。并非每个首屏都要展示长篇说明，但数据来源和定义应当可追溯。尤其当不同部门对同一指标有不同计算口径时，移动化不会消除争议，反而可能让错误判断传播得更快。
红色、黄色和绿色是视觉编码，不是业务规则。阈值如果没有考虑季节性、门店规模、业务阶段或数据完整性，就可能把正常波动标成异常，也可能让真正的问题被宽松阈值掩盖。阈值应由业务规则和数据质量共同决定，而非为了页面整齐统一设定。
对异常规则，我建议同时记录阈值来源、适用对象、触发时间、豁免条件和复核人。若目前无法设定可靠阈值，可以先展示趋势与参考区间，让用户进行人工判断，而不要制造过度确定的红绿灯。
提醒只是流程入口。消息发送成功，不代表责任人读到；责任人读到，不代表理解异常；理解异常，也不代表问题已经处理。若团队把通知数量当作闭环证明，就会高估移动 BI 的实际作用。
要判断是否形成闭环，至少需要明确接收对象、确认方式、处理状态、升级规则和复核方式。若这些动作发生在其他业务系统，应把跳转入口和状态回写关系设计清楚；如果暂时没有集成条件，也应在试点方案中承认这是流程缺口，而不是把它包装成平台能力。
登录次数和页面访问量可用于了解触达，却不能直接证明看板改善了工作。访问量升高可能意味着用户更依赖数据，也可能意味着信息不好找、需要反复打开核对。应把访问行为与任务结果、处理时长、异常复核等指标结合起来看。
同样，访问量低也不一定意味着失败。如果该页面只服务于少数有明确职责的用户，低频但关键的使用可能有价值。评估方式应由业务任务决定，不能用一个全员通用的活跃度指标给所有看板打分。
我会把“想做移动经营看板”拆成一组具体问题，并尽量避免在问题里预设页面或功能。比如“要不要做实时看板”可以改为“用户在业务发生后多久必须知道结果”；“要不要做消息提醒”可以改为“什么条件出现时，哪个角色必须采取动作”。
如果团队无法回答这些问题，优先补充场景调研，而不是先选图表类型。问不清任务时，页面需求会不断膨胀；任务定义清楚后，指标和交互通常会自然收敛。
指标不是数据仓库里“已经有的字段清单”。它应当是业务问题与可用数据之间的桥梁。用户要判断门店是否偏离目标，可能需要实际值、目标值、差额、变化趋势和门店规模等信息；但只有在这些信息能改变判断时，才有必要放进移动页面。
对每个指标，我会核对五项内容：业务定义、计算口径、时间范围、更新频率、责任归属。再补充一项常被遗漏的信息：数据缺失或延迟时，页面如何表达不确定性。显示“0”与显示“暂不可用”含义完全不同，混淆两者会直接影响行动。
| 设计对象 | 要回答的问题 | 常见遗漏 |
|---|---|---|
| 指标定义 | 数值代表什么业务事实？ | 同名指标在不同部门口径不同 |
| 时间口径 | 统计到何时、与哪一时间段比较？ | 未标示数据截止时间或比较周期 |
| 异常阈值 | 什么情况下需要用户介入？ | 阈值未按业务对象或场景校准 |
| 责任对象 | 谁有权限处理、谁负责复核？ | 只指定接收人，没有升级规则 |
| 数据状态 | 缺失、延迟和异常值如何展示？ | 把不可用数据误显示为零 |
移动页面可以采用“结论摘要，关键差异，原因线索，业务明细”的层次。摘要让用户判断是否需要关注；差异帮助定位偏离；原因线索支持进一步分析；明细则服务于核实和交接。不是每个场景都要四层齐全，但层次应能解释用户从发现到确认的路径。
例如，区域经营负责人需要先看到目标完成情况，再定位落后门店，随后查看相关品类或时段。门店主管则可能直接从某项异常商品进入明细。两类角色使用同一套指标体系时，入口和默认筛选仍可能不同。角色差异应通过权限和任务设计表达，而不是简单复制出大量相似看板。
提醒规则需要同时考虑业务紧急性和处理能力。高紧急、可行动的异常适合即时触达；低紧急或无需立即处理的变化，适合汇总通知或用户主动查看。对于高频波动、数据质量不稳定的指标，先做提醒模拟和人工校验，避免一上线就造成通知疲劳。
提醒消息最好能说明“发生了什么、影响对象是谁、数据截至何时、下一步去哪里”。单独推送一个红色数字，通常会把解释成本转嫁给接收者。还要测试重复提醒、阈值反复跨越、数据迟到和责任人休假等边界情况。
试点的目的不是证明项目一定成功，而是尽早发现任务、口径和交接设计中的问题。优先选择一个高频、范围清楚、责任人明确的场景；限定参与角色与指标数量；保留上线前基线；明确何种结果代表继续、调整或暂停。
我会把评估分成三层：第一层看信息是否找得到，第二层看判断是否更清楚，第三层看后续处理是否更可追踪。若第一层就失败，应先改信息架构；若找到信息却无法判断，应检查口径和上下文；若判断清楚但处理未发生，问题可能在责任分派和系统交接，而不是图表。
下面用一家假设的多门店零售企业说明设计过程。企业有多个经营区域，管理者需要查看门店销售表现，门店主管也希望及时发现缺货或异常波动。这里的数量、耗时和改善值均为情景模拟数据，用于演示如何制定验证框架，不是公开客户案例，也不是任何 BI 产品的实测结果。
在这个示例里，团队先选“区域负责人晨会前定位需要关注的门店”作为试点任务，而不是同时建设销售、库存、人效、会员等全量移动驾驶舱。选择它的原因是任务边界较清楚：有明确角色、有固定时段、有可比的目标值，也能在试点中观察用户是否找到重点门店。
原始需求可能包含销售额、目标完成率、客流、客单价、库存、毛利和促销表现。经过场景梳理后，试点首屏只保留能够帮助区域负责人作出“是否需要追问、追问哪家门店”的信息：目标差距、近期变化、门店排序、数据更新时间和必要的下钻入口。
客流或毛利等指标并没有被判定为不重要，而是暂时放到二级分析中。只有当它们能解释某个门店为何偏离时，才进入进一步查看路径。这样做的取舍是：首屏分析深度下降，但判断入口更集中。是否值得牺牲深度，要由用户任务而非设计偏好决定。
| 页面层级 | 展示内容 | 支持的判断 | 不应承担的任务 |
|---|---|---|---|
| 首屏摘要 | 目标差距、异常门店数、数据截止时间 | 今天是否需要重点关注 | 解释全部经营原因 |
| 门店列表 | 门店、完成情况、变化方向、异常标记 | 优先追问哪家门店 | 直接推断异常成因 |
| 门店详情 | 趋势、相关指标、必要的时间与品类维度 | 偏离发生在何时、何处 | 替代业务人员核实事实 |
| 后续交接 | 责任人、处理入口、复核要求 | 问题由谁接手以及如何确认 | 把尚未集成的流程假装成自动闭环 |
试点前，团队应记录用户完成任务所需时间、需要打开几个来源、是否依赖人工汇总、定位后是否能找到责任人等基线。试点后使用相同任务和相同口径观察，才有机会判断流程有没有变化。
下面这组数据仅用于展示试点方案如何量化，属于情景模拟。假设试点前，区域负责人完成一次门店筛查平均需要 18 分钟，试点后目标是将中位数降到 10 分钟；这是一个待验证的目标，不应写成已经实现的成果。若没有真实记录，正文和汇报都应保留“待测”，而不是用预期值替代结果。
证据角色: 中游过程
数据来源: 情景模拟数据，仅用于示范试点指标设计；非客户实测
指标:
全局说明: 这组模拟值用于说明如何把“移动看板更方便”转为可测量假设。试点报告必须以真实记录替换目标值，并说明样本范围与统计口径。
仅观察最终是否处理，容易把流程中间的失败全部归因于看板。更有诊断价值的做法，是记录用户从收到信息到处理完成的各个节点：提醒是否送达、用户是否打开、是否确认异常、是否找到责任人、是否完成复核。漏斗在哪一层明显流失，通常能提示下一步该改什么。
以下同样是情景模拟，用来说明漏斗记录方式。假设 100 次异常事件中，90 次成功送达、70 次被打开、50 次被确认、32 次进入处理、24 次完成复核。数字并非行业基准，也不代表真实平台表现；它提醒团队不要把“消息送达率”当作“业务闭环率”。
证据角色: 中游过程
数据来源: 情景模拟数据，每 100 次异常事件构造；非行业统计
指标:
全局说明: 漏斗的重点不是制造一个漂亮的转化率，而是定位哪一段需要改进。真实项目应按异常事件去重，并明确各阶段的时间窗口。
首屏精简不能只凭设计团队审美判断。可用任务测试检验：给不同角色一个具体问题，让其在手机上找到答案，再记录完成情况和误判原因。例如让区域负责人找出低于目标且近几日持续下行的门店；如果用户只看到低于目标，却忽略趋势，页面可能缺少关键比较信息。
首屏指标越少，不代表一定越好。若删掉的维度是识别误报所必需的，页面反而会增加错误判断。测试时应区分“找到数值”“正确理解数值”“做出与规则一致的判断”，并分别记录，避免把页面打开成功等同于任务成功。
如果同一个指标在多个部门的计算方式不一致，或更新时间不明确，先把数据解释清楚。移动端传播更快，口径不一致也会更快引发争议。项目初期可以先做只读摘要，标明数据范围与更新时间，待口径和质量检查稳定后再考虑异常提醒。
这类团队的阶段性目标不是“全部移动化”，而是减少错误解释。建议指定指标负责人，维护定义、更新规则和异常处理方式，并对关键指标设置数据缺失提示。数据治理看起来不像页面功能，却决定了页面能否被信任。
已有桌面看板的团队，不宜直接复制所有图表。先按移动任务把内容分成三类：首屏必需、需要时下钻、移动端暂不提供。将高频且需要快速判断的信息放在前面，将低频探索分析留在桌面端，通常比试图让手机完整承载所有分析更符合使用条件。
迁移时还要重新检查默认筛选、滚动顺序、标题长度、图例可读性、时间范围和返回路径。桌面端用户可能同时看到多张图并进行比较，手机端用户则可能一次只看到一组信息。页面层级如果没有重新设计，使用者就会用频繁滑动和反复切页补偿信息组织不足。
若业务对响应时限有明确要求，优先确认谁接收、谁替补、何时升级、如何确认处理，再选消息、待办或系统内任务等触达方式。具体能力取决于企业现有系统和所选平台，不能仅凭产品宣传假定已经具备离线访问、自动升级、消息回写或审批等功能。
若责任链不清，更多提醒只会把问题扩散给更多人。试点可先在小范围内记录异常到确认、确认到处理、处理到复核的时间分布，判断瓶颈发生在哪个岗位或系统，再决定是否需要平台集成。
管理者场景通常更需要快速看出变化、判断优先级并追问细节。页面可优先呈现结论、目标差距、变化趋势和可解释的下钻入口。但“摘要”不能只给结论不给依据，关键数值仍需可追溯到时间范围、口径和来源。
如果管理者只是用看板准备会议，离线填报或复杂审批未必是必要能力。不要因为平台能做交互，就把所有工作流程放到同一页面。功能越多，权限和培训成本也越高，应以实际任务频率与影响为依据。
一线人员可能需要从异常进入商品、客户、订单或工单的处理页面。此时要确认 BI 页面能否提供准确上下文、业务系统是否支持移动处理、身份权限是否一致，以及处理结果能否回到分析链路。若跨系统跳转会丢失筛选条件或身份信息，用户可能需要重复搜索，反而增加操作成本。
BI 平台负责数据分析和呈现，不一定是最合适的业务操作入口。可以让看板负责发现与解释，让已有业务系统负责执行，再通过接口或明确的人工步骤完成状态回传。关键不是所有操作都集中在一个产品里，而是用户知道下一步在哪里发生。
在比较平台时，我会把候选能力分成“必须满足、可以替代、暂不需要”三组。必须满足的能力由业务流程决定，例如角色权限、移动端可读性、数据刷新要求和安全策略；可以替代的能力可由现有系统或人工流程承担；暂不需要的功能不应成为首轮采购的核心依据。
如果团队考虑使用九数云，可以从公开产品资料和实际演示中核实其与自身场景有关的能力，再针对样例数据完成一轮任务测试。可关注移动端布局与筛选、数据权限、指标口径管理、刷新机制、异常触达方式、设备适配和安全要求。具体功能支持范围、配置前提与版本差异，应以官方说明和实际测试为准，不宜仅根据“移动 BI”或“轻应用”等名称推断。
测试时最好准备一项真实但已脱敏的任务：给目标用户一组数据，要求其在手机上定位异常、解释原因并找到下一步处理入口。观察过程比听功能介绍更有价值。若试用环境无法覆盖权限、刷新或跨系统跳转等关键条件，应把未验证项列入采购风险，而非默认视为已满足。
精简首屏可以降低查找成本，但删掉必要上下文也可能增加误判。适合首屏的不是“最重要的所有指标”，而是“完成当前任务所需的最少充分信息”。如果用户必须同时查看目标、趋势和数据更新时间才能判断，就不能为了页面简洁把它们全部挪走。
在取舍时，我会先列出用户需要作出的判断，再标明每项信息对判断的作用。如果某项信息只用于满足管理层“想多看一点”的偏好，可考虑放在下级页面；如果它能改变异常是否成立、是否需要行动，就应保留在首屏或近距离可达的位置。
实时并非天然优于定时刷新。实时链路可能带来数据延迟不一致、瞬时波动、重复提醒和更高的运维要求。如果业务决策按日或按班次进行，稳定的定时数据可能比高频刷新更适合；如果异常会快速扩大损失，实时性才可能带来明确收益。
判断标准应是“数据延迟是否改变决策”，而不是“技术上能否更快”。当数据源本身存在延迟，页面标注为实时反而会误导用户。建议把刷新策略与源系统能力、业务容忍时间、数据质量监控一起评估。
主动查看让用户控制注意力，适合例行分析、低紧急度观察和信息密度较高的任务；推送适合重要、可行动且有明确责任人的事件。两者可以并存，但不宜把每个看板指标都变成消息。
设计提醒前，先定义去重、静默时段、重复触发、恢复通知和升级逻辑。若无法说清楚哪些情况不应推送，提醒规则大概率还没有成熟。试点期间可先使用较小接收范围和可调整阈值，观察误报与漏报，再逐步扩大范围。
把查看和操作放在同一界面，路径可能更短，但也会增加权限、审计和流程编排复杂度。通过链接跳转到已有业务系统，边界较清晰，却可能造成上下文丢失和重复搜索。没有绝对正确的方案，应按操作频率、风险级别和系统能力选择。
低风险、频繁且简单的动作，适合评估能否在移动分析流程中简化；涉及审批、财务确认、客户承诺或合规留痕的动作，应优先保证权限和审计完整。若当前平台不能可靠承载操作，就明确使用跳转或人工交接，不要为了“一站式体验”牺牲流程控制。
不同岗位需要不同信息层级，但过度个性化可能导致会议里每个人看到的指标定义不同。建议把指标口径、时间规则和权限边界统一，把页面入口、默认筛选和信息优先级按角色适配。这样既保留岗位相关性，也避免把个性化变成多套互不兼容的数据版本。
个性化需求增加时，还要计算维护成本：每多一种角色模板，就多一组验证、权限测试和变更通知。若两类角色只是筛选条件不同，可以考虑共享页面；若其决策问题和行动链路都不同，再拆成独立入口更合理。
上线前检查不应只核对页面是否适配手机。至少要确认主要任务、指标口径、用户权限和后续交接四个方面。任一方面没有明确答案，都应标记为风险并决定是否影响试点，而不是默认由用户自行理解。
效率指标可包括完成任务的时间、信息来源数量和重复核对次数；质量指标可包括异常识别准确性、误报比例和口径理解一致性；风险指标可包括错误接收、权限越界、数据延迟未提示和处理状态丢失。具体指标应按场景挑选，不必为了表格齐全而全部采集。
用时缩短但误判增加，不是成功；提醒打开率上升但处理率不变，也不能说明流程已改善。最好让业务负责人和数据负责人共同复核结果，并保留用户反馈、样本任务和统计口径，避免只用一张汇总图解释复杂变化。
试点结束后可以分三类决策：继续扩展、调整后复测、暂停项目。若用户能找到信息但判断不稳定，先改口径和上下文；若判断正确但无法完成动作，先补交接；若只有少数用户使用且任务并不高频，则重新评估移动化的投入是否值得。
不要为了证明项目价值而在试点前锁定改善百分比。更稳妥的做法是先记录基线，再约定可接受的方向和风险边界。例如筛查耗时下降是目标之一，但若关键异常漏检增加，即使平均耗时变短也不能直接扩展。
产品能力验证关注平台是否支持所需的设备、权限、筛选、刷新或集成方式；业务效果验证关注用户是否更快、更准确地完成任务。两者相关，但不能互相替代。功能演示通过，不等于业务流程有收益；业务团队喜欢页面，也不等于安全与数据口径检查已经完成。
如果考虑九数云或其他 BI 平台，可将验证拆成两轮：先用官方资料、演示和配置测试核对技术能力，再以目标用户和实际任务验证使用效果。把“已确认”“待核实”“暂不支持”“由其他系统承担”分别记录，能避免采购讨论中把不同性质的结论混为一谈。
证据角色: 下游结果
数据来源: 情景模拟数据，示范试点决策坐标；并非实际项目测量或行业基准
指标:
全局说明: 散点图用于说明扩展决策不应只看耗时或正确率单一指标。上述方案为模拟坐标，真实项目需采用同一任务、同一用户范围和明确的正确答案标准。
移动查看不是桌面看板的附属展示，也不等于把所有分析搬到手机。它真正值得投入的条件是：用户需要在某个具体时刻获得足够可信的信息，能够作出判断，并知道下一步由谁、在哪里完成。
因此，设计顺序应当是先任务、再指标、再页面、再提醒和交接，最后用试点验证。若顺序反过来，团队很容易先做出漂亮的页面，再努力寻找它应该解决的问题。
现在可以选一个具体场景，找一位真实使用者，回顾他最近一次需要在外查看数据的过程。记录他当时想知道什么、用了哪些来源、花了多久、如何确认口径、看完后通知了谁。然后把这项任务做成小范围试点，先建立基线，再迭代页面和交接。
如果试点证明手机入口减少了查找和沟通成本，并且没有牺牲判断质量，再逐步扩展到相邻任务。反过来，如果数据口径、责任链或后续系统还没有准备好，就先补这些短板。移动 BI 不是把数据放进口袋，而是让正确的信息在正确的业务时刻，抵达能够采取行动的人。
我准备给外勤主管做一个手机看板，但不确定该先挑图表，还是先梳理业务流程。我担心桌面端已有的指标直接搬到手机上，最后信息很多，主管却还是不知道该先处理什么。
建议先定义查看任务，而不是先选图表。把场景写成一句话：谁在什么时机，想判断什么问题，看完之后要做什么。页面只是承载这项任务的工具；如果任务没说清楚，图表越多，越容易把移动端做成缩小版桌面报表。例如，以门店主管晨间查看为假设场景，任务可以是“开店前发现昨日销售或库存异常，并确定优先跟进门店”。
流程可拆成：查看异常门店数、判断偏差程度、进入门店明细、联系负责人或记录跟进。对应页面先展示异常结论和与目标的差距，再提供门店列表及下钻入口，不必把所有经营指标塞进首屏。设计前可用四个问题做检查：使用者是谁、何时打开、需要回答什么、看完后采取什么动作。
若最后一个问题没有答案，就先确认这是不是一个纯查看场景，不要为了显得完整，硬把任务处理功能放进 BI 页面。
我们已经有一套桌面经营看板，领导希望手机上也能看。我不确定是做响应式适配就够了，还是必须重新排版；如果删掉指标，又担心关键背景信息不完整。
不要按“图表能不能缩小”决定去留，而要按“它是否支持当前移动任务”筛选。移动首屏优先保留能回答关键问题的信息；低频分析、复杂交叉对比和需要长时间探索的内容，可以放到下一级页面或继续留在桌面端。
内容类型移动端建议判断依据 关键结论与异常状态优先放首屏用户能否快速决定是否需要处理 趋势和目标差距按任务保留是否能解释当前状态，而非只增加信息量 多维交叉分析放入下钻或桌面端是否需要频繁筛选、比较多个维度 装饰性图表与重复指标通常删除是否改变判断或下一步动作 一个实用的筛选方法是逐项追问：“如果暂时看不到这个指标，用户会不会因此做出错误判断？
”如果不会，它通常不该占据移动首屏。还要在手机上验证指标名称、单位、更新时间和筛选条件是否清楚；只压缩布局而不重排信息，经常会让图表仍然可见、含义却变得难以判断。
我不希望业务人员漏掉重要异常，但也怕提醒太多，最后大家把通知都关掉。我想知道哪些情况适合推送，哪些情况更适合让用户自己查看看板。
两种方式服务于不同任务：主动查看适合定时巡检和整体趋势判断；异常提醒适合事件发生后需要尽快确认的情况。不要把每个指标变化都变成推送，提醒应该指向一个可判断、可处理的问题，而不是重复播报数据。例如，门店负责人每天早上查看昨日经营汇总，适合由用户主动打开；
如果某项库存低于业务设定的安全线，并且需要补货或核实，则可考虑触发提醒。阈值应由业务规则和数据口径确定，不能直接套用一个看似通用的百分比。推送内容至少说明发生了什么、涉及哪个对象、数据截至何时，以及点开后能查看什么。
上线前可先在小范围观察提醒质量：记录触发次数、被确认的比例、重复或误报情况，以及提醒后是否有明确跟进。若提醒频繁但很少带来有效处理，优先检查阈值、数据延迟和接收范围，而不是继续增加通知。具体推送能力、权限和消息入口需按所用平台实际支持情况核实。
项目验收时，大家很容易用页面是否能打开、图表是否显示来判断成功。我担心上线后用户只是偶尔点开，实际决策和问题跟进并没有改变，应该用什么方法评估试点？
试点要验证的是任务能否完成，而不只是页面能否加载。先选一个边界清晰的场景，例如一类角色、一个业务问题和一条后续处理路径，再观察用户能不能找到关键信息、做出判断，并知道下一步找谁或去哪里处理。可在试点前记录基线，再与试点期间比较。
指标不必追求复杂，常见观察项包括：完成指定查看任务所需时间、关键异常是否被识别、问题是否有责任人和处理状态、用户遇到的口径疑问。若没有可靠基线，就先记录实际观察结果，不要预先承诺某个提升比例。建议按“准备，观察，复盘”执行：准备一组真实但经过权限控制的任务；观察用户独立完成任务时卡在哪一步；
复盘问题属于页面信息、指标定义、数据时效，还是后续流程缺失。若用户看懂了数据却无法采取行动，问题未必在 BI 页面，也可能需要调整责任分工或衔接现有业务系统。试点通过后再扩大范围，并确认角色权限、设备适配、数据刷新规则和安全要求。
这样可以区分“技术可用”和“工作流程真正用得上”，也能避免一开始就把所有桌面看板整体搬到手机端。
读者评论
把移动 BI 定位为业务判断流程，而非桌面看板缩小版，这个思路很实用。尤其是查看后由谁处理、如何复核，确实需要在设计前说清楚。
文中对提醒的讨论比较客观：数据更新快不代表每次变化都值得推送。实际落地时，阈值、接收人和处理时限都需要结合业务场景验证。
用上线前基线比较处理时长和催办次数，比单看访问量更能评估效果。不过跨部门统一指标口径和回写处理状态，可能是试点中较难解决的部分。