Business system methodology technology architecture

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

User-oriented To Reception Class C products, product manager or whether users are already cultivate the habits, the function of a certain degree of understanding, pattern seen more than enough to establish a certain product models, reference is also easy to find to imitate.
But the business-like systems, often without reference and imitation, a number of different business processes, organizational structure a little different companies, your home CRM and CRM his family may have no referential. So when building product architecture requires very product manager understand the business, the ability to test PM, while the technical architecture also have a great challenge.

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

First, the work system, the general need to strengthen the three areas

Basic services including technical foundation that goes without saying. Business-service basis and do not ignore, such as city services, entrance management, if these pre-standards do not perform well, once the system is cumulative years will be difficult to adjust.
Business structure and operations data, will be in the back of a special mention
to focus on that business systems architecture approach

Second, the three elements of the technical architecture

1. The order of the three elements must be from the functional to the system, and finally the architecture
start with function, the function element refers to a series of set of actions that can constitute a fully functional, such as login, registration.
By a user to complete a full functional elements of a unique work, technically called a module, called functional product.
Of course in product design and ongoing iterative process where it is often difficult to achieve so unique. . .
The system refers to a collection of functional elements have a direct or indirect relationship formed between each other, this collection alone can provide specific services for specific users, such as sales systems, customer service systems
we are talking about technical architecture must be "more" independent matter between systems.
We started talking about the first step in technical architecture, each system must be independent, system engineering and data coupled together, there is no infrastructure to speak of
without any functional elements of the relationship between the composition, it can not be called a system. The same system is not composed of any relationship, no schema
2. To distinguish between the different technology implementations and technical architecture
to achieve for the functions and systems, using DB, ES, load balancing will implement the corresponding method. Many implementations may be high-tech,
but do not confuse technical implementation and overall technology architecture, technology implementation and technical architecture are two different things
3. The development of technical infrastructure, we must consider the system function level.
Technical architecture refers to the different functional elements (system) on the appropriate link in the appropriate level,
and build relationships between features and functions, system to system, forming a structure, platform and experience the simplicity of a large system.
Expression of structure and function hierarchy is actually a relationship between the flow of information, there must be some logical relationship between different levels of information.
Although the correlation between the levels, but the same level of functionality between systems must be independent, while the objective is also often corresponding to different technical departments and business units.
System architecture design business class much more complex than the ToC.

. • a module to be divided by function -
suitable for a single product target ToC product, or a single upstream and downstream ToB system, and there is not much between the system of single user groups, user groups a single, functional and logic functions
. • b divided by business logic -
for ToB system complexity class, multi-role work together to complete a series of
a function (system) important to address within the same level, or likely to cause information architecture is to break the
first to sum up the first a level of functional elements, this first level of functional elements, in fact, is our main line of business, which is the core business. Clue, cc, single build, with a look, transaction, transfer. . . . .
Qualified system, the first between the need to establish a reasonable level of functional relations (practical reasons, indeed often between secondary function, is not easy to establish a rational relationship)

Third, the technical architecture of the two principles

1. When it comes to system architecture, architect organizational skills are important elements of each function of the organization is not just a system, you need to have the ability to different organizational systems. To whom is to understand and solve any problems.
Technical architecture and product architecture, must be consistent, each with a different logic to do the split, build relationships, it was a disaster
as a whole have a deep thinking and understanding of the business, we also need a stronger product abstraction.
Ninety percent of product manager, in fact, talk about the product architecture. Often talks about is the business needs, like a translator job it is business

2. 我们通常所谓的某产品，其实就是业务模式，就是流程和规则，如果业务系统的主流程和规则不是你设计的，只是翻译业务需求，那业务部门直接找技术也行得通。
   一个产品的使命是为使用者提供特定的服务，要我们通过什么样的方式为使用者提供什么样的产品和服务。所以一定是业务导向的，以业务结果的好坏评定，一切都是为业务服务的
   所谓产品架构，还是技术架构， 都是信息架构。
   作为系统业务架构师，需要时刻脑子里有个大系统的产品（技术）架构图。要有能力把
   产品功能（技术模块）抽象成信息化的层级的架构。通过功能与功能的组合、层级关系的交互传递信息的流转，整个架构图传递的是我们的业务流程、商业模式。
   产品要有技术能力，技术如果不懂产品，那再资深的工程师，也只能是码农。。。。

   ※ 这里说一下系统扩展性的问题，为最后第八章的实例做个铺垫。
   好的架构各个子系统之间相互配合形成一体化平台，子系统间只有最小的重复度独立，系统各自支持不同的业务板块，多个系统作为一个整体，共同为支撑公司业务
   可扩展性其实是在传达一个信息，我们是否了解未来这个产品会有哪些哪方面的新增加功能或者内容，也就是产品规划。
   没有人真的能预知未来，但新增功能，新的系统都会导致信息架构重新调整和使用者的认知成本。
   所谓可扩展性，就是尽可能为明天的改变降低成本，减少调整，这就需要系统架构设计是可横向共享的
   而在业务系统里什么是能横向共享的呢， 就是自始至终贯穿整个业务链条的，一般是客户，订单，商品等。所谓各系统的打通，其实就是各系统间如何有效的传递客户，商品等的信息状态
   好的架构能良好的支持业务的横向扩展。这点很重要，新的业务很多时候都在试错阶段，随时会增减业务环节，也就是不断地新的系统，新功能的融入。比如在几个流程节点上增减一个三方部门审核操作，审核系统本身不麻烦，但要做到即插即用，对接多个系统和公司多个单位，那不同的架构可能工作量差异很大
   好的业务架构各个系统的数据在业务整体上是连续的、完整的、准确的。通过数据采集，方便建立DW。可以很好的为业务运营提供数据支撑。
   好的业务架构，系统能提供的不止于业务功能，还有无时不刻无处不在的驱动各模块业务和各合作伙伴业务更好决策的数据。

   四。业务系统和用户系统

以产品为中心，是我有好的市场调研，我有牛掰的产品经理，我给你的产品就是我能做的最好的，最大可能是你需要的。
以客户为中心，适合面向运营单位，面向商家的企业级应用，理念是你需要什么
这里的你，可以是直接用户，商家，也可能是公司的销售，客服。
而你公司自己的业务系统，是需要所有人共同承担业务结果的。用户产品，你不需要承担用户使用后的结果。

理论上，只有业务系统才可以说数据是永远的程序是暂时的，用户系统不应该如是说。
如果不理解这个以产品为中心和以客户为中心的不同， 以用户产品的思路做企业级应用， 就会出发点出错，就是闹笑话。 比如，我之前的公司，明明是以CRM为主的营销管理系统，但同事们喜欢拿个淘宝网站的架构来做参考。
理论上， 用户系统里淘宝网站和人人车、链家、京东都是一样，都是把商品（车/房）展示给用户，获得订单（线索）。 作为“信息”提供方，是把自己有的东西，用自己的方式展示出来。
理解两类系统在逻辑上的差异，我也是用了很多年，过去在公司总是和同事说不清楚，其实也是我自己没想明白。可能是我在写这篇文章时候才多了些思考。

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

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

五。运营驱动

现在回答一下，什么是好的产品（业务模式）应该就是解决用户真实需求的实际痛点。从痛处入手。这里的用户可以是Toc的消费者，也可以是面向公司运营单位
产品思维：
从痛点入手，去解决问题，这是我理解的产品思维。而产品经理常常挂在嘴边的需求分析其实是个伪命题。做用户产品，产品经理能接触到多少用户了解到多少需求？ 做业务系统，北区大佬要APP，南区大佬要网页版，产品经理那个都惹不起，听谁的？
无论做什么产品，得是PM自己有能力设计主流程和规则，紧贴公司的方向和核心KPI，而不是翻译谁的需求。
至于抽象，迭代，交互设计，那可能叫产品能力更合适。 就像java能力可能是技术的基本能力，java再好和是否能开发出微博微信，没直接关系。汉语再流利，和写一篇量子力学论文基本也没关系
接上一节的话题，我认为比较合理的公司架构是运营驱动。
什么是运营？？
运营就是人为的干预规则。规则就是咱们的产品逻辑，也就是业务规则。
在电信行业出来以前，世界上是没有真正的运营的。 甚至诺基亚和微软卖出去产品，很难知道用户打了多少电话，用电脑做了什么， 而电信和互联网时代的到来，一切不一样了， 我们可以清楚的掌握业务执行结果，也就是用户使用我们的系统到底做了什么。通过使用者的使用情况，从结果知道客户需要什么，更新规则。
这套逻辑在业务系统提现得更加清楚明确， 用规则去约束销售、客户，接单后的动作，规定动作的时间等。
通过了解使用者对规则的执行情况，对比团队以及公司的KPI，分析偏差了那些，为什么偏差，再次升级系统，干预规则，干预偏差。
运营驱动，适合多个运营单位合作，非业务驱动的产品模式。很多时候，业务流程和公司组织架构的实际情况，做不到或者不需要运营驱动
✘ 多说一句，无论是做产品还是技术，掌握业务结果非常极其特别十分的重要，但大部分产品和技术都对此不感兴趣，也就限制了个人的上升空间。
业务结果分两部分，一是系统运行状况，二是使用结果。前者及格线是系统出了问题你要第一时间知道，不能等运营单位投诉再排查。后者就是每天到底多少用户，多少订单成立率转化率，这些必须关心。不能光想着系统怎么去实现，更要知道业务用你的系统做出了什么，以及每次升级为什么而做。

职场上，大家不同的能力，薪水，岗位，最终都会不同程度成为解决不同问题的人。这个说起来就是职业规划和价值观了，不多扯。但我们总得知道产品（系统）当前的问题以及产品（业务）最重要的事情（KPI）

六、数据运营

这张图，照搬我一个旧同事的PPT，至今没见过用一页纸把数据解释得如此清楚的
前面说到运营驱动，运营离不开数据。一般的公司， 在一定规模前，暂时都达不到数据运营。
不是说数据不重要。 数据能起到的作用，分三个阶段。这三个阶段简单的说就是

！ 发生了什么（报表）
! 为什么发生（数据分析）
! 将要发生什么（决策支持）。**
大多数互联网公司，包括那些上市的，其实还没解决业务发生了什么，对，说的没错。别看这么多互联网公司，包括很多上市公司，每天到底多少线索，多少订单，各种转化率，真的没谱。各团队口径差距巨大，这是大概率事情，国内也就BAT（京东，滴滴，美团不够了解）的主营业务算是数据过关。
而这页PPT真正解释牛的在右侧部分，数据正在发生什么和我期望发生什么，这比较超出我的能力， 不解释了，O(∩_∩)O哈哈~

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

七。什么是CRM

一、CRM的意义是实现收入可预期的最大化

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

客户开源和提升高质量客户的UP值贡献，理论上是管理问题，是运营策略问题。我们 所有CRM的参与者，重点是提升人效。人效，就是人均卖多少商品或人均贡献多少收入，是考核团队首要的KPI。 这里的人包括销售，运营，客服，产品和技术等。
三、 提升人效的路径，就是让机器承担更多的工作，即“服务数字化”。
标准化。标准化是数字化的基础，计算机只能保存离散的数据，所以标准化的核心是离散化的信息结构化。比如：建单、工单、分配等。
自动化。自动化指的是动态过程的数字化，比如流程、规则、权限控制的数字化。“动态”意味着各种存在依赖关系的元素互相之间的状态关系。
智能化。直观的理解就是让系统具备思考能力。这意味着系统在比较确定的上下文中具备分析能力。
我在公司时候讲解CRM，常常用比较得罪人的逻辑解释。我说，CRM的理念就是通过标准化操作，让销售和运营平庸化，所有销售业绩差异不应该过大，如果有销售总是远远超常发挥，那说明我们的业务模式出了问题。哈哈，比较得罪人，但是这套理念也适合技术团队。。。

八。业务系统架构实例

——横向共享的架构设计

复习:技术架构就是指把不同的功能元素（系统）放在适宜的环节、合适的层级，
公司的CRM应是面向企业不同运营单位的业务系统，会覆盖售前售中售后多个系统集合。我们讲技术架构是系统之间的关系，那如何建立这么多系统之间的关系？
这里讲一下一种技术架构案例，横向共享的设计
你的系统里，那些信息和信息的变化是其他系统关注的？？？

一般交易类业务有三种东西，可能是贯彻公司各业务线的。商品，客户，订单，尤其是前两种。商品和客户的信息保留在多个系统里，面向的也是企业内不同的运营单位，甚至第三方公司。
以商品为例，一个商品从采购仓储直到客户手里，生命周期可能几天到个把年。有负责采购相关的供应链部门，有负责营销的销售部门，有负责物流运输部门，还有售后等其他部门。这么多部门，对应着诸多的系统都有商品相关的信息和状态。
某个系统里，商品的状态信息变化了，其他系统如何第一时间掌握，并及时作出对应动作？？
比如一个简单的问题，商品成交了退订退货等事件，其他相关部门怎么知道呢，然后做相关处理，靠各系统间API调用？？只要业务跑两三年，保证各系统间的API成百上千，

我之前供职的一家公司，上万的员工，有个有趣的现象。供应链部门负责商品采购验收和上架，公司网站展示相应的商品。但是，二者数据长期不一致，能有多不一致。说出来吓死人，有四分之一的商品状态几年来一直对不上，每每想起，赶脚都会被人笑死。为什么会产生这样的情况? 因为供应链上架是API通知网站以及各部门，其他部门销售了，退订了商品等也是API调用供应链和网站。也就是各系统啥都是API调用，甚至什么是上架，定义都不一致，并且API调用不够稳定，又缺乏监控，也就是第五章说的产品技术都完全没有掌握业务结果的意识。。。

建设主数据，采用横向共享的设计取代系统间API调用的网状依赖。

Do what the master data, the output data are usually the main customers or commodity panoramic view, all business systems will have relevant information across business systems need to synchronize master data and obtain other relevant data from a panoramic view of the
various business truly master data open up the system

    主数据通过统一的数据采集，数据存储，数据管理，需要足够的产品认知能力和全局业务意识。
   主数据对外提供的是统一的信息查询和信息变更服务订阅，这里技术实现其实并不复杂，也就是ES和MQ。
  例如，销售系统通过主数据的“商品变革信息订阅中心”的信息订阅获取供应链上架的商品后，而供应链和售后等系统通过同样的订阅中心获取商品是否成交的信息决定商品上下架等操作

To reiterate points:

1. Call the shots more suitable for data that is merchandise and customers
2. Theoretically there may be a plurality of main data, but in actual operation, it is necessary to see the specific circumstances. For example, electricity providers, merchandise and advertising are two lines of business, or even two Division, their architecture, their transverse share, it may be more appropriate completely isolated
3. Accommodation, can refer business focus, such as we have in the end is to help businesses sell things or buy things to help the user. . .
4. Business is not a beginning, up to engage the main data, to think laterally share. In the early barbaric growth time, each system as independently as possible, we can draw a line
5. The main purpose of cross-system data sharing key data changes, should the maximum extent possible not to invade business systems. That is, do not let the business systems directly to business results to the primary data in the update, it must be by way of data collection, business systems without any change as far as possible
6. Master data do not have a direct business data, but there can be indirect. For example, cross-business index (for example: the proportion of PV website and volume), indicators of the business system itself does not concern (for example: the turnover rate of the last 10 days)
   to write a lot, I really do not know how the ending. . .