好的架构能良好的支持业务的横向扩展，各个系统的数据在业务整体上是连续的、完整的、准确的。业务系统的技术架构如何搭建？文章围绕这个问题展开了详细的说明，与大家分享。

业务类系统（通常称为To B 类产品），一般包括CRM，供应链，物流等。系统的架构设计非常具有挑战性。

面向用户的To C 类前台产品，无论产品经理还是用户都已经培养起了使用习惯，对功能有一定程度的理解，见过的模式足够多，能够建立起一定的产品模型，也容易找到参照物去模仿。

但是业务类的系统，常常是没有参照和模仿，一些业务流程的不同，一点公司组织结构的不同，你家的CRM和他家的CRM可能完全没有参考性。所以在搭建产品架构的时候则要求产品经理【资 ;源 之.家.】非常懂业务，考验PM能力的同时，对技术架构也具备很大的挑战。

首先，思考一下好的产品(业务模式)是什么？

一、 业务类系统， 一般需要加强的三个方面

基础服务包括技术方面基础这不用多说。业务型基础服务也不要忽视，比如城市服务，入口管理等，这些如果前期没有执行好的标准，系统一旦累计几年，将难以调整。

业务架构和数据运营，都会在后面专项的提到，重点说业务系统的架构方法。

二、技术架构的三个要素

1. 三要素的顺序一定是从功能到系统，最后是架构

先说功能，功能元素指的是一系列的操作集合，能构成一个完整的功能，比如登录，注册。

使用者通过一个功能元素完整的完成一项唯一的工作，技术上可以叫做模块，产品上称为功能。

当然在【资 ;源 之.家.】产品设计和持续迭代过程里，常常很难如此实现唯一……

系统是指相互之间有直接或间接关系的功能元素形成的集合，此集合能单独为特定使用者提供特定的服务，比如销售系统，客服系统

我们说的技术架构， 一定是“多个”独立系统之间的事情。

我们开始谈技术架构的第一步，各系统必须先独立，工程和数据耦合的一起的系统，没有架构可言

没有任何关系的功能元素组成，不能称为系统。同样的没有任何关系的系统组成，不需要架构

2. 要区分技术实现方法和技术架构的不同

针对功能和系统的实现，会对应的采用DB，ES，负载均衡等实现方法。很多实现方法可能技术含量很高，

但不要把技术实现方法和整体技术架构混淆，技术实现方法和技术架构是两回事

3. 【资 ;源 之.家.】制定技术架构，必须考虑系统功能层级

技术架构就是指把不同的功能元素（系统）放在适宜的环节、合适的层级，并且建立功能与功能，系统与系统之间关系，形成一个结构化、平台化、体验简约的大系统。

架构和功能层级表达的其实是信息之间的流转关系，不同信息层级之间一定是有逻辑关系的。

各层次之间虽然相关，但同一层级的功能系统之间一定是独立的，同时客观上也常常对应着不同的技术部门和业务部门。

业务类系统的架构设计比ToC的复杂很多。

（1）按功能模块来进行划分：

适合产品目标单一的ToC 产品，或者单一上下游的ToB系统，系统的使用者群体单一，使用者群体单一，功能和功能之间并没有太多的逻辑关系

（2）按业务逻辑来进行划分：

适【资 ;源 之.家.】合复杂类的ToB系统，多角色共同完成一系列的工作

一个功能（系统）务必在同一层级内解决，否则容易造成信息架构被打破

首先要总结出第一级别的功能元素，这个第一级别功能元素，其实就是我们的业务主线，也就是核心业务。 线索，cc，建单，带看，成交，过户。。。。。

合格的系统，需要第一功能层级间建立合理的关系（现实原因，的确常常次要功能间，不容易建立合理关系）

三、技术架构的两个原则

（1）说到系统架构，架构师的组织能力很重要，组织的不只是一个系统的各个功能元素，需要具备组织不同的系统的能力。在于理解要为谁，解决什么问题。

技术架构和产品架构，必须一致，各自用不同逻辑做拆分，建关系，那是灾难。

对业务整体有深刻的思【资 ;源 之.家.】考和理解，还需要更强的产品抽象能力。

九成的产品经理，其实不谈产品架构。常常挂在嘴边就是业务需求，好像工作就是业务的翻译官

（2）我们通常所谓的某产品，其实就是业务模式，就是流程和规则，如果业务系统的主流程和规则不是你设计的，只是翻译业务需求，那业务部门直接找技术也行得通。

一个产品的使命是为使用者提供特定的服务，要我们通过什么样的方式为使用者提供什么样的产品和服务。所以一定是业务导向的，以业务结果的好坏评定，一切都是为业务服务的

所谓产品架构，还是技术架构， 都是信息架构。

作为系统业务架构师，需要时刻脑子里有个大系统的产品（技术）架构图。要有能力把产品功能（技术模块）抽象成信息化的层级的架构。通过功【资 ;源 之.家.】能与功能的组合、层级关系的交互传递信息的流转，整个架构图传递的是我们的业务流程、商业模式。

产品要有技术能力，技术如果不懂产品，那再资深的工程师，也只能是码农。。。。

※ 这里说一下系统扩展性的问题，为最后第八章的实例做个铺垫。

好的架构各个子系统之间相互配合形成一体化平台，子系统间只有最小的重复度独立，系统各自支持不同的业务板块，多个系统作为一个整体，共同为支撑公司业务

可扩展性其实是在传达一个信息，我们是否了解未来这个产品会有哪些哪方面的新增加功能或者内容，也就是产品规划。

没有人真的能预知未来，但新增功能，新的系统都会导致信息架构重新调整和使用者的认知成本。

所谓可扩展性，就是尽可能为明天的改变降低【资 ;源 之.家.】成本，减少调整，这就需要系统架构设计是可横向共享的

而在业务系统里什么是能横7共享的呢， 就是自始至终贯穿整个业务链条的，一般是客户，订单，商品等。所谓各系统的打通，其实就是各系统间如何有效的传递客户，商品等的信息状态

好的架构能良好的支持业务的横向扩展。这点很重要，新的业务很多时候都在试错阶段，随时会增减业务环节，也就是不断地新的系统，新功能的融入。比如在几个流程节点上增减一个三方部门审核操作，审核系统本身不麻烦，但要做到即插即用，对接多个系统和公司多个单位，那不同的架构可能工作量差异很大

好的业务架构各个系统的数据在业务整体上是连续的、完整的、准确的。通过数据采集，方便建立DW。可以很好的为业务【资 ;源 之.家.】运营提供数据支撑。

好的业务架构，系统能提供的不止于业务功能，还有无时不刻无处不在的驱动各模块业务和各合作伙伴业务更好决策的数据。

四、业务系统和用户系统

以产品为中心，是我有好的市场调研，我有牛掰的产品经理，我给使用者的产品就是我能做的最好的，最大可能是使用者需要的。

以客户为中心，适合面向运营单位，面向商家的企业级应用，理念是使用者需要什么

使用者，可以是直接用户，商家，也可能是公司的销售，客服。

两类系统，一个标志性的区别，就是我们是否关注和承担使用者的业务结果。

CRM、供应链等业务系统是需要所有人共同承担业务结果的。邮件新闻用户产品，我们不需要承担用户使用后增长多少知识的结果。

如果不理解这个以产品【资 ;源 之.家.】为中心和以客户为中心的不同， 以用户产品的思路做企业级应用， 就会出发点出错，就是闹笑话。 比如，我之前的公司，明明是以CRM为主的销售管理系统，但同事们喜欢拿个淘宝网站的架构来做参考。

理论上， 用户系统里淘宝网站和人人车、链家、京东都是一样，都是把商品（车/房）展示给用户，获得订单（线索）。 作为“信息”提供方，是把自己有的东西，用自己的方式展示出来。

理解两类系统在逻辑上的差异，我也是用了很多年，过去在公司总是和同事说不清楚，其实也是我自己没想明白。可能是我在写这篇文章时候才多了些思考。

用户产品关注怎么帮助使用者实现发邮件，看新闻等功能，很多功能技术难度非常大，但就是一个复杂的软件，而业务系【资 ;源 之.家.】统为什么核心是数据，因为我们要关注使用者的业务结果，业务到底有没有把商品卖出去，广告的直接效果如何为什么说用户产品就是一个软件？我们夸张一点理解，所有的互联网用户产品都属于“SAAS”类软件， 属于某种在线OFFICE。你的邮件和我的邮件没有直接关系，你写的PPT也和我的Word没关系，使用者之间是隔离的，大家用的是大致同一套界面而已而业务系统，使用ERP的部门上下架多少商品直接影响到后续销售系统和售后系统的使用者的逻辑，甚至销售业务订单的完成度也互相影响业绩，所以业务系统的核心是数据，核心逻辑除了实现业务动作，更在于你的数据对我的数据的影响。很多小公司可以没有“软件”，用Excel也能实现业【资 ;源 之.家.】务管理，但不能没有数据

因此，只有业务系统才可以说数据是永远的程序是暂时的，用户系统不应该如是说。

五、运营驱动

一般公司的内部销售运营体系，都是业务导向，实现业务目标是第一位。但会经历两个阶段，

一是 ，业务驱动。 这段时期，业务模式不稳定，产品能力的问题或者业务人员强势， 业务部门引导公司方向 。这种情况，产品的作用有限，虽然也有便利性，创新性的要求，但总体说还是业务需求的翻译官，业内称作功能性产品经理

二是，产品驱动。当业务模式固化下来，尤其是业务流程相对标准化以后，产品经理（或者运营）主导规则和流程 CRM 是最具代表性的业务系统

现在回答一下，什么是好的产品（业务模式）应该就是解决用户真实需求的【资 ;源 之.家.】实际痛点。从痛处入手。这里的用户可以是Toc的消费者，也可以是面向公司运营单位

产品思维：

从痛点入手，去解决问题，这是我理解的产品思维。而产品经理常常挂在嘴边的需求分析其实是个伪命题。做用户产品，产品经理能接触到多少用户了解到多少需求？ 做业务系统，北区大佬要APP，南区大佬要网页版，产品经理那个都惹不起，听谁的？ 无论做什么产品，得是PM自己有能力设计主流程和规则，紧贴公司的方向和核心KPI，而不是翻译谁的需求。

至于抽象，迭代，交互设计，那可能叫产品能力更合适。 就像java能力可能是技术的基本能力，java再好和是否能开发出微博微信，没直接关系。汉语再流利，和写一篇量子力学论文基本也没关系

接【资 ;源 之.家.】上一节的话题，我认为比较合理的公司架构是运营驱动。

什么是运营？？

运营就是人为的干预规则。规则就是咱们的产品逻辑，也就是业务规则。

在电信行业出来以前，世界上是没有真正的运营的。 甚至诺基亚和微软卖出去产品，很难知道用户打了多少电话，用电脑做了什么， 而电信和互联网时代的到来，一切不一样了， 我们可以清楚的掌握业务执行结果，也就是用户使用我们的系统到底做了什么。通过使用者的使用情况，从结果知道客户需要什么，更新规则。

这套逻辑在业务系统提现得更加清楚明确， 用规则去约束销售、客户，接单后的动作，规定动作的时间等。

通过了解使用者对规则的执行情况，对比团队以及公司的KPI，分析偏差了那些，为什么偏差，再【资 ;源 之.家.】次升级系统，干预规则，干预偏差。

运营驱动，适合多个运营单位合作，非业务驱动的产品模式。很多时候，业务流程和公司组织架构的实际情况，做不到或者不需要运营驱动

多说一句，无论是做产品还是技术，掌握业务结果非常极其特别十分的重要，但大部分产品和技术都对此不感兴趣，也就限制了个人的上升空间。

业务结果分两部分，一是系统运行状况，二是用户（业务人员）的使用结果。前者及格线是系统出了问题你要第一时间知道，不能等运营单位投诉再排查。后者就是每天到底多少用户，多少订单成立率转化率，这些必须关心。不能光想着系统怎么去实现，更要知道业务用你的系统做出了什么，以及每次产品升级为什么而做。

职场上，大家不同的能力，薪水，岗【资 ;源 之.家.】位，最终都会不同程度成为解决不同问题的人。对问题没有感知，对结果没兴趣的产品技术leader，百分百就是废柴，你就是问题本身。这个说起来,就是职业规划和价值观了，不多扯。

六、数据运营

这张图，照搬我一个旧同事的PPT，至今没见过用一页纸把数据解释得如此清楚的

前面说到运营驱动，运营离不开数据。一般的公司， 在一定规模前，暂时都达不到数据运营。

不是说数据不重要。 数据能起到的作用，分三个阶段。这三个阶段简单的说就是发生了什么（报表），为什么发生（数据分析）和将要发生什么（决策支持）。大多数互联网公司，包括那些上市的，其实还没解决业务发生了什么，对，说的没错。别看这么多互联网公司，包括很多上市公司，每【资 ;源 之.家.】天到底多少线索，多少订单，各种转化率，真的没谱。各团队口径差距巨大，这是大概率事情，国内也就BAT（京东，滴滴，美团不够了解）的主营业务算是数据过关。

为什么会产生这样的情况，我们明明人人都在说数据多么多么重要的废话。我理解，这不是技术问题，其实是管理问题。各部门的KPI都是摆设，没有人真正对数据结果负责，比如成交率下跌了两个点，有人会因此离职吗？ 没有，那也就没人去啃那些对不上的数据，各部门数据差异越来越大，在第八章会再次提及。

而这页PPT真正解释牛的在右侧部分，数据正在发生什么和我期望发生什么，这比较超出我的能力， 不解释了，O(∩_∩)O哈哈~

决策人员：决策者、高层管理者，通常只是用送到手【资 ;源 之.家.】中的极简单工具，极少自己分析分析人员：业务管理者、专业分析人员利用商务智能各种工具向决策者制作数据内容并解释数据含义一线人员：一线业务人员，利用工具向管理者固定汇报业务状态、进行少量分析

七、什么是CRM

1. CRM的意义是实现收入可预期的最大化

并且可有计划的提升预期。无论什么样的CRM，都是为了营收，这没啥可掩饰的，没有哪家会为免费用户花力气做CRM。

2. 重点是提升人效

客户开源和提升高质量客户的UP值贡献，理论上是管理问题，是运营策略问题。我们 所有CRM的参与者，重点是提升人效。人效，就是人均卖多少商品或人均贡献多少收入，是考核团队首要的KPI。 这里的人包括销售，运营，客服，产品和技术等【资 ;源 之.家.】。

3. 提升人效的路径，就是让机器承担更多的工作，即“服务数字化”

标准化，标准化是数字化的基础，计算机只能保存离散的数据，所以标准化的核心是离散化的信息结构化。比如：建单、工单、分配等。自动化，自动化指的是动态过程的数字化，比如流程、规则、权限控制的数字化。“动态”意味着各种存在依赖关系的元素互相之间的状态关系。智能化，直观的理解就是让系统具备思考能力。这意味着系统在比较确定的上下文中具备分析能力。

我在公司时候讲解CRM，常常用比较得罪人的逻辑解释。我说，CRM的理念就是通过标准化操作，让销售和运营平庸化，所有销售业绩差异不应该过大，如果有销售总是远远超常发挥，那说明我们的业务模式出了问题。哈【资 ;源 之.家.】哈，比较得罪人，但是这套理念也适合技术团队。。。

八、业务系统架构实例——横向共享的架构设计

复习：技术架构就是指把不同的功能元素（系统）放在适宜的环节、合适的层级。

公司的CRM应是面向企业不同运营单位的业务系统，会覆盖售前售中售后多个系统集合。我们讲技术架构是系统之间的关系，那如何建立这么多系统之间的关系？

这里讲一下一种技术架构案例，横向共享的设计。你的系统里，那些信息和信息的变化是其他系统关注的？？？

一般交易类业务有三种东西，可能是贯彻公司各业务线的。商品，客户，订单，尤其是前两种。商品和客户的信息保留在多个系统里，面向的也是企业内不同的运营单位，甚至第三方公司。

以商品为例，一个商品从采购仓储【资 ;源 之.家.】直到客户手里，生命周期可能几天到个把年。有负责采购相关的供应链部门，有负责营销的销售部门，有负责物流运输部门，还有售后等其他部门。这么多部门，对应着诸多的系统都有商品相关的信息和状态。

某个系统里，商品的状态信息变化了，其他系统如何第一时间掌握，并及时作出对应动作？？

比如一个简单的问题，商品成交了退订退货等事件，其他相关部门怎么知道呢，然后做相关处理，靠各系统间API调用？？只要业务跑两三年，保证各系统间的API成百上千，

我之前供职的一家公司，上万的员工，有个有趣的现象。供应链部门负责商品采购验收和上架，公司网站展示相应的商品。但是，二者数据长期不一致。能有多不一致？说出来吓死人，有四分之一的商【资 ;源 之.家.】品状态几年来一直对不上，每每想起，赶脚都会被人笑死。

为什么会产生这样的情况? 因为供应链上架是API通知网站以及各部门，其他部门销售了，退订了商品等也是API调用供应链和网站。也就是各系统啥都是API调用。同时什么是上架，下架和成交，各系统定义都不一致，并且API调用不够稳定，又缺乏监控，也就是第五章说的产品技术都完全没有掌握业务结果的意识。。。

理论上说， 如果各系统自身足够强壮，系统间通讯严丝合缝，指标定义清晰明了，那什么问题都不会有，根本不需要做横向共享，不需要搞什么辅助设计。但这几乎是不可能的.

要明白，除非系统上线后永不升级，否则一切都是逐步演进的，日积月累差异会大的惊人

建设主数据，采用【资 ;源 之.家.】横向共享的设计取代系统间API调用的网状依赖。

主数据能做什么，一般主数据的输出是客户或商品全景视图，所有业务系统将有跨业务系统需要的相关信息同步到主数据，并从全景视图获得其他相关的数据。

主数据真正实现各个业务系统的打通

主数据通过统一的数据采集，数据存储，数据管理，需要足够的产品认知能力和全局业务意识。

主数据对外提供的是统一的信息查询和信息变更服务订阅，这里技术实现其实并不复杂，也就是ES和MQ。

例如，销售系统通过主数据的“商品变革信息订阅中心”的信息订阅获取供应链上架的商品后，而供应链和售后等系统通过同样的订阅中心获取商品是否成交的信息决定商品上下架等操作

再重申几点：

比较适合做主数据的也就是商【资 ;源 之.家.】品和客户理论上可以有多个主数据，但实际操作过程里， 需要具体看情况。比如电商，商品和广告是两个业务线，甚至两个事业部，各自的架构，各自的横向共享，可能完全隔离更合适选择的重点，可以参照业务重点，比如我们到底是帮商家卖东西还是帮用户买东西。。。并不是业务一开始，上来就搞主数据，就想着横向共享。在初期野蛮生长时候，各系统尽可能独立，划清界限即可主数据目的是跨系统的共享主要数据的变化，应该尽最大可能不要侵入业务系统。 也就是不要让业务系统直接把业务结果往主数据里更新，一定是通过数据采集的方式，各业务系统尽可能不做任何变化主数据不要直接产生业务数据，但可以有间接的。比如跨业务的指标（例：网站PV和成交【资 ;源 之.家.】量的比例），业务系统自身不关注的指标（例：最近10天成交率）

本文由 @王以弘 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议