最开始聊这个话题是因为一个做技术管理的老朋友来找我诉苦他们公司业务部门一再要求搭一套内部经营分析看板领导听完一句“我们又不是没有研发团队为什么还要花几十万去买BI”于是自研项目就这么立项了。结果做了九个月上线时业务说这不是他们想要的他们想要的是“能自己拖拖拽拽查数”的工具而不是每天提需求让研发帮忙改SQL再导成Excel。这个场景我相信很多公司都经历过也不只一次。问题的麻烦在于当“自研”被当成一种表态而不是一笔需要精细核算的投资能力边界和全周期成本这两个词往往被选择性忽略。这篇文章不打算简单站队“自研好”还是“采购好”。我更想把它拆成几层来看先说清楚BI产品的能力边界到底是什么再算一笔真正看到第36个月的全周期落地成本然后讨论这几年越来越多人走的“开源内核自研前端”混合路线最后聊一下大模型问数给这个决策带来的新变量。看完你基本可以自己做一个判断——你们公司是应该砸钱养自研团队还是老老实实去对接成熟BI工具。1. 为什么这是决策问题不是技术问题很多团队一开始把“自研还是采购BI”当成技术选型题最后发现错了。这本质上是一道资源配置题你的团队里有没有能做数据产品的人业务侧愿不愿意把口径统一起来数据底子干不干净上线时间窗口允不允许你花一年去打磨长期有没有人持续维护。1.1 BI不是“几个报表页面”它是三层能力的叠加要判断自研能不能做得先建立同一个基准BI到底包含什么。大多数技术人员想到BI第一反应是“图表看板”那就把它的复杂度看小了。一套真正能用起来的BI平台至少包含三层数据接入层处理各种数据源MySQL、Oracle、SQL Server、PostgreSQL、Kafka、API、Excel的同步、增量更新、连接配置还包括CDC、离线数仓、实时流等不同模式。数据建模层这是最容易被低估的一层。什么是事实表、维度表怎么建星型模型如何定义指标口径比如“销售额是含税还是不含税退货扣不扣”如何管控度量值的计算逻辑以及行列级权限如何在模型层就落地。分析展现层自助式拖拽分析、图表联动、筛选下钻、大屏、移动端、报表定时分发、消息预警、权限管理。用户每天看到的是第三层所以很多人误以为“BI就是画几个图”。实际上第三层只是水面上的冰山水面之下的建模和接入才是成本大头。1.2 “报表工具”和“BI平台”的真正分水岭是自助分析我判断一个系统是不是真BI方法很简单问业务方一句“你现在能不能自己拉一个新维度出来不通过任何开发人员”如果答案是“可以”那它是BI。如果答案是“你把需求提给ITIT排期下周给你”那它只是报表工具。不少自研团队做了几个月交付物看起来也是大屏看板但业务想看一个计划外的维度组合时还是要回到研发侧写SQL、调接口。这种东西使用率很快会掉下来——因为它把数据消费者的探索需求全部堵死了。1.3 市场里的成熟BI并不便宜但它的价格对应的是多年工程积累Power BI、Tableau、帆软FineBI、观远、永洪这些工具能活到今天不是靠画图好看。他们的核心资产是已经把“数据源连接器、复杂权限、多维分析引擎、移动端适配、调度系统、二次开发接口”这些难啃的骨头都啃完了。你花掉的那笔许可费本质上是在为别人十几年的工程经验买单这跟云服务器的逻辑类似租比买省心但长期租又可能有持续成本。所以决策的第一步不是问“我们能不能写代码”而是问“我们的目标场景需要哪一层的能力团队能不能长期维护这一层”。接下来的两章就把边界一层层拆开。2. 自研BI的真正边界能做与几乎做不好的事我不是“自研一概不行”的拥护者。实际上如果一家公司的核心业务就靠数据能力吃饭比如做垂直SaaS、做数据产品对外输出那自研BI底层引擎是有战略价值的。问题在于大部分企业自研BI的动机只是“不想花钱”或者“想体现技术能力”这两种动机都会在半年后带来痛苦。2.1 自研能稳稳拿下的地盘固定报表和内部小范围看板如果目标很清楚就是企业内部的运营团队每天看几张固定报表维度不多、数据量不大、并发极低那自研是能扛住的。架构不需要复杂一个定时任务把业务库的数据同步到分析库后面用Python或Node写几个查询接口前端用ECharts或者AntV渲染图表再用一个简单的后台管理用户和角色。我见过一个传统零售IT团队三个人用了三个月就把门店销售日报做出来了效果很稳定核心原因就是需求固定、数据量小、权限简单。这种场景下自研的优势很真实页面风格完全可控跟内部系统的交互深度集成想要什么布局就什么布局还不用看外部厂商的产品迭代脸色。2.2 自研很容易翻车的地带自助探索、复杂权限和大并发但问题往往出在需求升级的那一刻。业务方看完了固定报表一定会提出“能不能让我自己在界面上筛选一下、把月份和门店维度换一换”。这句话一出来自研的工程量就陡增拖拽式多维分析前端不是画图而是要维护一堆行列维度的元数据模型前端要支持任意拖拽、聚合、筛选、下钻还要处理图表的联动刷新。市面上的成熟前端库不少但真正达到Tableau那个操作流畅度的很难轻松做到。行列级数据权限业务方要求“华东区经理只能看华东区数据但区域总监能看全国”。这已经不是前端隐藏按钮的问题而是在数据查询请求到达SQL引擎之前就要在模型层把WHERE条件拼进去并且要能在复杂关联查询里不走错权限。这里一旦数据量大权限条件还会拖垮查询性能需要做权限缓存和谓词下推优化。自研团队没有一年的稳定性打磨基本做不踏实。大并发下的查询引擎查询走Elasticsearch还是ClickHouse要不要预聚合如何做查询超时管理如何防止几个大查询把分析库CPU打满。这些问题只有在并发上来以后才会暴露而自研团队往往会惊讶地发现上线前测试一切正常上线后却经常被业务部门的集中看数打垮。2.3 一个典型的自研失败路径几乎都是同一个配方把大量精力放在图表样式、大屏动画和前端交互上却对数据建模、权限模型、查询性能关注不足。第一版很快做出来业务验收时也很开心因为“图好看”。用了一个月业务发现数据对不上换个维度组合就出bug报表越加越慢。IT团队开始从“做功能”变成“修bug”加班抱怨一年后有人离职这套系统从此进入维护模式。我给技术团队的建议是如果真的要自研就用“能力边界清单”提前画好红线明确哪些功能在自研第一期不做哪些必须做。不要把全部希望寄托在“边做边看”上。能力边界清单可以按三层分别列层级自研第一期能做自研很难短期做到数据接入单机定时同步、MySQL/CSV/API上百种数据源原生兼容、增量同步自动恢复、实时流数据建模单表或简单多表JOIN、固定指标复杂星型模型、统一指标口径治理、血缘追踪分析展现固定图表、基础看板拖拽自助分析、行列级权限、秒级下钻、移动端适配性能与稳定小数据量单用户高并发、大数据量、异常自愈3. 成熟BI的边界License之外还有多少隐性成本不要以为选了采购就万事大吉。成熟BI的边界不体现在“能不能做”而体现在“适不适合你的场景”和“除了那笔licence费还有什么要花钱”。3.1 License费用只是入场券后面的实施、培训、二开都绕不开以Power BI为例如果走Pro授权单个用户每个月的费用不高但真正要用到企业级发布共享基本要上Premium Per User或者Premium容量价格直接跳一个数量级。国内厂商FineBI/FineReport这条路也不是买几十个并发就一劳永逸私有化部署、集群扩容、移动端模块、门户集成通常都要单聊价格。采购型工具的完整成本结构我建议用下面这个记忆框架授权/license 实施服务 培训 二开集成 年维护 服务器资源 口径治理。头一年很多企业把前三项算了到了第二年才发现后四项才是资金黑洞。实施顾问水平参差不齐交付的ETL逻辑写得像意大利面条后面数据对不齐时还是要自己人维护二开接口文档不全前端要拖进度自己补培训没做好业务方不熟悉操作最后贵重授权买了一堆活跃用户寥寥无几。3.2 成熟工具也不是万能适配产品Roadmap会锁死你一半需求有一个做新零售的朋友跟我分享过他们的经历他们的运营团队极其依赖一个“自定义群组分析”的功能而市面上的BI产品中大部分分析维度是预先配置好的无法支持“任意选中几个门店群组做组合对比”这种临时性的业务思考。类似这样的需求裁缝铺要改版型但通用BI厂商只会说“需求已经提上Roadmap了具体排期不确定”。这就是采购型产品的能力边界它能覆盖80%的通用场景但超个性化的体验永远不是它的优先项。具体到落地层还会遇到这些问题数据源驱动兼容你用到一个不太主流的AP系统数据库是某国产老库连接驱动不官方适配这时候要么等厂商更新要么自己去写连接但自写连接又回到了自研老路。移动端和第三方系统集成厂商的移动端APP不一定符合你的品牌要求也没有办法直接嵌到你的甲方App里需要再做一层iframe或SDK集成这个集成开发成本不会太低。私有化和安全合规很多传统企业在购买SaaS版BI时都会卡在企业数据不能出内网的安全要求上于是必须转私有化而私有化版本的报价和维护复杂度立刻上升。3.3 价格之外更要命的是“用户习惯迁移成本”不要忽略采购一个新工具也意味着业务人员要重新学习一套操作逻辑。一个已经在Excel里做了五年透视表的财务主管面对Power BI的DAX函数会非常抗拒一个习惯FineReport单元格报表模式的IT专员突然面对自助语义层也会迷茫。我见过不少企业采购完BI之后专门设置了一个“BI接口人”岗位由这个岗位的人代业务方做分析。这何尝不是一种变相的自研只是把自研代码变成了自研“人肉取数”。所以选型时要先想清楚用户是真的要自助还是只是要有人替他把报表变好看。这两种需求的对应方案完全不同前者需要功能培训和组织变革后者其实找成熟的报表工具就够了。成熟BI边界的一张清晰体检表你可以这样去对照采购BI的隐性成本点影响时间是否容易被忽视实施顾问交付质量上线后持续高用户培训不足前6个月高二开权限与接口受限有定制需求时中私有化适配部署阶段中厂商涨价与版本升级生命周期中高4. 全周期成本核算算到第36个月才知道贵不贵如果只对比第一年投入采购方案可能看起来比自研便宜也可能更贵取決于规模。但BI这种系统的致命点在于持续迭代和维护。把时间轴拉到第36个月再对比两条曲线的走向完全不同。4.1 自研BI的全周期成本模型自研的核心成本是人力。一个最小可用的自研BI团队至少需要后端开发1人、前端开发1人、数据/算法工程师1人、产品/测试1人这还不包含运维。按国内一线城市的中位数估算包含薪资、社保、办公分摊一个中级工程师的全成本大约每年40-60万资深的话要80万以上。四个人起步一年人力成本约200-240万。第一年因为要从零搭数据接入、建模、前端框架人员基本是满负荷。到了第二年系统进入迭代期团队可以缩到三个人接下来按每年150-200万预算计算。同时你还要考虑分析库、调度服务器、对象存储的网络和云资源费用一年保守按20-50万算。三年下来自研总成本我自己习惯这样估第一年4人×60万 基础设施30万 270万第二年3人×65万 基础设施30万 优化项目20万 245万第三年3人×70万 基础设施40万 新需求40万 290万粗算三年接近800万。这还是在团队稳定、没有大规模推倒重来的前提下。如果第一版技术选型失误比如查询引擎选型不对导致性能不足第二年回炉重写引擎成本会再增加一两百万。除了这些账面成本还有一个容易被忽视的机会成本业务部门从立项到真正用上自助分析等待了18个月。在这18个月里数据驱动决策是缺位的一些业务问题晚发现几周造成的损失有时候比系统本身的价格还高。4.2 采购BI的全周期成本模型采购方案要细算。以一家中等规模企业为例假设需要授权给80个活跃分析用户Power BI方案Pro授权少数Premium Per User一年订阅费大概小几十万。如果数据量特别大、需要Premium容量预留费用会更高。FineBI常见的企业订阅/私有化报价按并发数和模块包来算中等规模也是每年几十万到一百万区间。第一年还要加入实施与培训费用一般按license价格的比例来估20%-50%不等。每年还要预留二开与运维人天。即使采购了成熟产品内部也必须有人承担数据源维护、指标口径调整、新手答疑的角色这个角色可以不是全职但至少每年要占掉半个人的精力。按三年预估采购方案总成本大致结构是这样的成本项第一年第二年第三年License/订阅30万30万32万实施与培训10万2万2万二开与接口5万5万5万内部运维人天5万8万8万三年下来大约120-150万远低于自研的近800万。但这是只对比“投入”不对比“控制力”和“个性化收益”的结论。4.3 必须写进汇报里的三项隐性成本不管选哪条路有三项隐性成本我建议你们一定要写进立项报告里否则这个测算一定会失真口径维护成本无论自研还是采购业务指标口径统一都是要人来推动的。这个角色比开发还难招既要懂业务又要懂数据。用户培训成本再好的工具用户不会用就白搭。培训组织、答疑、操作手册编写的工时在两套方案里都存在。数据治理成本接入的数据质量差、脏数据多时BI做得越强大反而越容易让决策层看到一堆错误结论。数据清洗和治理的投入往往能占到整体项目成本的30%。5. 混合路线开源内核 自有前端正在成为性价比选项聊到现在你可能觉得我一直在“自研差采购好”这个二分法里绕。其实近几年越来越多团队开始走第三条路线只做自研中价值最高的那一层剩下的复用开源或采购组件。这个路线值得单独拿出来聊因为它的成本结构和风险特征跟纯自研、纯采购都不一样。5.1 什么是“半自研”的典型结构底层用Apache Superset、Metabase这类开源BI做数据探索和可视化也不排斥同时采购一个轻量级报表工具处理固定报表数据接入用开源的调度框架统一管前端面向管理层定制专属界面数据API自己开发。这样的好处是不再需要从零写多维分析引擎也不用自己维护图表库。前端团队可以把精力聚焦在公司想强调的体验和品牌上。还有一种常见组合是“采购成熟BI做分析引擎 自研门户做统一入口”。比如内部用Power BI做数据建模和自助分析但对外或对领导展示时将所有看板嵌入自研的门户系统通过API统一鉴权。这样既拿到成熟引擎的稳定性又可以拥有统一的交互入口性能和权限边界靠自研的API网关来兜底。5.2 开源内嵌不等于零成本人员门槛反而更高需要泼一盆冷水开源软件不是免费。部署Superset集群、扩展其缓存机制、实现单点登录、与内网权限体系打通、在大数据量下做查询优化这些都是实打实的开发工作而且开源社区的可参考案例远不如商业BI的文档体系完善。这时候你的团队需要有熟悉开源项目源码的技术骨干一旦遇到冷门bug基本只能自己读源码修。什么情况下适合混合路线我认为有两个充分条件你们有稳定的前端/后端团队但不打算养一个庞大的数据平台组你们的个性化需求集中体现在“展示层”或“交互层”而不是“分析引擎层”。如果核心诉求是分析引擎本身有特殊能力比如自定义聚合函数、复杂安全管控那开源加二次开发可能比商业产品更痛苦因为这等于把前面说的自研痛点重新捡了回来。5.3 混合路线的全周期成本估算混合路线的三年成本大概处于两者之间如果自研门户和集成开发投入约2人年加上云资源和开源组件维护三年总成本可能在三百万到五百万区间。它比纯自研省了最贵的数据引擎部分又比采购方案多了对体验和集成的控制权。我把三种路线的成本与风险对比做成了一个总表方便你直接拿去做汇报材料对比维度纯自研采购成熟BI混合路线三年总成本估算700-1000万120-200万中型规模300-500万上线时间8-18个月2-6周3-6个月数据引擎能力弱需长期打磨强中依赖开源交互和品牌控制力强弱强团队要求高需数据平台人才低内部有维护人即可中需全栈骨干主要风险人才流失、工程债厂商锁死、需求排期不可控开源组件停更、社区支持弱6. 大模型来了先别急着自研“Chat BI”最近半年越来越多团队受到另一个概念冲击既然大模型能写SQL了我们是不是可以用自然语言直接查数那还需要BI吗如果围绕这个话题做决策我见到不少团队因为想要“AI问数”功能而决定自研BI结果掉进一个更大的坑。6.1 自然语言查数没有想象中那么简单它需要“语义层”兜底直接让大模型连上数据库、用户问什么它就翻译成SQL这在几条数据的Demo里跑得很漂亮但到真实生产环境几乎必翻车。原因很具体业务库里的表结构通常以系统技术命名比如t_so_item、cust_code用户心智里的“华东区实际销售额”和SQL实体之间隔着一层复杂的业务语义映射。没有语义层做口径约束大模型会把“销售额是否含税”这种关键业务规则完全忽略掉。这也正是很多BI厂商这两年拼命做的事不只是做图表而是构建统一指标平台和语义层把“可查询字段、指标定义、维度关系、权限约束”沉淀成机器可读的元数据。大模型只是读这些元数据、生成SQL的入口真正的灵魂在于那个被精心治理过的语义层。而语义层的搭建和治理正是自研BI里最难、最累的部分。6.2 如果大模型问数被视为核心竞争力更需要谨慎很多团队对我说“我们要自研因为要把大模型问数做成产品差异化功能外面产品做不到我们要那么细。”这种诉求值得尊重但要注意大模型问数的价值必须建立在一个已经稳定运行的BI和指标体系之上。你连数据源接入、权限管控、指标口径都还没理清直接做AI问数相当于在流沙上盖高塔。我建议这类团队先这样分阶段走第一阶段用成熟BI或者开源BI把底层指标体系和权限模型建好第二阶段再叠加自然语言接口可以调用成熟厂商的AI能力也可以基于开源的RAG框架自己做。这时自研的工程量就从“从零写BI引擎”变成“在已有语义层上做接口包装”成本和风险都大幅下降。6.3 说回选型AI功能不会改变“自研还是采购”的基本判断逻辑大模型其实提高了对数据基础的要求而不是降低。换句话说如果自研的基本盘不成立别认为包装一个AI聊天框就能翻身如果采购方案能解决90%的看数需求那大模型功能只是锦上添花。把“大模型SQL能力”当成选型主线是本末倒置。7. 我给出的最终决策清单与落地顺序到了可以直接抄作业的部分。根据这几年的实战观察我不会给一个“非此即彼”的答案而是给你一套判断路径和落地顺序。7.1 先回答五个问题再谈买还是建业务方的真实需求是“固定看数”还是“自由探索”前者优先采购报表类工具后者才需要完整BI平台。你们内部有没有一个能长期负责数据口径、指标治理的负责人没有的话无论自研还是采购都会变成烂账。上线时间窗口能接受多久如果管理层要一个月内看到业务看板自研几乎可以出局。公司是否把数据分析能力定义为核心壁垒如果是做对外数据产品那自研底层有价值如果只是内部管理辅助采购更划算。数据安全合规是否限制数据出内网如果有限制优先考虑私有化采购或开源混合方案而非SaaS版。7.2 按团队类型给出偏好建议团队规模小、无专职数据平台组直接采购成熟BI配置一个兼职管理员即可。有前端后端团队但缺资深数据建模专家建议走混合路线采购或开源分析引擎自研轻量门户。有大厂背景的数据工程团队且业务复杂、个性化极强可以自研但必须从语义层开始设计而不是从图表开始。想借BI做对外产品输出第一版也建议用开源引擎快速搭脚手架验证市场后再逐步替换核心组件。7.3 落地顺序建议POC先行TCO复盘再签约或立项无论是自研还是采购都不要跳过POC阶段。POC不是让厂商演示精美的模板而是拿你们自己真实的业务场景去验证阶段一列出三个必须解决的业务场景写明需要的字段、维度、权限规则。阶段二给每个候选方案成熟BI、开源BI、自研方案一周时间做出对应原型。阶段三邀请业务关键用户打分重点看“我能不能自己完成”而不是“图好看”。阶段四把原型阶段暴露出的二开、配置工作量记录下来连同License报价、人力成本一起放进TCO计算表。阶段五再回头跟管理层确认时间窗口和预算范围最后做决策。这个顺序看似繁琐但能避免最贵的问题——方向错了越努力越亏。7.4 如果一定要自研第一版范围这样控最后给一个真自研团队的最小范围建议第一版只做固定报表 一个核心业务主题域的立方体模型 基于角色的粗粒度权限不要做强自助分析不要做大屏动画不要接超过三个数据源。把这些都砍掉的原因很简单自研BI最容易成功的方式不是功能丰富而是先让业务方在最小闭环里尝到甜头再逐步丰富边界。根据我个人的经验很多自研失败并不是团队技术不行而是第一版想覆盖的边界太广导致每个模块都只做了六十分。先用六十分做出一个稳定闭环把数据准确性跑赢让业务方愿意每天打开它再谈增加自助分析能力这个顺序比上来就做全能型BI要踏实得多。如果你现在正面临这个决策最值得做的一件事是拿起纸笔把不同方案的真实成本按三年维度列一遍再去跟业务部门做一次最朴素的需求访谈。别被“自研更自由”这个想法迷惑也别觉得“买了一定省心”。说白了BI的最终目的是让数据消费体验变好决策者和开发者的面子工程都不应该排在这个目标前面。