ビジネスシステム方法論の技術アーキテクチャ

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

ユーザー指向のレセプションクラスCの製品、製品マネージャにまたはユーザーがすでに習慣を育成しているかどうか、ご理解のある程度の機能は、パターンは、特定の製品モデルを確立するために十分以上のものを見て、参照も見つけることは簡単です模倣します。
しかし、多くの場合、参照および模倣せずにビジネスライクなシステムは、さまざまなビジネス・プロセスの数、組織構造少し異なる企業が、あなたの家のCRMおよびCRMは、彼の家族は何の参照を持たないことがあります。だから、製品アーキテクチャを構築することは非常にプロダクトマネージャーがビジネスを理解して必要とするとき、技術的なアーキテクチャはまた、偉大な挑戦を持っていながら、PMをテストする能力。

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

まず、作業システムは、一般的な必要性は、次の3つの分野を強化します

言うまでもない技術基盤などの基本的なサービスを提供しています。ビジネス・サービスの基礎とシステムが累積年が調整することは困難だろうしたらこれらの事前の規格は、うまく機能しない場合は、このような都市サービス、入場管理、など、無視しないでください。
ビジネスの構造と操作データは、特記の背面になります
そのビジネス・システム・アーキテクチャ・アプローチに焦点を当てます

技術アーキテクチャの第二に、三つの要素

1.三つの要素の順序がシステムに機能からでなければならず、最終的なアーキテクチャは、
機能を開始し、機能素子は、ログインなど、完全に機能的な登録を構成することができるアクションのセットの一連のことをいいます。
ユニークな作品の完全な機能要素を完了するために、ユーザによって、技術的に機能的な製品と呼ばれるモジュールと呼ばれます。
もちろん、製品設計と、とてもユニーク達成することが困難な場合が多い継続的な反復プロセスインチ 。。
システムは、互いの間に形成された直接または間接的な関係を持って、一人でこのコレクションは、顧客サービスシステムは、そのような販売システムなどの特定のユーザーのための具体的なサービスを提供することができる機能要素のコレクションを指し
、我々は技術的なアーキテクチャについて話しているが、「より多くの」独立していなければなりませんシステム間の問題。
我々は、技術的なアーキテクチャの最初のステップの話を始め、各システムは独立している必要があります、システムエンジニアリングと一緒に結合されたデータは、話すために何のインフラが存在しない
組成物との間の関係のいずれかの機能要素なしで、それはシステムと呼ばれることはできません。同システムは、任意の関係で構成されていない、何のスキーマ
2は、異なる技術の実装及び技術的アーキテクチャを区別しないように
対応するメソッドを実装するDB、ES、ロードバランシングを使用して機能し、システムのために達成します。多くの実装では、ハイテクであってもよいし、
技術の実装と技術的なアーキテクチャは、2つの異なるものですが、技術的な実装と全体的な技術アーキテクチャを混同していない
技術インフラの開発3.、我々はシステムの機能レベルを考慮する必要があります。
技術的なアーキテクチャは、適切なレベルに該当するリンク上の異なる機能要素（システム）を指し、
そして構造、プラットフォームを形成する、システムの特徴および機能、システム間の関係を構築し、大規模システムの単純性を経験します。
構造と機能の階層の表現は、実際の情報の流れとの間の関係であり、情報の異なるレベル間のいくつかの論理的な関係が存在しなければなりません。
目的はまた、しばしば異なる技術部門やビジネスユニットに対応している間のシステム間のレベルの間の相関が、同じレベルの機能は、独立していなければならないが。
はるかに複雑目次よりシステムアーキテクチャ設計のビジネスクラス。

- •モジュールは、関数によって分割される
単一の製品対象目次物、又は単一の上流および下流TOBシステムに適した、単一のユーザグループ、ユーザグループ単一、機能的および論理機能のシステムとの間ずっと存在しません
。•は、ビジネスロジックで割っB -
一緒にTOBシステムの複雑性クラス、マルチロール作業のための一連の完了するために、
同じレベル内で対処することが重要な機能（システム）、または情報アーキテクチャを引き起こす可能性が高いことは破るためにある
最初のを合計する最初の機能要素のレベルは、機能要素のこの最初のレベルは、実際には、コアビジネスであるビジネスの私達のメインライン、です。一見、トランザクション、転送とクルー、CC、単一のビルド、。。。。。
資格のシステム、機能的関係の合理的なレベルを確立する必要があるとの最初の（実際的な理由は、実際に多くの場合、二次関数の間で、合理的な関係を確立することは容易ではありません）

第三に、2つの原則の技術的なアーキテクチャ

1.それがシステムアーキテクチャになると、建築家の組織力は、組織の各機能の重要な要素であるが、単にシステムではありません、あなたは別の組織体制への能力を持っている必要があります。誰に何の問題を理解し、解決することです。
技術的なアーキテクチャと製品アーキテクチャは、関係を構築し、異なるロジックを持つ各分割を行うには、一貫していなければならない、それは災害だった
全体として、我々はまた、より強力な製品の抽象化を必要とする、ビジネスの深い思考と理解を持っています。
プロダクトマネージャーの90％が、実際には、製品のアーキテクチャについて話しています。多くの場合、翻訳者の仕事のように、それはビジネスであり、ビジネスニーズで語ります

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调用的网状依赖。

ビジネスシステムは、のパノラマビューから他の関連データをマスターデータを同期して取得する必要があり全体でのマスタデータは、出力データは、通常、主要顧客や商品のパノラマビューです何をすべきか、すべてのビジネスシステムは、関連する情報を持っています
様々なビジネスの真のマスタデータシステムを開きます

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

ポイントを繰り返すには：

1. 商品や顧客のデータのためのショットがより適切なコール
2. 理論的には存在メインデータの複数であってもよいが、実際の動作では、特定の状況を表示することが必要であることができます。例えば、電気・プロバイダー、商品や広告は、ビジネスの二行、あるいは2課、そのアーキテクチャ、彼らの横を共有している、それは完全に孤立し、より適切かもしれません
3. 宿泊は、ビジネスのフォーカスを参照することができ、我々は最終的に持っているような企業は、物事を売る助けたり、ユーザーを支援するためのものを購入することです。。。
4. 、メインデータに係合するように横方向にシェアを考えるまでビジネスは、最初ではありません。初期の野蛮な成長時間で、それぞれのシステムのように独立して可能な限り、我々は線を引くことができます
5. クロスシステムデータ共有キーデータ変更の主な目的は、最大限のビジネスシステムに侵入するべきではありません。これは、直接のアップデートで、プライマリ・データへの業績へのビジネスシステムを聞かせていないが、それは可能な限りそのままデータ収集、業務システムを経由しなければなりません
6. マスタデータは、直接ビジネス・データを持っていないが、間接的にそこにすることができます。例えば（例：PVのウェブサイトやボリュームの割合）、クロスビジネス指標、業務システム自体の指標は、（例：過去10日間の離職率）心配ない
   多くのことを書くために、私は本当に終わるのか分かりません。。。