实例分析：一整套营业系统产品技能架构的方法论

业务类系统（常日称为To B 类产品），一样平常包括crm、供应链、物流等。
系统的架构设计非常具有寻衅性。

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

但是业务类的系统，常常是没有参照和模拟，一些业务流程的不同，一点公司组织构造的不同，你家的CRM和他家的CRM可能完备没有参考性。
以是在搭建产品架构的时候则哀求产品经理非常懂业务，磨练PM能力的同时，对技能架构也具备很大的寻衅。

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

一、 业务类系统，一样平常须要加强的三个方面

根本做事包括技能方面根本这不用多说。
业务型根本做事也不要忽略，比如：城市做事、入口管理等，这些如果前期没有实行好的标准，系统一旦累计几年，将难以调度。

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

二、技能架构的三个要素

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

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

利用者通过一个功能元素完全的完成一项唯一的事情，技能上可以叫做模块，产品上称为功能。
当然在产品设计和持续迭代过程里，常常很难如此实现唯一。

系统是指相互之间有直接或间接关系的功能元素形成的凑集，此凑集能单独为特定利用者供应特定的做事，比如：发卖系统、客服系统。

我们说的技能架构， 一定是“多个”独立系统之间的事情。
我们开始谈技能架构的第一步，各系统必须先独立，工程和数据耦合的一起的系统，没有架构可言。
没有任何关系的功能元素组成，不能称为系统。
同样的没有任何关系的系统组成，不须要架构。

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

针对功能和系统的实现，会对应的采取DB，ES，负载均衡等实现方法。
很多实现方法可能技能含量很高，但不要把和整体技能架构稠浊，技能实现方法和技能架构是两回事。

3. 制订技能架构，必须考虑系统功能层级

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

架构和功能层级表达的实在是信息之间的流转关系，不同信息层级之间一定是有逻辑关系的。
各层次之间虽然干系，但同一层级的功能系统之间一定是独立的，同时客不雅观上也常常对应着不同的技能部门和业务部门。

业务类系统的架构设计比ToC的繁芜很多。

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

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

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

适宜繁芜类的ToB系统，多角色共同完成一系列的事情。
一个功能（系统）务必在同一层级内办理，否则随意马虎造成信息架构被冲破。

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

合格的系统，须要第一功能层级间建立合理的关系（现实缘故原由，的确常常次要功能间，不随意马虎建立合理关系）。

三、技能架构的两个原则

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

技能架构和产品架构，必须同等，各自用不同逻辑做拆分，建关系，那是灾害。

对业务整体有深刻的思考和理解，还须要更强的产品抽象能力。
九成的产品经理，实在不谈产品架构。
常常挂在嘴边便是业务需求，彷佛事情便是业务的翻译官。

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

一个产品的义务是为利用者供应特定的做事，要我们通过什么样的办法为利用者供应什么样的产品和做事。
以是一定是业务导向的，以业务结果的好坏评定，统统都是为业务做事的。

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

作为系统业务架构师，须要时候脑筋里有个大系统的产品（技能）架构图。
要有能力把产品功能（技能模块）抽象成信息化的层级的架构。
通过功能与功能的组合、层级关系的交互通报信息的流转，全体架构图通报的是我们的业务流程、商业模式。

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

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

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

可扩展性实在是在传达一个信息，我们是否理解未来这个产品会有哪些哪方面的新增加功能或者内容，也便是产品方案。
没有人真的能预知未来，但新增功能，新的系统都会导致信息架构重新调度和利用者的认知本钱。

所谓可扩展性，便是尽可能为来日诰日的改变降落本钱，减少调度，这就须要系统架构设计是可横向共享的。
而在业务系统里什么是能共享的呢？便是自始至终贯穿全体业务链条的，一样平常是客户、订单、商品等。
所谓各系统的打通，实在便是各系统间如何有效的通报客户，商品等的信息状态。

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

好的业务架构各个别系的数据在业务整体上是连续的、完全的、准确的。
通过数据采集，方便建立DW，可以很好的为业务运营供应数据支撑。

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

四、业务系统和用户系统以产品为中央，是我有好的市场调研，我有牛掰的产品经理，我给你的产品便是我能做的最好的，最大可能是你须要的。
以客户为中央，适宜面向运营单位，面向商家的企业级运用，理念是你须要什么。

这里的你，可以是直接用户，商家，也可能是公司的发卖，客服等。

如果不理解这个以产品为中央和以客户为中央的不同， 以用户产品的思路做企业级运用， 就会出发点出错，便是闹笑话。
比如：我之前的公司，明明因此CRM为主的营销管理系统，但同事们喜好拿个淘宝网站的架构来做参考。

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

理解两类系统在逻辑上的差异，我也是用了很多年，过去在公司总是和同事说不清楚，实在也是我自己没想明白。

可能是我在写这篇文章时候才多了些思考：

（1）用户产品关注怎么帮助利用者实现发邮件，看新闻等功能，很多功能技能难度非常大，但便是一个繁芜的软件，而业务系统为什么核心是数据，由于我们要关注利用者的业务结果，业务到底有没有把商品卖出去，广告的直接效果如何

（2）为什么说用户产品便是一个软件？我们夸年夜一点理解，所有的互联网用户产品都属于“SAAS”类软件， 属于某种在线OFFICE。
你的邮件和我的邮件没有直接关系，你写的PPT也和我的Word没紧要，利用者之间是隔离的，大家用的是大致同一套界面

（3）而业务系统，利用ERP的部门高下架多少商品直接影响到后续发卖系统和售后系统的利用者的逻辑，乃至发卖业务订单的完成度也相互影响古迹。
以是业务系统的核心是数据，核心逻辑除了实现业务动作，更在于你的数据对我的数据的影响。
很多小公司可以没有“软件”，用Excel也能实现业务管理，但不能没有数据。

理论上，只有业务系统才可以说数据是永久的程序是暂时的，用户系统不应该如是说。

一样平常公司的内部发卖运营体系，都是业务导向，但会经历两个阶段：

一是 ，业务驱动。
这段期间，业务模式不稳定，产品能力的问题或者业务职员强势， 业务部门勾引公司方向 。
这种情形，产品的浸染有限，虽然也有便利性，创新性的哀求，但总体说还是业务需求的翻译官，业内称作功能性产品经理二是，产品驱动。
当业务模式固化下来，尤其是业务流程相对标准化往后，产品经理（或者运营）主导规则和流程 CRM 是最具代表性的业务系统。

五、运营驱动

现在回答一下，什么是好的产品（业务模式）该当便是办理用户真实需求的实际痛点。
从痛处入手。
这里的用户可以是Toc的消费者，也可以是面向公司运营单位。

接上一节的话题，我认为比较合理的公司架构是运营驱动。

什么是运营？？

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

在电信行业出来以前，天下上是没有真正的运营的。
乃至诺基亚和微软卖出去产品，很难知道用户打了多少电话，用电脑做了什么， 而电信和互联网时期的到来，统统不一样了， 我们可以清楚的节制业务实行结果，也便是用户利用我们的系统到底做了什么。
通过利用者的利用情形，从结果知道客户须要什么，更新规则。

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

通过理解利用者对规则的实行情形，比拟团队以及公司的KPI，剖析偏差了那些，为什么偏差，再次升级系统，干预规则，干预偏差。

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

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

业务结果分两部分：一是系统运行状况，二是利用结果。

前者及格线是系统出了问题你要第一韶光知道，不能等运营单位投诉再排查。
后者便是每天到底多少用户，多少订单成立率转化率，这些必须关心。
不能光想着系统怎么去实现，更要知道业务用你的系统做出了什么，以及每次升级为什么而做。

六、数据运营

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

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

不是说数据不主要。
数据能起到的浸染，分三个阶段。
这三个阶段大略的说便是发生了什么（报表），为什么发生（数据剖析）和将要发生什么（决策支持）。

大多数互联网公司，包括那些上市的，实在还没办理业务发生了什么，对，说的没错。
别看这么多互联网公司，包括很多上市公司，每天到底多少线索，多少订单，各种转化率，真的没谱。
各团队口径差距巨大，这是大概率事情，海内也就BAT（京东，滴滴，美团不足理解）的主营业务算是数据过关。

而这页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协议