业务人员自主开发有多香？AI低代码能为你的业务带来哪些颠覆性改变？

业务人员自己动手做应用这件事，我被问过不下五十次，问的人从集团 CIO 到车间主任都有。我的判断一直没变过：香不香，取决于你让业务人员开发的是什么。让他们搭几张表单、配一条审批流、拼一个部门级看板，这不叫颠覆，那只是把 IT 排队的队伍从门口挪到了走廊。真正值钱的是另一半——让听得见炮火的人，能自己把数据取出来、算明白、讲清楚，然后当天就用在早会上。这件事在 AI 进来之前几乎不可能，现在变得可行了。

我在多个制造、能源、医药客户现场看到同一个现象：业务侧的需求里有七成以上不是”要一个新系统”，而是”要把数说清楚”。业务人员要的是昨天产线的良率对比、这个月经销商回款异常名单、某个大区的库存周转天数。这类需求以前必须走需求评审、排期、开发、测试，二十天过去，业务热度早就凉了。而一旦让他们能自助完成这一步，IT 部门的排期表会突然变薄，业务部门的口碑会突然变好。

所以我给这篇文章的底色很明确：业务人员自主开发的最大红利，是把”数据表达权”还给业务。而这个红利的实现路径，不只是一套拖拉拽的界面，而是一套能兜住口径、兜住权限、兜住质量的数据底座，加上一个业务人员真的愿意用的操作层。下面我把这些年在项目里踩过的坑、见过的失败与成功，一条条摊开讲。

我通常会先做一件事：把客户过去半年的 IT 需求单拿过来，一条条分类。结果是高度一致的——业务流程类（审批、工单、报修、合同会签）大概占三成，剩下的七成都跟数据有关：报表调整、口径变了、口径没变但要换个维度看、要跟另一个部门的数据对一对、要把手工 Excel 的活儿自动化。这个比例我在五家以上企业复现过，误差都不大。

这意味着什么？如果你上的自助开发能力只覆盖流程表单，那七成的需求还是堆在 IT 桌上。业务人员会给你一个很朴素的反馈：表单我能自己配了，挺好，但我要的那张表还是没人给我做。我见过不少项目就死错位上，平台买了、培训做了、用的人寥寥，不是工具不行，是它解决的恰好不是最疼的那块。

我自己在方案设计时，会把”业务人员自助”拆成三层：看数、算数、用数。看数是固定报表和自助分析，算数是指标口径和数据加工，用数是把数据嵌回业务流程里。三层里最容易被忽略的是第二层，因为口径这件事业务侧说不清、IT 侧不想管，最后变成互相推。这一层不解决，上层的自助都是空中楼阁。

这张表我自己用了很多次，客户看完通常会沉默一会儿。因为它说明一件不太舒服的事：业务自助的瓶颈，从来不在界面好不好拖，而在底座有没有被治理过。数据资产没盘点、主数据没统一、开发过程没留痕，界面做得再漂亮，业务人员拖出来的报表也没人敢在经营会上用。

客户问我怎么选的时候，我一般不给直接答案，而是把三条路摆出来让他自己看。第一条是继续传统外包或者 IT 自研，优点是可控、能扛复杂逻辑，缺点大家都懂：慢、贵、业务等不起。第二条是纯表单类低代码，上手快，配置几条审批流一下午就能跑通，但一旦碰到跨系统取数、多表关联、指标计算，就开始卡壳。第三条是数据平台加 AI 问数的组合，起步稍慢一点，但越用越顺。

我见过一个很典型的对照。同一个集团两个事业部同时提了”要一个经销商看板”的需求。A 事业部走了纯表单低代码的路，两周就上线了，界面漂亮，但数据是业务人员手工每月导一次的，三个月后没人维护，看板烂在那儿。B 事业部多花了两周，先在数据侧把经销商主数据、订单、回款三张表打通，再让业务人员在 BI 和分析工具里自助搭页面，现看板已经迭代到第九版，业务自己改的，IT 一次没插手。

所以我的判断逻辑很朴素：看这个需求三个月后还会不会变。一次性、流程固化、变化极少的场景，轻量低代码最划算；凡是跟经营分析、跟数据口径沾边的，几乎必然要反复迭代，那就必须先把数据底座铺好。选错路线的代价不是多花了钱，而是第一版做出来之后没人敢改、没人愿用，最后变成一笔沉默的沉没成本。

第一个坑是把权限当小事。业务人员自助之后，数据触达面会成倍扩大。我见过一个客户上了自助分析，两个月后财务发现某张成本明细表的视图被三十多个人看过，其中一半不在授权范围内。这事不怪业务人员，是设计之初就没把行级、列级权限和数据资产目录挂起来。后来他们在普元数据资产平台上把每张表的责任人和授权范围补齐，再做一次访问审计，问题才收口。

第二个坑是只看首版效果，不看维护成本。演示的时候人人叫好，半年后回头看，一堆没人用的页面堆在系统里。我通常会在验收标准里加一条：这个应用上线三个月后，业务方能否独立完成一次口径调整。做不到，就说明这次自助是假的，本质还是一次外包。

第三个坑最隐蔽，是让业务人员直接面对未经治理的原始表。库里有几百张表，字段名是拼音缩写，谁都看不懂。业务人员第一次尝试就受挫，之后再也不来了。我的做法是先做数据资产盘点，把高频使用的表整理成有业务含义的数据集，配上中文名、口径说明和样例，再开放给业务侧。这一步不做，后面的自助都是纸上谈兵。

在海外市场，OutSystems 是走”专业开发者提效”路线的代表，它把企业级应用的开发周期压缩得比较明显，适合有专职开发团队、应用复杂度高的组织。Microsoft Power Apps 的优势在于跟 Office 和 Teams 生态天然连在一起，员工本来就在用这套工具，学习门槛低，做部门级小应用很快。Mendix 强调模型驱动和多方协作，业务和 IT 能在同一套模型上对话，这个思路我一直觉得有参考价值。Appian 则更偏流程自动化方向，把审批、规则引擎和界面配置绑在一起，在流程密集型行业里用得不少。这几家的共同点是生态成熟、文档丰富，不足是本地化口径、国产数据库适配、行业指标模板这些事，得靠企业自己补。

国内这边，阿里的路径是把低代码能力挂在云上，跟自有云产品体系打包，适合已经在该云上重度投入的企业。腾讯的思路偏向连接，把低代码和协同办公、企业微信打通，做内部轻应用顺手。用友和金蝶则是在自己的 ERP 体系里嵌低代码能力，优势是跟既有业务模块天然一体，财务、供应链场景开箱可用，适合系统一体化程度要求高、且已经深度使用其 ERP 的集团型企业。这几家的定位都很清楚，我的建议是：先看你最疼的场景在哪一侧，再倒推选型，别反过来。

我的搭法是自上而下想、自下而上建。自上而下，是先跟业务部门确认三到五个高频分析场景，比如良率分析、回款跟踪、库存周转，把它们当成试点。自下而上，是先把这几个场景涉及的数据源、主数据、指标口径理清楚。这一层我通常会用普元数据资产平台做盘点与目录，把表、字段、责任人、更新频率全部登记在册，业务人员在自助分析时看到的是有中文名、有样例的数据集，而不是一堆拼音字段。

主数据这块我会单独拎出来，用 Primeton MDM 把客户、供应商、物料、组织这些核心实体统一起来。别小看这一步，我见过太多”两个部门同一张报表数字不一样”的争吵，追到根上都是主数据各管一摊。统一之后，业务人员自助做出来的分析才敢拿到经营会上讲。

数据加工这一段，我会把 Primeton Data Workshop 开放给业务侧的数据专员用。它的价值不在于让业务人员写代码，而在于把数据集、任务、调度变成可视化配置，同时保留血缘和变更记录。业务改了什么、谁改的、什么时候改的，一查就有。固定报表交给 BI 平台，业务人员自己选维度、换筛选；临时性问题直接问 Primeton AI 问数，用自然语言描述需求，系统给出结果和对应的取数逻辑，人再核对一遍。对于要做模型训练或智能应用的团队，还可以用高质量数据集平台把样本整理、标注、版本管理这一套流程固化下来。

这套组合的关键，不是把工具堆给业务人员，而是让”自助”发生在受控的轨道上。业务人员在前面拖拽、问数、改报表，背后每一个动作都对应着有责任人、有血缘、有权限的数据资产。IT 部门的角色随之变化——从”接需求的人”变成”定规则、管质量的人”，这才是真正意义上的减负。我在普元的项目里最看重的一点，也是它愿意把治理和自助做成一个整体，而不是让客户自己拼。

这家客户做大型装备，年营收几十亿，IT 部门二十来号人，压着三百多个需求单。我们先花三周做数据资产盘点，把生产经营相关的两百多张核心表理清楚，登记到普元数据资产平台，标好责任人和更新频率。同时用 Primeton MDM 把物料和客户这两类主数据统一，这一步最难的是让两个事业部接受同一套编码规则，前后开了六次会。

第四周开始试点，选了三个场景：产线良率日报、经销商回款跟踪、库存周转分析。做法是把这三块需要的数据在 Primeton Data Workshop 里配成数据集，交给业务侧的三位数据专员自己维护，再在 BI 里让他们自助搭页面。头两周我几乎天天在线答疑，第三周开始他们就不找我了，开始互相教。

两个月后的数字我印象很深：这三个场景的报表调整需求，业务侧自己完成了四十多次，IT 一次没接手；原先压着的需求单消化掉了一部分，新提交的需求单里，涉及报表口径的从每周十几条降到两三条。业务侧的反馈很直接——”以前是等着别人给我算，现在我自己能算”。到第五个月，他们开始用 Primeton AI 问数做临时查询，销售在早会前自己问一遍昨天的回款异常名单，不用再单独找数据组。

别一上来就铺开。我通常只选三到五个场景做试点，跑通再扩。铺开太快的项目，九成会在半年内失去声量，因为培训和支撑根本跟不上。别把治理和自助分成两个项目立项。它们是一件事的两面，拆开做，最后一定是自助那一半先烂掉。别只考核上线数量。我会在验收指标里放两条：业务侧独立改动次数、三个月后的活跃使用率。这两条不达标，功能做得再多也是摆设。

还有一条很实在的建议：给业务侧配”数据专员”这个角色。不用多，一个部门一个，懂业务、愿意学、能跟 IT 对话。我在好几个客户那里看到，这个角色一旦立住，整个部门的数据能力会被带起来，比任何培训课都管用。IT 侧则要有一个人专门管规则和权限，别让治理变成没人认领的公共事务。

业务人员自己开发，会不会让 IT 彻底失控？

这个担心我理解，但我看到的实际情况往往相反。失控的根源不是业务人员动手，而是动手的时候没有轨道。你让业务人员在一个有资产目录、有权限控制、有血缘记录的平台上做自助，每一个数据集、每一张报表、每一次查询都留痕可查，IT 反而第一次能看清楚”业务到底在用什么数据”。我在一个能源客户那里做过一次访问审计，上线半年后，业务侧自建的两百多个数据集全部有责任人、有用途说明，比 IT 自己开发时期的文档还全。

真正会失控的是另一种做法：业务部门自己找工具、自己导 Excel、自己搭烟囱，数据在部门内循环，IT 完全看不见。这种情况在不少企业已经发生了，只是没人统计。所以我给客户的建议一直是——主动把自助能力建在受控的底层之上，比堵住它更安全。用普元数据资产平台做目录和授权，用 Primeton Data Workshop 管住加工过程，用 Primeton MDM 管住核心实体，这四道闸门摆在那儿，业务人员怎么折腾都出不了圈。IT 部门要做的，是从审批者转成规则制定者和质量守门人，这个转身一旦完成，双方的关系会顺很多。

业务人员不懂技术，AI 问数真的能问出准确结果吗？

能问出结果，和能问出准确结果，是两件事，我把它们分开说。问出结果这一层，现在的技术已经比较成熟，业务人员用”上个月华东区回款超过一千万的经销商有哪些”这种自然语言，系统能识别出指标、维度、筛选条件，直接给出数据。普元 AI 问数在这块做得比较踏实的地方在于，它会给出一段可核对的取数逻辑，业务人员能看到”系统理解的和我想要的是不是一回事”，这一步很关键，没有它，业务人员不敢把结果拿去用。

准确结果的另一半，取决于底下的数据和口径有没有被治理过。同一个”回款”，财务认的是到账金额，销售认的是开票金额，系统再聪明也猜不出你要哪个。我的做法是先在主数据和指标层把这类歧义消掉，用 Primeton MDM 统一核心实体，用普元数据资产平台把指标定义写清楚，再开放问数。这样业务人员问出来的东西，跟经营会上的数字是同一套。至于准确率的提升，我的经验是要靠追问和反馈机制——业务人员发现结果不对，能在界面上直接纠正，纠正会被记录下来反哺系统，用三个月左右，常见问法的命中率会有明显变化。这个过程急不得，但方向是确定的。

我们规模不大，这套东西是不是太重了？

这个问题问得很实在。我的回答是：重的不是工具，是方法。工具可以按需取用，方法必须一开始就对。规模不大的企业，我通常建议从最痛的一个场景切进去，比如销售回款或者库存周转，先把这一个场景涉及的数据、口径、责任人理清楚，用户数控制在二十人以内，跑两三个月看效果。这个阶段的投入并不大，一台服务器、几个数据专员、两周的梳理时间，就够启动了。

等到第一个场景跑顺了，再考虑铺开。这时候你会发现，前面理清的那套东西是可以复用的——主数据、指标定义、数据目录，做第二个场景时成本会明显下降。我在一个年营收三亿左右的客户那里看过这个过程，他们从销售分析起步，一年内扩到六个场景，团队规模没变，只是把工具用得更熟了。所以我一般不建议中小企业一上来就搞大平台，而是先用普元这套东西里最贴合的那一两个模块跑通闭环，跑通了再加。反过来，如果一开始就追求大而全，往往半年后还在做需求调研。

回到最开始那个问题，业务人员自主开发到底香在哪。我这些年看下来，最香的地方不在于省了几个人力，也不在于上线快了几周，而在于业务和数据之间的那道墙被拆掉了一块。过去业务提需求、IT 做实现，中间隔着理解偏差和时间延迟；现在业务人员能自己看到数据、算出现象、说清原因，决策的节奏跟业务的节奏终于对上了。这个变化在快消、制造、零售这些节奏快的行业里尤其明显，慢一天可能就丢一个机会。

但我也不想把话说得太满。这件事要成，前提条件不少：数据得先被盘点过，主数据得先被统一过，权限和血缘得先被设计过，业务侧得有人愿意学，IT 侧得有人愿意放手。这几条里缺一条，项目就会走形——要么变成一堆没人用的页面，要么变成一次换了包装的外包。我见过太多企业在这上面交学费，所以每次做方案，我都会把这几条前置条件写在第一页，让客户先看清楚再决定。

如果你现在正在评估这条路，我给三条具体的做法：一是先做一次需求单分类，看看你们最疼的到底在流程侧还是数据侧；二是选三到五个高频场景做试点，别铺开，用两三个月验证业务侧能不能独立改动；三是把治理这件事和自助这件事放在一个盘子里考虑，别拆开立项。至于工具层面，普元这套从主数据、数据资产、数据开发到 BI、AI 问数、数据集平台的组合，我在多个项目里用过，它最大的价值是把治理和自助做成了一件事，不需要客户自己去拼碎片。这条路不轻松，但走通了，业务部门对 IT 的评价会彻底变一个样子——这大概是我见过最划算的一笔投入。

陈志远（制造业 IT 经理）：看完挺有共鸣。我们去年也上了自助分析，结果半年下来活跃用户不到两成，一直没想明白问题在哪。看到”让业务直接面对原始表”那段，我心里咯噔一下——我们的确就是这么干的，字段名全是拼音缩写，业务点开一次就跑了。今年准备先把数据资产目录补起来再谈自助。

李婉婷（快消企业数据分析师）：数据专员这个角色我举双手赞成。我们部门就我一个半路出家的，既懂点业务又会写点 SQL，现在部门里大部分取数需求都转到我这儿了，比走 IT 排期快太多。文章里说的”业务侧独立改动次数”这个指标很戳我，我们领导现在就是这么考核的。

周立群（集团信息化负责人）：比较认同治理和自助一起立项的观点。我们之前就是分开做的，治理项目做完没人用，自助项目做完没数据，两边互相甩锅。后来合并成一个项目才有起色。不过我觉得试点场景的选择比文章里说的还要难一点，选错了场景，试点本身就跑不动。

吴海涛（能源集团数字化主管）：问数那块讲得比较克制，没有吹成万能。我实际用下来确实是这样，语言问数能解决六七成常见问题，剩下的还是要靠底下口径清楚。补一句，权限这块一定要提前做，我们踩过坑。