为什么你的 BI 项目没人用？把 BI 嵌入业务系统，才是真正的数据价值！
作者：Echo_Wish
很多公司都花了几十万、甚至几百万买 BI 工具。
结果呢？
领导一年登录不了几次，业务人员嫌麻烦，开发觉得维护成本高，最后 BI 系统慢慢变成了一个"数据孤岛"。
其实，并不是 BI 不好。
而是很多企业从一开始就做错了一件事：让用户去找 BI，而不是让 BI 去找用户。
现在越来越多企业开始做一件事情——Embedded Analytics（嵌入式分析）。
简单来说，就是把 BI 能力直接塞进业务系统里面。
今天，我们就聊聊这个越来越火的话题：BI 工具嵌入产品，到底有哪些实现方式？又有哪些坑千万不能踩？
什么叫嵌入式 BI？
举个最简单的例子。
以前销售每天打开：
ERP
↓
复制订单编号
↓
打开BI
↓
查询销售数据
↓
分析
现在呢？
打开 ERP。
订单页面右边直接就是：
━━━━━━━━━━━━━━━━━━━
订单金额趋势
客户购买频率
利润分析
库存预警
同比增长
━━━━━━━━━━━━━━━━━━━
甚至不用切换页面。
这，就是嵌入式分析。
分析能力已经成为业务系统的一部分。
用户甚至不知道自己正在使用 BI。
为什么越来越多公司开始这么干？
原因其实很简单。
大家可以想一想。
如果让你：
每天打开三个系统查看数据。
和
打开一个系统，所有数据都在眼前。
你会选哪个？
答案不用说。
所以 Gartner 很早就提出一个观点：
数据分析应该发生在业务发生的地方。
这句话其实非常有道理。
因为：
分析，不应该增加工作量。
而应该帮助用户做决策。
常见的四种嵌入模式
很多人觉得：
不就是 iframe 一嵌吗？
其实远远没有这么简单。
不同企业，适合不同方案。
第一种：Iframe 嵌入（最快）
这是最简单的。
例如：
<iframe
src="https://bi.company.com/dashboard?id=1001"
width="100%"
height="900">
</iframe>
开发成本最低。
几乎不用改 BI。
但是问题也很多：
- 登录容易失效
- UI 风格不统一
- 页面刷新慢
- 无法深度交互
- SEO 不友好
适合：
内部管理系统。
不适合：
对外 SaaS 产品。
第二种：SDK 嵌入（推荐）
现在越来越多 BI 平台都提供 SDK。
例如：
const dashboard = BI.embedDashboard({
container:"#dashboard",
dashboardId:"sales_001",
token:accessToken,
theme:"dark"
});
dashboard.load();
优势很多：
可以：
- 动态切换 Dashboard
- 修改主题
- 设置过滤条件
- 获取点击事件
- 控制权限
例如点击订单：
dashboard.on("click", function(data){
console.log(data.orderId);
openOrderDetail(data.orderId);
});
这样：
点击 BI 图表。
自动跳到 ERP 订单页面。
用户体验一下子就起来了。
第三种：API + 自己画图
很多互联网公司其实不用 BI 前端。
而是：
BI
↓
SQL
↓
API
↓
Vue
↓
ECharts
例如：
@app.get("/api/sales")
def sales():
sql = """
select
month,
sum(amount)
from sales
group by month
"""
return db.query(sql)
前端：
axios.get("/api/sales")
.then(res=>{
chart.setOption({
xAxis:{
data:res.data.month
},
series:[{
data:res.data.amount
}]
});
});
这种方式自由度最高。
但是：
开发成本也是最高。
因为所有组件：
都要自己维护。
第四种：微前端嵌入（大型企业最爱）
现在很多大型平台：
已经开始：
CRM
ERP
MES
OA
BI
全部拆成：
独立前端。
例如：
Shell
├── ERP
├── BI
├── OA
├── CRM
采用：
Module Federation。
或者：
Qiankun。
这样 BI：
就是一个独立应用。
维护方便。
升级方便。
权限也容易统一。
真正难的，其实不是嵌进去
很多人第一次做嵌入式 BI。
最大的误区就是：
认为：
页面出来了，项目就结束了。
实际上。
真正的挑战才刚开始。
第一大挑战：权限
很多公司都是：
ERP 登录一次。
BI 又登录一次。
用户直接崩溃。
所以现在基本都会做：
SSO。
例如 JWT：
payload = {
"user":"echo",
"role":"manager",
"tenant":"A"
}
token = jwt.encode(payload, SECRET)
BI 收到 Token。
直接识别身份。
无需再次登录。
体验会好很多。
第二大挑战：多租户隔离
SaaS 产品一定会遇到。
例如：
客户 A
不能看到：
客户 B 数据。
所以查询必须自动带：
where tenant_id = ?
千万不要：
前端传 tenant_id。
一定要：
后端解析 Token。
自动注入。
例如：
tenant = token["tenant"]
sql = """
select *
from sales
where tenant_id=?
"""
db.query(sql,tenant)
否则：
一个接口。
数据全部泄露。
第三大挑战：性能
很多 Dashboard：
打开就是：
30 多个图。
每个图：
一条 SQL。
结果：
30 SQL
↓
数据库
↓
CPU 100%
用户：
一直转圈圈。
怎么办？
一般都会：
第一层：
Redis 缓存。
第二层：
查询结果缓存。
第三层：
预聚合。
例如：
cacheKey=f"sales:{tenant}:{month}"
result=redis.get(cacheKey)
if not result:
result=query()
redis.set(cacheKey,result,300)
很多 Dashboard：
90% 请求。
其实都来自缓存。
第四大挑战：主题统一
很多 BI：
默认长这样：
白底
蓝色按钮
默认字体
而你的产品：
黑色主题
圆角按钮
企业 Logo
用户一眼就知道：
这是两个系统。
所以：
真正成熟的平台。
都会支持：
CSS Theme。
或者：
动态主题。
甚至：
跟随产品主题自动切换。
这样：
整个产品：
看起来才像一个整体。
数据分析不是功能，而是体验
我一直有一个观点：
BI 最大的问题，不是功能不够，而是离业务太远。
以前很多企业做 BI，更像是在建一个"数据博物馆"。
数据很多，图表很漂亮，指标也不少，但真正需要决策的时候，业务人员还得退出当前页面，登录另一个系统，再翻找半天报表。这样的分析，再强大也很难形成真正的价值。
真正优秀的嵌入式分析，应该像汽车上的仪表盘一样。
司机不会为了看油量，专门打开另一个 App；医生不会为了查看患者生命体征，再切换到另一个系统；仓库管理员也不应该为了确认库存趋势，离开当前的出库页面。
分析能力应该伴随着业务流程，而不是打断业务流程。
很多企业在推进数字化时，总喜欢问："我们的 BI 功能够不够丰富？"
但我更愿意问另外一个问题：
你的 BI，是不是已经融入了业务？
如果答案是否定的，那么再多的图表、再炫的可视化，都可能只是"摆设"。
写在最后
未来的 BI，一定不会再是一个独立的网址，而会逐渐演变成一种无处不在的分析能力。
它可能出现在 ERP 的订单详情页，出现在 MES 的生产工单界面，出现在 CRM 的客户画像中，也可能直接嵌入移动端、小程序，甚至 AI 智能助手的对话窗口。
对于开发者来说，嵌入式分析不仅仅是把一个 Dashboard 放进页面那么简单，它涉及统一身份认证、权限隔离、多租户设计、缓存优化、主题融合、事件联动、性能治理等一整套工程化能力。
而对于企业来说，这也意味着一种思维方式的转变：不要再让用户主动寻找数据，而是让数据主动服务业务。
当 BI 真正"消失"在产品中时，它反而发挥出了最大的价值。
这也许就是未来数据产品的发展方向——最好的 BI，不是最显眼的那个，而是用户几乎感觉不到它存在，却时时刻刻都在帮助他们做出更好决策的那个。
