谈谈技术型销售必会的能力——业务架构设计

预告：

最近三个月的时间技术类的文章发的比较多，特别是关于LLM和RAG的，关注“土猛的员外”公众号的朋友上涨了近20倍，说明大模型相关的内容还是挺受欢迎的。所以下周，我会和小明（我们CTO，也是很受欢迎的国产开源软件knife4j的作者）一起发布RAG总结性系列文章的第一篇《RAG十问》，从RAG的开源和商业框架、RAG答非所问的5种原因和解决方案、对抗幻觉、毒性检测以及RAG是否会被OpenAI干掉等问题。敬请期待！哈~

既然下周继续开始LLM和RAG的原创文章，那么今天我就先发一篇年初写的关于业务架构设计的原创文章，现在回头看，我觉得这更是一个技术型销售的心得，业务架构设计可能是新型销售非常值得投入时间去增强的技能（至少我靠业务架构设计拿了好几个本来非常困难的单子），希望对您会有一些帮助。

以下是原文：

在文旅行业里面，有一个问题是从业者不太愿意说，但却无法回避：就是大部分的项目其实在交付之后并没有发挥出真正的价值。

这些项目往往有一个统一的名字——“交钥匙工程”，这可不是一个褒义词，而是意味着交付之后，这个项目的整个生命周期就完结了，因为多数情况下是无法运营起来的。造成无法运营的原因有很多，比如很大一部分业内人士认为：这是没有运营团队或没有运营投入造成的。而我觉得这个锅不能运营来背，根本原因是在项目开始阶段，就缺少合理的业务架构设计，以至于在交付之后，运营人员的运营路径和系统是不匹配的。

那么什么是业务架构设计呢？

作为一个十多年的码农，我本来更适合讲的是系统架构，而不是业务架构，但是最近三年的从业经历中的一些亲身体验以及见过的一些“灾难级”项目，觉得还是要和大家分享一下我自己理解的业务架构设计，能给哪怕一两位从业者带来一些新的思考也是好的。

我认为的业务架构设计包含了规划设计、最终价值目标确定、价值目标的分解，以及实现目标所需要的抓手和配套的运营动作和工具。大部分的项目在开始的时候客户肯定就会有一个最初的目标，如何去理解这个目标，然后一直分解推演到运营工作计划和系统功能清单，就是业务架构设计的工作。

设计过程中是需要和最终的运营团队有深入交流的，如果在设计阶段还没有确定运营团队，那么对架构师的能力要求则会更高，就需要他们本身有较强的运营能力。业务架构设计的越好，后续的系统研发会非常有明确指向，运营团队接管后也会有非常匹配的各种抓手助力他们运营，才能真正把项目持续的运营起来。

案例一：景区真实案例

以上说了这么多生硬的“道理”，接下来我们先来看一个真实的例子，为了不泄露太多信息，会保留一些重要信息，但可展示的内容应该也能说明白业务架构设计的重要性了。

这是一个华东地区的景区，我们称这个景区为“A”，它拥有滑雪场、亲子游玩项目、度假酒店、餐饮和其他一些项目。

我第一次看到内部方案的时候，我们的售前对客户现状和痛点分析是：数据孤岛、没有私域流量运营等几个痛点，但是在方案的后续内容中对于数据打通之后客户能得到什么，私域流量如何去打造等问题并没有去做合理化解决，而是开始堆整体系统架构，开始把我们的各类产品堆进去，比如中台、比如旅游商城，还有各类综合管控系统等。

各位，这并不是我当时所在的公司的特点，这完全是行业通病，而且我自己接触过的非常多的“大厂”架构师也不能免俗。

那么面对这样的一个客户，我们更合理的处理方式应该是怎么样的呢？

一、找到客户核心竞争力

这肯定需要做的是和客户更深入的交流，包括客户的决策者和实际的运营团队，然后去挖掘哪些点可能是客户的核心竞争力。

在A景区的项目中，我们最终确定下来在数字化层面上的客户核心竞争力是“做好游客的复游率”——提出了“每年必来一次”这个的项目主要slogan。因为类似于A这样的景区（或度假区）在华东地区超过10家（大概有17家），各自的获客竞争是非常激烈的，假设每获客成本是100元（线上线下各种渠道的推广），那么增加复游率，就可以将每获客成本大大降低，比如每获客成本变成60元，更高的推广ROI就是景区的核心竞争力。

二、分解主目标

其次去分解“每年必来一次”这个主目标，一般会分成三个主要指标，这里我只举其中的一个，就是老客的差异化服务。简单列几个措施包括：

1. 尊荣感（面子）：景区大门、休息室等门禁的人脸身份识别，会有语音反馈，比如“尊敬的X先生，欢迎您再次来XXXX”，“我们为您和家人准备了XXXX礼品和水果”等，包括景交车、矿泉水、停车费等方面的减免券等，处处体现尊荣感；
2. 服务差异化：酒店服务上，假设普通客人是1位服务人员对应20个房间的话，老客户获得的是1位服务人员对应6个房间的服务，而且在服务、物品上也会有差异；
3. 赠送可以带回家的礼品：赠送可以带回去的老客大礼包。

三、设计抓手和考核

这些措施都会在老客游前就进行营销，转化率是一个检验有效性的大指标。然后再根据这些指标和措施进行具体的工具与运营动作的落实。比如在工具方面，这里就需要人脸识别系统和门禁、语音智能系统、改造过的PMS、电商会员系统和核销功能、营销效果数据分析系统等，以及作为底座的数据中心。在运营上，老客尊荣服务的设计和执行，礼品的筹备和发放、人员服务用语的培训等等，都是非常具体的运营动作。

其实在整个业务架构的设计上，“每年必来一次”虽然是最大的目标，为了实现它而设计的软硬件系统却可能只会占30%，但这已经够了。其他70%部分，依然可以是传统的安全管控、人员管理、可视化数据驾驶舱等，毕竟这些是标准件，虽然不能为项目凸显特色，但客户也是需要的。

接下来说说业务架构的设计步骤，也会再举一个真实的案例来配合说明。

我自己整理的设计步骤是以下五步：

• 和客户充分沟通，整理需求；

• 挖掘和定义主指标，也就是最主要的一个大目标，或slogan；

• 分解这个大目标，一般会分解成2-3个二级目标，并论证这些二级目标可以支撑大目标的实现；

• 为每个二级目标制定抓手，这些抓手是为了支撑这些二级目标的，抓手一般可以是一句话的解决方案或指标，比如“人均打开次数3.1次”、“人均停留时间86秒”等；

• 制作运营动作和工具（系统）清单，为各自的抓手服务，然后可以将一些可以共用的系统抽出来，将运营清单和功能清单合理化。

案例二：文化场馆案例

这里再讲一个案例，是分布在城市里的某沉浸式文化类体验馆的项目，我们暂称为B项目。B项目我就不说具体的过程了，直接上一些图例。

这里略过了客户沟通和需求整理，以及大目标（因为一看就能看出是哪个客户），只从二级目标开始，再到抓手，再到最后的运营动作和工具。当然，上图并不是最终版本的方案，每个二级目标有单独的分析拆解内容，这里就只放一个集合稿的截图了。

如何在项目中段做业务架构设计？

前面讲的都是从客户需求和规划阶段就开始的业务架构设计，但是很多情况是在你介入的时候，顶层的规划可能已经定义好了，这时候依然是可以进行设计，无非是从二级目标，或者抓手开始。

曾经经历过一个项目，项目负责人们对于这个运营项目需要做什么已经定义的非常清晰。而且看起来也是有一定开创性的，对客户有价值。但项目在开始的第一年却非常挣扎，特别是在系统层面的产品和研发工作开展上，一度是找不到方向。

原因是什么？其实就是没有做好业务架构设计，造成了主目标和实际的抓手脱节，甚至没有支撑主目标的这些二级目标和抓手。

比如当时的一个大目标是月GMV达到300万元，之后就给到产研侧了，让IT侧的产品经理去思考怎么实现配套的系统设计，结局就很惨了，他对运营没这么熟悉，也没有这么大的权限。比较合理的方式应该是将月GMV300万元进行分解，我们从最简单的GMV公式来分解：

这里的业务架构设计就是不断去分解，我们只讲转化率，将一些更具体的支撑转化率的抓手找出来，比如小程序如果游客只打开一次，只有3、4秒，就再也不会打开了，那又怎么可能会有转化率呢。所以反复打开小程序（的场景）和停留时间就是一些具体的抓手，只有把这些抓手定义出来，才能给到产品经理和运营人员去思考在设计和内容上如何去实现这些指标，才不至于漫无目的地挣扎。

客户需要的是一套可执行的解决方案

最后再说说业务架构设计的核心，核心其实就是一句话：帮助客户设计一套可执行的解决方案。

我自己的销售经历中，有过从30万的小切口（项目）进去，最终拿下几百万订单的例子。靠得就是真心帮助客户解决问题，真正去思考他们面临的难题，然后提出一套可执行的解决方案。

还有一次更有意思的经历就是，与三家专业做P类产品的竞争对手（其中一家是行业龙头）竞争P类项目，结果最终是我们胜出。原因也是业务架构设计，因为P类产品项目招标只是最开始的一个项目，客户更加在意的是后面的二期、三期。客户希望中标企业可以有更全面和更专业的解题思路来全盘考虑，而且经得起他们的推敲。

我当时设计的整套方案，在P类产品上确实稍逊于另外三家，因为我们并不是专业做P类产品的。但是我在整个三期的整体系统考虑上是花了大功夫的，包括：

• 组织架构如何建立，有哪些部门，它们之间的关系和工作流程？
• 各部门的职能、人员要求和考核指标；
• 哪些部门是本部来做，哪些是可以协作或外包；
• 如何去做后期的无痛扩展；
• 最后是一整套配合整个思路的IT架构和各类系统。

最后

好了，今天就说到这里了，希望这篇文章对您有帮助！

对了，如果要加强自己的业务架构能力，平时需要主动地多去了解一些知识和技能，比如和客户的沟通能力，需要有基础的规划能力，需要对产品设计和研发有一定的了解，还需要知道运营工作到底有哪些，换句话说，也就是不要给自己设限，主动地多做事，多争取实操机会。

另外，心里永远怀揣一句话：“再好的方法也敌不过一颗真诚为客户创造价值的心！”