方法论：业务系统的技术架构
业务类系统（通常称为To B 类产品），一般包括CRM，供应链，物流等。系统的架构设计非常具有挑战性。
面向用户的To C 类前台产品，无论产品经理还是用户都已经培养起了使用习惯，对功能有一定程度的理解，见过的模式足够多，能够建立起一定的产品模型，也容易找到参照物去模仿。
但是业务类的系统，常常是没有参照和模仿，一些业务流程的不同，一点公司组织结构的不同，你家的CRM和他家的CRM可能完全没有参考性。所以在搭建产品架构的时候则要求产品经理非常懂业务，考验PM能力的同时，对技术架构也具备很大的挑战。
首先，思考一下好的产品(业务模式)是什么？
一、 业务类系统， 一般需要加强的三个方面
基础服务包括技术方面基础这不用多说。业务型基础服务也不要忽视，比如城市服务，入口管理等，这些如果前期没有执行好的标准，系统一旦累计几年，将难以调整。
业务架构和数据运营，都会在后面专项的提到，重点说业务系统的架构方法。
二、技术架构的三个要素
现在回答一下，什么是好的产品（业务模式）应该就是解决用户真实需求的实际痛点。从痛处入手。这里的用户可以是Toc的消费者，也可以是面向公司运营单位
产品思维：
从痛点入手，去解决问题，这是我理解的产品思维。而产品经理常常挂在嘴边的需求分析其实是个伪命题。做用户产品，产品经理能接触到多少用户了解到多少需求？ 做业务系统，北区大佬要APP，南区大佬要网页版，产品经理那个都惹不起，听谁的？ 无论做什么产品，得是PM自己有能力设计主流程和规则，紧贴公司的方向和核心KPI，而不是翻译谁的需求。
至于抽象，迭代，交互设计，那可能叫产品能力更合适。 就像java能力可能是技术的基本能力，java再好和是否能开发出微博微信，没直接关系。汉语再流利，和写一篇量子力学论文基本也没关系
接上一节的话题，我认为比较合理的公司架构是运营驱动。
什么是运营？？
运营就是人为的干预规则。规则就是咱们的产品逻辑，也就是业务规则。
在电信行业出来以前，世界上是没有真正的运营的。 甚至诺基亚和微软卖出去产品，很难知道用户打了多少电话，用电脑做了什么， 而电信和互联网时代的到来，一切不一样了， 我们可以清楚的掌握业务执行结果，也就是用户使用我们的系统到底做了什么。通过使用者的使用情况，从结果知道客户需要什么，更新规则。
这套逻辑在业务系统提现得更加清楚明确， 用规则去约束销售、客户，接单后的动作，规定动作的时间等。
通过了解使用者对规则的执行情况，对比团队以及公司的KPI，分析偏差了那些，为什么偏差，再次升级系统，干预规则，干预偏差。
运营驱动，适合多个运营单位合作，非业务驱动的产品模式。很多时候，业务流程和公司组织架构的实际情况，做不到或者不需要运营驱动
多说一句，无论是做产品还是技术，掌握业务结果非常极其特别十分的重要，但大部分产品和技术都对此不感兴趣，也就限制了个人的上升空间。
业务结果分两部分，一是系统运行状况，二是用户（业务人员）的使用结果。前者及格线是系统出了问题你要第一时间知道，不能等运营单位投诉再排查。后者就是每天到底多少用户，多少订单成立率转化率，这些必须关心。不能光想着系统怎么去实现，更要知道业务用你的系统做出了什么，以及每次产品升级为什么而做。
职场上，大家不同的能力，薪水，岗位，最终都会不同程度成为解决不同问题的人。对问题没有感知，对结果没兴趣的产品技术leader，百分百就是废柴，你就是问题本身。这个说起来,就是职业规划和价值观了，不多扯。
六、数据运营
这张图，照搬我一个旧同事的PPT，至今没见过用一页纸把数据解释得如此清楚的
前面说到运营驱动，运营离不开数据。一般的公司， 在一定规模前，暂时都达不到数据运营。
不是说数据不重要。 数据能起到的作用，分三个阶段。这三个阶段简单的说就是发生了什么（报表），为什么发生（数据分析）和将要发生什么（决策支持）。大多数互联网公司，包括那些上市的，其实还没解决业务发生了什么，对，说的没错。别看这么多互联网公司，包括很多上市公司，每天到底多少线索，多少订单，各种转化率，真的没谱。各团队口径差距巨大，这是大概率事情，国内也就BAT（京东，滴滴，美团不够了解）的主营业务算是数据过关。
为什么会产生这样的情况，我们明明人人都在说数据多么多么重要的废话。我理解，这不是技术问题，其实是管理问题。各部门的KPI都是摆设，没有人真正对数据结果负责，比如成交率下跌了两个点，有人会因此离职吗？ 没有，那也就没人去啃那些对不上的数据，各部门数据差异越来越大，在第八章会再次提及。
而这页PPT真正解释牛的在右侧部分，数据正在发生什么和我期望发生什么，这比较超出我的能力， 不解释了，O(∩_∩)O哈哈~
- 决策人员：决策者、高层管理者，通常只是用送到手中的极简单工具，极少自己分析
- 分析人员：业务管理者、专业分析人员利用商务智能各种工具向决策者制作数据内容并解释数据含义
- 一线人员：一线业务人员，利用工具向管理者固定汇报业务状态、进行少量分析
七、什么是CRM
我之前供职的一家公司，上万的员工，有个有趣的现象。供应链部门负责商品采购验收和上架，公司网站展示相应的商品。但是，二者数据长期不一致。能有多不一致？说出来吓死人，有四分之一的商品状态几年来一直对不上，每每想起，赶脚都会被人笑死。
为什么会产生这样的情况? 因为供应链上架是API通知网站以及各部门，其他部门销售了，退订了商品等也是API调用供应链和网站。也就是各系统啥都是API调用。同时什么是上架，下架和成交，各系统定义都不一致，并且API调用不够稳定，又缺乏监控，也就是第五章说的产品技术都完全没有掌握业务结果的意识。。。
理论上说， 如果各系统自身足够强壮，系统间通讯严丝合缝，指标定义清晰明了，那什么问题都不会有，根本不需要做横向共享，不需要搞什么辅助设计。但这几乎是不可能的.
要明白，除非系统上线后永不升级，否则一切都是逐步演进的，日积月累差异会大的惊人
建设主数据，采用横向共享的设计取代系统间API调用的网状依赖。
主数据能做什么，一般主数据的输出是客户或商品全景视图，所有业务系统将有跨业务系统需要的相关信息同步到主数据，并从全景视图获得其他相关的数据。
主数据真正实现各个业务系统的打通
主数据通过统一的数据采集，数据存储，数据管理，需要足够的产品认知能力和全局业务意识。
主数据对外提供的是统一的信息查询和信息变更服务订阅，这里技术实现其实并不复杂，也就是ES和MQ。
例如，销售系统通过主数据的“商品变革信息订阅中心”的信息订阅获取供应链上架的商品后，而供应链和售后等系统通过同样的订阅中心获取商品是否成交的信息决定商品上下架等操作
再重申几点：
- 比较适合做主数据的也就是商品和客户
- 理论上可以有多个主数据，但实际操作过程里， 需要具体看情况。比如电商，商品和广告是两个业务线，甚至两个事业部，各自的架构，各自的横向共享，可能完全隔离更合适
- 选择的重点，可以参照业务重点，比如我们到底是帮商家卖东西还是帮用户买东西。。。
- 并不是业务一开始，上来就搞主数据，就想着横向共享。在初期野蛮生长时候，各系统尽可能独立，划清界限即可
- 主数据目的是跨系统的共享主要数据的变化，应该尽最大可能不要侵入业务系统。 也就是不要让业务系统直接把业务结果往主数据里更新，一定是通过数据采集的方式，各业务系统尽可能不做任何变化
- 主数据不要直接产生业务数据，但可以有间接的。比如跨业务的指标（例：网站PV和成交量的比例），业务系统自身不关注的指标（例：最近10天成交率）
本文作者 @王以弘
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！