本文共字，预计阅读时间。

本文为证券行业数智化转型系列观察第二篇，第一篇为：《“微操大师”要不得！论数智化转型中的指挥关系——证券行业数智化转型系列观察（一）》

各位数智化转型的同仁们，当前大语言模型的浪潮席卷而来，市场上一片生机勃发，但许多企业内部却陷入困境：项目失败、上线无人用、数智化进程停滞不前。大家从战略、文化、组织、人才等角度反思，原因纷繁复杂。但如果你是公司数字化转型负责人，条件只允许你解决一个问题，你会优先解决哪个问题？

毛泽东同志说过打仗要“抓住战略枢纽去部署战役，抓住战役枢纽去部署战斗”，总有一些关键局部对全局会起到决定性作用，那对于企业数智化转型来说，这个枢纽是什么呢？

问题不在技术，也不在预算，不在人才，也不在协同，而在于项目从第一天起就把“领导满意”当终点，而非“业务指标”真动了没有。 所谓求仁得仁。

这篇文章，我想结合证券行业的实践，回答一个简单问题：怎样让每一次迭代、每一行代码、每一张PPT、每一个Prompt，都必须先对着“战果”交账，否则就地叫停？

如果你也受够了“汇报即巅峰”、“立项即失败”的循环，不妨继续往下看。

一、把镜头拉到朱日和：演习如果变成“汇报片”，打仗必流血

首先，我们将视野稍微挪开一下，来看看军队军改前后的对比，可以非常好地展现当下数智化转型所遇到的问题。

《突出重围》和《沙场点兵》等影视作品就非常突出地反映了军改前军队在演习中存在的突出问题。朱日和基地早年的演习，导演部把脚本写到“分钟级”：红方炮火几时几分覆盖，蓝方几时几分退却，连“阵亡”士兵倒地的姿势都预先彩排。一位旅长私下吐槽：“仗还没打，输赢早写在红头文件上。”

演习按照预案走，甚至有时候分秒不差，《突出重围》电视剧片段

“练为看”、“演为看”、“演习成了演戏、作训成了作秀、谋战成了谋官”。这与某些券商的“数智化”何其相似：

• 项目启动会上，领导一句“我们要做行业一流的智能投顾”，OKR却只有一个“系统上线”节点；
• 项目组996三个月，上线当天锣鼓喧天，两周后日均访问量几乎降为0；
• 汇报PPT里“AI赋能”字样出现了18次，股基交易量、客户留存率却纹丝不动。

太多公司的数智化转型形式主义横行，为什么要转型没想清楚，数智化项目和业务脱节，汇报代替了实际成果验证，数智化转型变成了某些人谋取政治资本的手段，如此下去，数智化转型不失败才怪。

数智化转型和军事演习看似风马牛不相及，但是他们有着一个共同的特点，就是效果不是直接显现，不好简单地进行评估。比如演习是为了更好地打仗，但是毕竟不是实战，实战赢了就是赢了，输了就是输了，一目了然，那么演习如何最大化地服务于实战就成了各级指挥官首当其中要解决的问题。数智化转型也是如此，绝大部分都是服务于业务，但它又不直接产生业务收益，所以如何将数智化转型和公司的业务战略进行有机的关联是企业在开展数智化转型时首先要明确的问题。

军改后，军委把“演习评估权”从导演部交给“第三方蓝军”，胜负唯一标准：40小时内能否歼灭对方主力。于是出现了蓝军零下30℃雪地穿插300公里，端掉红军司令部的一幕。导演部不再喊“停”，因为“实战不会喊停”。

映射到金融企业：谁掌握“评估权”，谁就掌握“是否真打”的话语权。如果评估权仍在“立项部门”自己手里，“自导自演、自演自评”，数智化就永远走不出“汇报片”套路。

因此，我们认为企业数智化转型要解决3个层面的问题：

1. 主要矛盾：是“战略懒惰”，还是“战术勤奋”？为数智化转型设定合理的目标及如何实施，即侧重于Why和What，而不是How。
2. 方法论：建立以“假设验证”为中心的迭代闭环。建立“战果→假设→验证”的闭环。
3. 灵魂与保障：“批评与自我批评”的战斗文化。

二、主要矛盾：是“战略懒惰”，还是“战术勤奋”？

自从今年春节DeepSeek引发新一轮的大语言模型热潮以来，特别是在国家各项政策的加温下，各家企业可谓闻风而动，对于AI相关的重视程度越来越高，不管是参与的层级，还是投入的资源。有企业提出“All in AI”，也有企业为各类算力资源的采购大开绿灯，一派繁忙热闹的景象。

但是，大半年过去了，很多公司AI相关项目却并没有带来明显的成效，有些项目还在为上线苦苦挣扎，还有些项目即使上线了，业务部门却没人用，或者离最初的效果设想差个十万八千里。症结到底在哪呢？

我认为，问题的根源不在于战术执行的快慢，而在于战略思考的深浅。太多企业陷入了一种“战略上懒惰，战术上勤奋”的怪圈，且乐此不疲。

所谓的“战术勤奋”，是指在项目“如何实现”（How）的层面，大家极其努力。团队遵循着敏捷开发的流程，UI/UX设计师精心打磨每一个像素，工程师们夜以继日地编写代码，项目经理严格把控着交付时间线（Deadline）。这一切看起来都高效而专业，但这本质上是一种“工程师思维”的快速迭代，其核心目标只是“多、快、好、省”地把功能做出来。

而“战略懒惰”，则是指在项目“为什么做”（Why）和“做什么”（What）的层面，缺乏足够深刻的洞察和严谨的验证。公司或业务线层面，只说“我们要All in AI”，却回答不了“智能体带来多少新增客户”、“AI带来多少两融利息收入”。一个需求，可能仅仅源于领导的一次“灵感闪现”，或是对竞品某个功能的简单模仿。在接到任务后，团队未经充分的商业价值论证和用户需求验证，就立刻“假设”它是正确的、是值得投入巨大资源的。于是，一场轰轰烈烈的战术行动开始了，而其战略基石却脆弱不堪。

这就好比一支部队，拥有最先进的武器装备，士兵训练有素，行军速度极快，但假若指挥部给出的作战方向本身就是错误的，那么部队越是“勤奋”，其行动效率越高，离真正的胜利就越远，甚至可能是在南辕北辙。

AI的发展，尤其是AIGC技术的普及，在某种程度上加剧了这个问题。它极大地降低了“战术勤奋”的门槛，一个应用原型、一套宣传物料，过去需要数周才能完成，现在可能几小时就能生成。这种“战术上的轻易获胜”感，更容易麻痹我们，让我们沉溺于创造的快感中，而忘记了发问：我们创造的这一切，真的有人需要吗？真的能解决问题吗？

因此，我们必须清醒地认识到，数智化转型的核心矛盾，不是技术实现的速度不够快，而是价值验证的速度不够快。打破僵局的关键，在于将组织的注意力从单纯追求交付速度，转移到追求认知迭代的速度上来，建立一套真正以商业价值为核心的迭代机制。

三、方法论：建立“战果→假设→验证”的闭环，让每一次迭代都“见红”

要破解“战略懒惰”的困局，就必须建立一套全新的作战体系，我们称之为“以假设验证为中心的迭代闭环”。这个闭环摒弃了过去那种“领导拍板、下属执行、闭门造车”的瀑布式或伪敏捷模式，将每一次迭代都视为一次科学实验。其核心不再是交付功能，而是验证假设。这个闭环由四个紧密相连的环节构成，缺一不可。

3.1 高质量立项：明确作战目标与核心假设

立项要解决两个核心问题：立项决定权在谁手里、为什么立项。任何一个数智化项目，在启动之初，必须回答两个根本性问题：

1、战果指标——只认“硬通货”。明确的作战目标是什么？ 这不是一个模糊的“提升用户体验”或“实现降本增效”，而是一个可量化的、具体的业务指标。例如，“在未来三个月内，通过优化推荐算法，将核心用户的平均购买转化率从3%提升至4%”。

2、核心假设——一句人话。支撑该目标的核心假设是什么？ 即我们认为通过何种方式能够达成这个目标。例如，我们的核心假设是：“当前用户转化率低的主要原因是推荐商品与用户兴趣不匹配，如果能利用新的协同过滤算法，更精准地推送用户可能感兴趣的商品，转化率就会提升。”

很多项目，罗里吧嗦写了一大堆文档，立项时提交一份厚厚的、面面俱到的需求文档（BRD/PRD），但是最重要的核心假设却描述不清楚。立项文档应侧重于一份简洁的“假设-验证”清单，它清晰地列出了项目的所有前提假设，并明确了衡量这些假设是否成立的数据指标。这个步骤如同战前制定作战方案，明确主攻方向和胜利标准，是所有后续行动的基石。没有这个基石，项目就如同在黑暗中行军，不知道方向，更不知道何时抵达终点。

另外，在很多公司的立项过程中，还容易犯以下三类错误。

错误一：领导定的项目一定正确

在许多企业的决策流程中，存在着一种根深蒂固的“权威崇拜”文化。当一个项目由高层领导，尤其是一把手拍板决定时，它往往就被赋予了“正确性”的光环，项目团队很少会，也不敢去质疑其背后的商业逻辑。大家默认领导站得高、看得远，其决策必然是基于更全面的信息和更深刻的洞察。然而，这种假设在瞬息万变的数智化时代是极其危险的。领导者的决策同样可能受到信息滞后、认知局限或个人偏好的影响。将一个未经充分论证和验证的项目直接推向执行层，这异于一场冒险的赌博。项目团队因为不敢或不愿挑战这个“正确性”假设，便放弃了在立项初期进行充分“Why”和“What”探讨的机会，导致项目从一开始就埋下了失败的种子。

错误二：探索性项目需验证

另一类常见的项目是所谓的“探索性项目”或“创新项目”。这类项目往往因为其“探索”的属性，而被赋予了某种“免责金牌”。项目团队和管理层普遍认为，既然是探索，就意味着结果是不确定的，因此无需像常规项目那样进行严格的商业论证和阶段性验证。这种心态导致项目在立项时目标模糊，缺乏明确的衡量标准，最终演变成一场漫无目的的“技术秀”。团队成员沉浸在追逐最新技术的快感中，却忘记了探索的最终目的是为了找到可行的商业路径。没有验证机制的探索，就像一艘没有罗盘的船，在茫茫大海中随意漂泊，即使偶然发现了新大陆，也更多是运气的成分，非方法论的成功。这种对探索性项目的错误认知，使得大量资源被消耗在毫无方向的技术尝试上，最终鲜有能转化为实际商业价值的成果。

错误三：技术先进等于商业成功

在数智化转型的热潮中，许多企业陷入了一种“技术崇拜”的误区，错误地将“技术先进性”与“商业成功”划上了等号。他们认为，只要采用了最前沿的技术，比如人工智能、区块链、元宇宙等，项目就必然会成功。这种假设导致企业在立项时，往往是从技术出发，而不是从业务需求出发。他们会问：“我们能用AI做什么？”而不是“我们的业务痛点是什么，AI 能否有效解决它？”这种本末倒置的做法，催生了许多“为了 AI而AI”的项目。这些项目虽然在技术上可能颇具亮点，但由于没有切中业务的要害，无法为用户创造真正的价值，最终往往落得“叫好不叫座”的下场。技术只是实现商业目标的工具，而非目标本身。一个项目的成功与否，最终取决于它是否解决了实际问题，是否创造了商业价值，而不是它使用了多么炫酷的技术。

3.2 过程验证：最重要的任务是侦察

立项完成后，项目便进入实施阶段。在传统模式下，这个阶段的重心是“开发”；但在“假设验证”闭环中，这个阶段的重心是“侦察”——即通过最小可行性产品（MVP）、用户访谈、数据埋点分析等一切手段，去持续不断地验证我们在立项阶段提出的核心假设是否正确。

工程师们固然要写代码，但他们的首要任务不是构建一个大而全的“完美系统”，而是以最快的速度搭建一个能够用于收集真实世界反馈的“实验装置”。这个过程需要团队深刻理解《资治通鉴》中的智慧：“将在外，君命有所不受”。这里的“君命”，就是我们最初立项时的“核心假设”。如果前线侦察回来的情报（用户数据、市场反馈）表明，“君命”可能是错的，那么前线指挥官（项目负责人）就必须有权、也有责任，及时向上级提出调整作战方案的建议，而不是为了所谓的“执行力”而盲目地冲锋陷阵。

例如，在上述推荐算法的项目中，团队快速上线了一个仅针对1%用户的MVP版本。一周后数据表明，新算法的转化率不但没有提升，反而略有下降。这就是最重要的“侦察”情报。此时，团队的任务不是去优化代码，而是立刻深入分析用户行为，访谈被测试的用户，找出假设不成立的真正原因。是因为算法逻辑有问题？还是因为UI展示方式不被接受？或者，我们最初“转化率低是因为推荐不准”这个根本假设就是错的？

3.3 科学评判：用战果和数据说话

一个项目或一个迭代阶段的成功与否，其评判标准绝不能是“领导是否满意”，也不能是“功能是否按时上线”，唯一的标准应该是“战果”——即我们在立项阶段定下的那个可量化的业务目标，是否通过真实的数据得到了验证和达成。

很多项目的汇报，从头到尾都是精美的PPT，讲述着团队付出了多少努力，克服了多少困难，最终“圆满”完成了系统上线。这是一种可悲的自欺欺人。用数据说话，意味着我们要建立客观、公正的度量体系。成功了，要拿出数据证明，是哪个指标提升了，提升了多少；失败了，同样要用数据说话，告诉大家我们的尝试没能带来预期的结果。

这种以数据为准绳的评判文化，能够最大程度地挤压“办公室政治”的生存空间，让所有人的努力都聚焦于为最终业务结果负责。一个不看功劳（effort）只看苦劳（results）的评价体系，才能真正筛选出有价值的项目，淘汰掉那些只是看起来很美的“花瓶”。

3.4 严肃复盘：打明白仗，而非糊涂仗

无论是成功还是失败，每一个迭代周期结束后，都必须进行一次严肃的复盘。复盘的目的不是为了“秋后算账”，追究责任，而是为了打明白仗，将经验和教训沉淀为组织的肌肉记忆。

复盘要回答以下几个关键问题：

• 我们最初的假设是什么？
• 最终的结果是什么？数据告诉我们什么？
• 是什么导致了成功/失败？是我们预料之中的，还是意料之外的？
• 从这次迭代中，我们学到了什么关于用户、市场或技术的认知？
• 基于这些认知，我们下一步应该如何调整我们的假设和行动计划？

一次成功的试错，其价值不在于“错”，而在于“试”的过程让我们收获了宝贵的认知，从而避免了在错误的方向上进行更大的投入。而一次失败的试错，则是连失败的原因都没有搞清楚，下一次依然在同一个地方跌倒。严肃、深刻的复盘，正是区分这两者的关键。它要求团队成员，尤其是项目负责人，具备极大的勇气和诚实，敢于直面失败，解剖自己，从而为下一次迭代打下坚实的基础。

四、灵魂与保障：“批评与自我批评”的战斗文化

如果说“假设验证”的迭代闭环是数智化转型的作战方法和先进武器，那么“批评与自我批评”的文化，就是驾驭这套体系的战斗意志和组织灵魂。没有这种文化作为保障，再精妙的流程设计也只会沦为僵化的形式主义，最终形同虚设。

4.1 要敢于说真话，不要无意义的一团和气

在项目推进的各个环节，从立项的假设讨论，到过程中的问题分析，再到结束后的复盘总结，都极度依赖于团队成员能够基于事实和数据，进行开放、坦诚、甚至尖锐的交流。我们需要的是“诤友”，而不是“好好先生”。

当项目负责人兴奋地阐述一个新想法时，需要有人冷静地提出：“这个方案的核心假设是什么？我们有什么初步的数据可以支撑它吗？如果假设不成立，最大风险是什么？”当一个迭代的数据结果不理想时，需要有人敢于指出：“我认为问题的根源可能在于我们对用户场景的理解出现了偏差，而不是技术实现的问题。”

这种“说真话”的文化，尤其考验组织的雅量。它要求我们摒弃那种“枪打出头鸟”、“一团和气”的陈腐观念。正如毛泽东同志所指出的：“盲目地表面上完全无异议地执行上级的指示，这不是真正在执行上级的指示，这是反对上级指示或者对上级指示怠工的最妙方法。” 表面上的意见一致，往往掩盖了深层次的矛盾和风险，最终会导致项目的“温水煮青蛙”式失败。

4.2 高层领导要带头，驱动组织的自我进化

“批评与自我批评”的文化能否建立，关键在“一把手”。高层领导者必须在两个方面做出表率：

第一，要敢于并善于从一线听取“坏消息”。领导者要主动创造让一线员工敢于说真话的机制和氛围。相比于层层过滤、美化包装后的汇报，那些来自用户的真实抱怨、来自基层员工的尖锐质疑，才是最宝贵的“情报”。华为在这方面提供了极佳的范例，其著名的“蓝军”机制，就是一个专门的“反对派”部门，其职责就是全方位地否定和挑战公司的战略、产品和管理，从而帮助红军（主力部队）挤掉泡沫，发现潜在的致命缺陷。任正非本人也反复强调，我们唯一可以依靠的，就是自我批评。

第二，要勇于自我批评，带头承担决策责任。当项目失败或走入歧途时，“一把手”首先要反思的是自己的决策是否存在问题，而不是第一时间将板子打到执行团队身上。是自己当初对市场趋势判断失误？还是在资源配置上存在不公？领导者的自我批评，是向整个组织传递一个最强烈的信号：在这里，我们对事不对人，我们追求的是真理和进步，而不是维护个人的权威和面子。只有当最高层能够坦然面对自己的错误时，整个组织才能卸下包袱，形成实事求是的风气。

总而言之，一个缺乏批评与自我批评文化的组织，就像一个人没有了免疫系统，即使看起来很强壮，也无法抵御病毒的入侵，更谈不上在残酷的市场竞争中持续进化。

五：行动指南：从今天开始迭代求真

理论的价值在于指导实践。要将“假设验证的迭代闭环”和“批评与自我批评的文化”落到实处，需要具体的、可操作的抓手。以下是给所有数智化转型负责人的行动建议：

1、设立“假设验证官”或“价值管理岗”

• 在重要的数智化项目中，设立一个独立于项目经理的角色（可由数字化部门产品经理来担任），其唯一职责就是对项目的核心假设进行全生命周期的管理和监督。
• 职责：在立项阶段，负责审视和挑战核心假设的合理性与可验证性；在项目过程中，持续追踪用于验证假设的数据和反馈，定期向决策层汇报验证进展；在项目结束后，主导复盘，确保经验教训被有效记录和传承。

2、每季度砍掉20%“无战果”项目

• 项目要有进有出。数字化委员会或数字化项目管理组定期对项目情况及进度进行评判，排名末位20%项目立即冻结预算，释放人力。

3、推行“最小可行性产品（MVP）”工作法

• 在全公司范围内，大力倡导和推行MVP理念，改变过去那种追求“一步到位、大而全”的项目开发模式。
• 要求：每一个新项目、新功能，都必须以最快的速度和最低的成本，开发出一个能够触达真实用户、并能收集到关键反馈的最小版本。将资源优先投入到那些能够直接验证核心商业假设的功能点上。

3、建立“红蓝军”对抗机制

• 借鉴华为经验，针对公司的重大战略方向或关键业务项目，建立正式或非正式的“蓝军”团队。
• 运作方式：“蓝军”由公司内部经验丰富、敢于直言的专家组成，定期对“红军”（项目执行团队）的方案、进展和成果进行批判性审视和挑战。这种内部的“左右互搏”，能有效避免群体思维，暴露潜在风险。

4、改革项目评审与汇报机制

• 彻底改变以PPT为核心的汇报模式，转向以数据和产品演示（Demo）为核心。
• 新规：项目汇报时，第一页必须清晰地展示本次迭代的核心假设、验证数据和结论。汇报内容必须聚焦于“我们学到了什么”以及“下一步计划”，而不是“我们做了什么”。取消那些华而不实的“工作量”展示。

5、“一把手”带头开好复盘会

• 将复盘会制度化、规范化，尤其是对于失败或未达预期的项目，公司最高负责人应亲自参与甚至主持。
• 原则：复盘会要遵循“三不主义”——不追究责任、不批评个人、不流于形式。会议的核心是深度剖析事实，找到根本原因，形成可执行的改进项。领导者的参与，是对这种追求真理的文化的最好背书。

结语

军改给军队的最大启示只有一句话：演习不是目的，打赢才是目的。

数智化转型给证券企业的最大警醒也只有一句话：项目不是目的，战果才是目的。

项目为战，不为看；数智化的唯一战果，是客户账户里真实跳动的数字，不是PPT里跳动的动画。把“战果”作为唯一准绳，让每一次迭代都接受“战果”的拷问，都让我们更接近真理，我们就能走出“练为看”的泥潭，真正练出一支“练为战”的数字化铁军。

[Source]

本文系未央网专栏作者发表，属作者个人观点，不代表网站观点，未经许可严禁转载，违者必究！

本文为作者授权未央网发表，属作者个人观点，不代表网站观点，未经许可严禁转载，违者必究！

本文版权归原作者所有，如有侵权，请联系删除。