一件球衣的众创实验，戳中了数字化项目的软肋
最近，一家英超俱乐部做了一件挺有意思的事：他们把新赛季第三球衣的设计权，交给了一群普通的球迷。借助AI绘图工具，没有受过专业训练的球迷也能在几分钟内生成草稿、调整配色、提交方案，最终胜出的作品会被真正生产出来，穿上球场，也摆上货架。
很多人把它当成一次成功的营销案例来看。但如果换一个视角，这其实是一次组织能力的展示：让最终使用者直接参与到产品的定义环节中，并且用工具把参与的門槛降到几乎为零。
这恰恰是绝大多数企业在做信息化、做数字化转型时最缺失的一环。我们见过太多公司，花几十万采购一套ERP，或者投入半年时间定制开发一套CRM，上线三个月之后，一线员工又开始偷偷用回Excel。问题往往不出在技术，而出在——真正的使用者，从头到尾没有参与过设计。
需求传递链越长，系统离业务越远
传统的信息化项目是怎么做的？大致是这样一个链条：一线员工有痛点 → 部门主管整理成需求 → IT部门或产品经理写成文档 → 外包团队或开发人员实现 → 上线后一线员工发现不好用。
三次转译，三次失真
- 第一次失真：员工说”我要能快速查到这个客户的跟进记录”，到了主管那里变成了”需要客户信息查询模块”，具体的查询维度、响应速度、移动端需求全部丢失。
- 第二次失真：需求文档写成了功能清单，开发方看到的是”字段、表单、列表、权限”，而业务场景里那些不成文的习惯——比如销售习惯先看微信聊天记录再看系统，比如仓库管理员习惯用手机扫码而不是电脑录入——一条都没写进去。
- 第三次失真：系统上线，流程被固化成了设计者想象中的样子。员工发现要多点五次鼠标才能完成过去三秒钟的动作，于是开始绕过系统。
链条每长一环，信息就损耗一层。到最后，系统成了给老板看的仪表盘，而不是给员工用的工具。这也是为什么大量企业的ERP项目最终沦为”数据录入系统”，CRM沦为”客户名单保管箱”。
反过来看那场球衣大赛，逻辑是反的：使用者就是设计者，中间没有转译环节，需求不需要被翻译，它直接就是作品本身。
AI和低代码，正在把”造工具的权力”还给使用者
过去我们说”让业务人员自己开发系统”，听起来像天方夜谭。但现在这件事的门槛正在快速坍塌，主要来自三个方向。
第一，自然语言正在成为新的”开发界面”
表单、流程、报表这些企业系统里最占工作量的部分，如今可以通过描述来生成初稿。业务人员说清楚”我要一个什么场景、谁在什么条件下做什么、结果怎么统计”，系统就能给出可用的原型。原型可以被讨论、被推翻、被修改，比一沓五十页的需求文档效率高得多。
第二，AI Agent 开始承担那些”必须进系统但又很烦”的动作
企业数字化最尴尬的地方在于：系统要求数据完整，但员工没时间填。AI Agent 开发的价值就在这里——它可以读取邮件和聊天记录自动生成客户跟进纪要，可以在订单状态变化时主动提醒相关人，可以用自然语言回答”上个月华南区哪些客户流失了、原因是什么”。员工从”给系统喂数据的人”变成”向系统要答案的人”，使用意愿自然就上来了。
第三，触点形态已经足够丰富
不是所有业务都适合打开电脑登录后台。门店导购需要的是小程序开发出来的轻量工具，外勤人员需要的是APP开发出来的移动端，经销商和供应商需要的是浏览器直接打开的网页端。深圳网站建设行业这两年的明显变化是，客户不再只问”做个官网多少钱”，而是问”这个页面能不能直接对接我们的订单系统”。惠州网站开发的项目里，也越来越多出现”官网+小程序+后台管理”打包需求，本质上就是企业在补自己的数字化触点。
工具门槛降下来之后，企业才有条件去复制那场球衣大赛的逻辑：让懂业务的人直接参与”造工具”，而不是被动等待工具。
共创不是让业务部门自己干，而是重新划分责任边界
说到这里必须泼一盆冷水。很多企业一听”业务人员自己搭系统”，第一反应是裁掉IT部门。这是误解，也是灾难的开始。
真正的共创，是把工作重新切分：
- 业务一线负责”定义场景”和”验收效果”。他们最清楚哪个环节最耗时、哪种客户最容易丢、哪张报表没人看。他们不需要会写代码，但需要能用原型工具表达清楚自己想要什么。
- IT部门或外部服务商负责”架构、集成、安全、性能”。数据放哪里、和老ERP怎么打通、权限怎么分级、并发上来会不会崩，这些是专业活，不能让业务人员凭感觉决定。
- 管理层负责”规则”。数据口径统一不统一、跨部门共享的边界在哪里、谁能改谁能看，这些是治理问题，必须由高层拍板，否则共创会变成各自造烟囱，最后数据更加割裂。
换句话说，共创改变的不是”谁来干活”，而是”谁来决定做什么”。决定权交给离业务最近的人，实现权交给最专业的人。
四条落地建议，给准备动手的企业
1. 别从核心系统开刀，先找一个”低风险、高频次”的场景
不要一上来就重构ERP。选一个参与人数不多、失败成本可控、但每天都被抱怨的场景——比如报销、巡店打卡、售后工单派发、样机借还——用两三周做出可用版本，让参与者亲眼看到”我的意见真的改变了系统”。这种正向反馈比任何动员会都有效。
2. 用可点击的原型代替需求文档
让业务人员对着屏幕说”这里不对、这个字段应该放前面、这个按钮我不用”，远比让他们写需求描述要准确。原型评审会开三次，比需求评审会开十次管用。
3. 培养几个”业务翻译官”
每个部门挑一到两个既懂业务、又不排斥新工具的人，作为内部种子用户。他们不需要成为开发者，但需要能把同事情绪化的抱怨，转化成结构化的场景描述。这批人是共创能否持续的关键。
4. 数据治理要走在智能应用前面
如果客户资料重复、物料编码混乱、订单状态定义各说各话，那么再聪明的AI Agent也只能在脏数据上得出错误答案。先把主数据口径统一，再谈智能分析，顺序不能反。
写在最后：数字化转型的主角，从来不是系统
那场球衣设计大赛真正值得借鉴的，不是”用了AI”这个标签，而是一种姿态：把决策权交给最了解需求的人，把工具做得足够简单，让参与成为一种表达而不是负担。
企业做信息化、做系统定制，道理完全一样。一套ERP能不能跑起来，取决于仓库管理员愿不愿意扫码；一套CRM有没有价值，取决于销售愿不愿意在里面记录真实进展；一个小程序好不好用，取决于顾客愿不愿意第二次打开。这些都不是技术指标，而是参与度指标。
作为长期服务企业数字化建设的团队，微商派（vsppt）在做的其实就是把这些环节衔接起来：从前端的深圳网站建设与惠州网站开发，到移动端的小程序开发与APP开发，再到后端的ERP/CRM系统定制与AI Agent开发，我们不主张关起门来交付一套”功能齐全”的系统，而是更愿意先花时间走到业务现场，把一线员工的不满意变成可执行的原型，用快速迭代的方式让系统长成业务真正需要的样子。
技术会一直变，工具会越来越聪明。但数字化能否落地，最终仍然取决于一个朴素的问题：那些每天使用它的人，有没有被邀请参与设计它。