条件一：数据源稳定
每个指标要能指到一个确定的源表或接口，且更新频率可承诺。若关键数据仍靠人工填表或邮件汇总，驾驶舱只能展示滞后结果。判断办法是随机抽三个指标，让数据工程师当场说出取数路径与更新时间。
条件二：主键与组织口径统一
客户、门店、项目、组织架构要有一致编码，否则同一对象在不同系统各有 ID，聚合只能靠名称模糊匹配。缺口常见于并购与多业态企业，需要先建映射表并指定维护方，否则每次新增系统都要重做一遍。
条件三：权限有源可依
行级权限依赖组织架构与岗位数据。若权限仍由各部门手工维护，驾驶舱无法自动收敛可见范围，只能退化成人工授权。可行做法是接入统一身份，把组织与岗位当作权限主数据同步过来。
条件四：网络与日志可达
跨网段取数、内外网隔离、数据库只读账号，都会改变实施方式。审计要求日志留存时，还要确认源系统是否开启操作日志。这些条件在立项时确认，比在上线前一周才发现要从容得多。
适用与不适用
适合谁
- 正在评估驾驶舱可行性的数据与信息化团队
- 多系统并存、主数据分散的中大型企业
不适合谁
- 核心指标仍靠表格手工汇总的部门
- 组织架构频繁调整、主数据无人维护的企业
典型场景
某集团准备建驾驶舱，先做了一周条件核查：抽十个指标追溯取数路径，发现三个来自手工台账；客户编码在三个系统里不一致；权限仍由各部门邮件审批。团队据此把项目拆成两期，先做主数据映射与统一身份，驾驶舱延后一个季度启动。
可执行步骤
- 随机抽十个核心指标，逐一追溯取数路径、更新频率与责任人并记录
- 比对客户、门店与组织架构的主数据编码，列出不一致清单与影响范围
- 确认统一身份与岗位数据能否直接作为行级权限来源，不必二次开发
- 逐一核查跨网段取数、只读账号、日志留存与审计留痕等条件
- 按缺口数量与影响面决定先做数据治理还是先建驾驶舱，并写进立项材料
常见坑
- 跳过条件核查直接排期，实施到一半发现接口要厂商配合，进度与预算同时失控。
- 主数据不一致却强行聚合，报表里同一客户出现多行，业务方从此不再信任数字。
- 跳过条件核查直接排期，实施到一半才发现接口要厂商配合，进度与预算同时失控，责任也难以界定。
自检与验收清单
- 核心指标是否都有确定的取数路径与更新频率
- 主数据编码是否已建映射并指定维护方
- 权限能否自动同步而非由各部门人工授权
- 日志留存是否满足审计要求并可导出查询
常见问题
数据条件不满足就不能做吗？
可以缩小范围做单域驾驶舱，但要限定指标并标注数据截止时间。缺主数据与权限源时不宜做跨部门版本，否则每个部门都会拿着不同口径的数字来质疑同一张看板。
主数据治理要多久？
取决于系统数量与历史数据质量，通常按月计而非按周计，且需要业务部门确认编码规则。建议先做客户与组织两类主数据，它们对驾驶舱影响最大，其余可分批推进。
云上和本地部署条件差别大吗？
主要差别在网络与账号体系：云上要确认能否打通内网数据源与统一身份，本地要确认算力与运维责任归属。数据分级结论会影响部署形态，建议在条件核查阶段一并列出。