口径打架，同一个指标几套算法
财务口径的收入、业务口径的收入、报表里的收入，三个数。每个部门的取数逻辑写在各自的 Excel 公式和 SQL 里，没人能说清哪个是对的。AI 只是把这个问题放大了——它会用其中一个，但不会告诉你它选了哪个。
Reality Check
AI 用不好数据，问题不在 AI
企业在 AI 上投入之后，最常见的挫败不是「模型不行」，而是「模型给的数我不敢用」。
数据搬来搬去，越搬越不可信
数仓抽一份、BI 抽一份、分析师再导一份到 Excel。每搬一次就多一个版本、多一次口径漂移。等到 AI 来取数时，已经分不清哪份是源头。
AI 拿不到带权限边界的数据
把数据开放给智能体，安全部门第一个问题是：它用谁的身份看？能看到哪些区域、哪些客户？如果答案是「全都能看」，这事就推不下去。
根因
AI 的上限，是它能拿到什么数据。在补数据底座之前，堆再多模型能力也只是把不可信的答案生成得更快。
The Order Matters
三件事按顺序做：一个底座 → 一套口径 → 一个语义层
Fabric 的能力清单很长。但真正决定 AI 能不能用上数据的，是这三步，且顺序不能颠倒。
1
一个底座
OneLake
所有数据放在同一个湖里，多引擎直接调用，不再为每个用途复制一份。
Bronze 原始层Silver 标准层Gold 业务层
分层留痕，出问题能一路追回去
2
一套口径
指标字典
每个核心指标明确业务定义、计算公式、数据来源、更新频率、责任部门与权限级别。
最容易被跳过、后期代价最大的一步
3
一个语义层
Fabric IQ Ontology
把上面那套口径变成机器能读的业务模型：实体类型、关系、业务规则与数据绑定。
五种智能体可共享同一套定义
顺序不能颠倒：跳过第二步，第三步建出来的语义层不可信
Define Once, Share Everywhere
一次定义，五种智能体共享
Ontology 最被低估的价值不是「让 AI 看懂数据」，是让所有 AI 用同一套定义。
OneLake 统一数据底座Bronze 原始层 · Silver 标准层 · Gold 业务层
定义一次
Fabric IQ Ontology · 语义层
实体类型 · 关系 · 业务规则 · 数据绑定 · 访问控制
- 业务含义
- 一致性
- 治理
- 可解释
Fabric
数据智能体
分析师与业务用户
对话式分析问答
Fabric
运营智能体
运营团队
持续监控 · 告警 · 触发动作
Foundry
Foundry IQ
开发者
自定义 agent · 工具调用
Copilot Studio
低代码智能体
业务人员 / 低代码
对话式 agent · 流程自动化
MCP
自定义智能体
开发者
任何 MCP 客户端接入
五处消费同一套定义 —— 不用在每个平台重新解释一遍「活跃客户」
这意味着什么
你在 Copilot Studio 上搭的 agent、在 Microsoft Foundry 上跑生产的 agent、和 Fabric 里的分析 agent，可以共享同一套业务定义。定义一次，五处生效——不用在每个平台重新解释一遍什么叫「活跃客户」。
Capability
Microsoft Fabric 关键能力
完整功能清单微软官网有。这里只讲支撑上面那三步的四件事。
OneLake
全域统一数据湖，结构化 / 半结构化 / 非结构化统一存储，多工作区共享与隔离，虚拟化减少搬运与冗余。
全场景分析
数据集成、数据工程、数据仓库、数据科学、实时智能、Power BI，一套平台一条链路，不再拼接多家组件。
Real-Time Intelligence
低延迟流式分析，设备与业务事件实时接入，支撑监控、预警与实时决策类场景。
统一治理
权限管控、敏感数据识别、数据血缘、容量与成本监控，全平台一套安全模型。
Reference Architecture
一家大型能源企业的统一数据平台
风电、光伏电站运营数据，加上 ERP 财务、CRM 客户、年度预算和多年历史 Excel，分散在互不相通的系统里。管理层看到的日报周报月报，靠人工提取、合并、核对——耗时、易错，且各部门口径不一。
数据源
业务数据源
- 电站运营系统
- ERP 财务与合同
- CRM 客户与商机
- 年度预算
- 多年历史 Excel
Data Factory · Pipeline · Dataflow Gen2 · Notebook
数据底座
OneLake 统一数据底座
Bronze 原始层保留源系统原始数据，便于追溯重跑
Silver 标准层清洗去重、格式统一、主数据匹配
Gold 业务层主题模型与聚合指标
语义层
统一维度模型 + 语义层
指标字典 · DAX 度量值 · 口径管理 —— 同一套定义供所有报表与智能体复用
- 指标字典
- Fabric IQ Ontology
分析与智能
Power BI 三大分析域
- 电站运营发电量 · 利用小时 · 故障
- 企业经营收入成本 · 预算 · 回款
- 客户销售漏斗 · 赢单率 · 客户价值
后续扩展
自然语言问数 · Copilot
AI Agent 与预测分析
底座建好后按期扩展，不必一次建完
三大分析域
电站运营
发电量与上网电量、利用小时、设备可利用率、弃风弃光、故障与停机、场站与区域排名，支持从集团到单台设备逐级下钻。
企业经营
收入成本利润、预算完成率、项目与合同毛利、应收账龄与回款、板块与子公司贡献，运营指标与财务结果关联分析。
客户销售
销售漏斗与阶段转化率、赢单率与销售周期、客户价值与集团分析、销售预测准确性，覆盖区域与团队绩效。
四个关键设计
Bronze / Silver / Gold 分层
保留从源系统到报表的完整处理过程，避免报表直连业务系统带来的性能与数据一致性风险，出问题能逐层回溯。
指标字典
每项指标明确定义、公式、来源、频率、责任部门与权限级别——先解决人的分歧，再写代码。这是全项目最容易被跳过、代价最大的一步。
RLS 行级安全
按组织、区域、场站、岗位配权：销售只看自己的客户，场站负责人只看自己的场站，敏感财务数据单独限制。
容量与成本监控
跟踪各工作区消耗、高消耗任务与峰值时段，让平台运行成本可预测、可优化，而不是月底看账单才知道。
分期策略
一期电站运营与现有报表 → 二期 ERP 经营财务 → 三期 CRM 客户销售 → 四期预测分析、自然语言问数与 AI Agent。每期以可验收的业务成果收口，不追求一次建完。
这个项目的核心价值
它不是把 Excel 报表搬到 Power BI。而是以 Fabric 和 OneLake 建立统一数据底座，把运营、财务、销售数据整合成可信、可治理、可复用的数据资产——并为后面的 Copilot 问数和 AI Agent 备好地基。
Delivery
诺未怎么交付
数据平台项目失败，多半不是技术问题，是口径没谈拢、范围没划清、责任人没确认。我们把这些放在写代码之前。
现状评估与蓝图设计
- 报表清单与使用频率盘点，识别可替代、需保留、可合并的部分
- 数据源技术可行性评估：数据库、API、文件接口能力
- 指标定义与数据责任人逐项确认
需求规格 · 数据源清单 · 总体蓝图
01
02
OneLake 底座与数据管道
- Fabric 容量规划与开发／测试／生产工作区划分
- Bronze / Silver / Gold 分层建设与命名规范
- 多源接入、增量同步、主数据映射与异常识别告警
平台基础架构 · 自动化数据管道
语义建模与口径治理
- 统一维度模型：组织、区域、客户、合同、项目、产品
- 企业指标字典编制与跨部门口径对齐
- 语义模型、DAX 度量值与 Fabric IQ Ontology 业务建模
Lakehouse 与语义模型 · 企业指标字典
03
04
分析交付与 AI 打通
- Power BI 报表开发与管理驾驶舱
- RLS 行级安全与数据权限配置
- 与 Copilot、Foundry 智能体对接；容量成本与刷新监控
上线运行 · 运维手册 · 用户培训
Why NovaTech
为什么是诺未
诺未科技（NovaTech）是微软解决方案合作伙伴，自 2011 年起深耕微软技术栈，为超过 1000 家企业提供从战略咨询到持续运维的端到端服务。
全栈微软资质，端到端交付能力
微软云全六项 Solution Partner 认证：
- Modern Work · Data & AI (Azure) · Digital & App Innovation
- Infrastructure (Azure) · Business Applications · Security
Advanced Specialization 与双通道资质：
- AI on Azure · Infra & Data Migration
- Adoption & Change Management · Custom Solutions for Microsoft Teams
- 21V CSP / OSPA / NCEI · HK 1T/2T CSP · SG 2T CSP · ECIF Certified Partner
连续两年微软黑客松冠军
2025 年
「Eva」智能体在微软中国区 Copilot AI 创新大赛获第一名
2026 年
「Sales Deal Agent」多智能体方案在微软 Frontier Agentic Hackathon 摘得「智胜全能金奖」（第一名），同年获FY26 微软市场拓展先锋奖
数据平台不是终点。诺未同时交付 Copilot Studio、GitHub Copilot 与 Microsoft Foundry 项目——底座建完之后的那一段，我们也做。
FAQ
常见问题 FAQ
Q1：和我们现有的数仓 / BI 是什么关系？要推倒重来吗？
A：不用推倒重来。实际做法是分期：先把现有报表接进来跑通，验证口径和数据一致，再逐步把上游的抽取与加工搬到 Fabric。老系统在过渡期继续跑，业务无感切换。哪些该替代、哪些该保留原始明细、哪些重复报表可以合并，这是第一阶段调研就要出结论的事。
Q2：我们已经在用 Power BI，Fabric 对我们意味着什么？
A：Power BI 本身就是 Fabric 的一部分，现有的报表与语义模型可以延续，不是另起炉灶。变化在下面一层：以前 Power BI 直连各个业务系统或中间库，现在数据先进 OneLake 统一分层加工，报表连的是治理过的模型。好处是口径统一、刷新性能可控、血缘可追溯；代价是要先把数据分层和指标字典这两件事做扎实。
Q3：Ontology 到底是什么？和数据模型有什么区别？
A：数据模型描述的是表怎么建、字段怎么关联；Ontology 描述的是业务本身——有哪些实体类型（门店、设备、客户、合同）、它们之间是什么关系、有哪些业务规则、以及这些概念绑定到哪些表。区别在于：数据模型给人和 SQL 用，Ontology 给 AI 用。它的实际价值是「定义一次，多种智能体共享」——Fabric 的分析 agent、Foundry 上的自定义 agent、Copilot Studio 的低代码 agent，可以用同一套业务定义，答案才对得上。
Q4：数据安全怎么做？谁能看到什么？
A：按组织、区域、场站、岗位配置行级安全（RLS），必要时叠加对象级安全（OLS）：销售只看自己的客户，场站负责人只看自己的场站，敏感财务与人员数据单独限制。平台侧配套敏感数据识别、数据血缘追踪、刷新状态监控与访问审计。关键是权限模型要和组织架构对齐，这在蓝图阶段就要定，不是上线后再补。
Q5：多久能看到东西？
A：我们建议分期建设，一期通常先接运营数据、替代现有的日报周报月报——这是最快见效、也最容易验收的部分，之后再依次接 ERP 经营数据、CRM 销售数据，最后做预测与 AI 应用。具体周期取决于数据源接口条件、历史数据年限和报表数量，会在现状评估阶段给出明确排期，而不是先承诺一个数字。
Q6：怎么计费？
A：分两部分：Microsoft Fabric 按容量（F SKU）计费，Power BI 许可另计，这部分建议在报价里单独列示，方便你们内部走预算；诺未侧是实施与运维服务费，按数据源数量、表数量、报表数量和历史数据年限来界定范围。第三方系统的接口开发费、原系统厂商的服务费通常不在范围内，这点我们会在方案里写清楚，避免后续争议。