如何从0到1设计业务系统

如何从0到1设计业务系统

作者｜杨堃编辑｜雨多田光本文转载自公众号goYangKun，聊聊架构已获授权发布。本文以一个案例，向读者逐步揭示一套业务系统从0 到1 的设计过程。重点讲述架构、模型等业务系统最本质的设计精要。业务系统设计概述什么是业务系统互联网公司常常将产品方向分为两类，C 端和 B 端，C 端主要是面向客户和消费者的系统，B 端的范围则相对模糊，给供应商或商家使用的系统，给内部业务人员使用的系统，都统称为 B 端系统。C 端和B 端系统建设的出发点和侧重点完全不同。C 端系统偏重用户体验，强调感性，持续的数据分析优化，同一个按钮不同的摆放位置都要精心设计、论证，服务对象是个人；B 端系统偏重流程、模块化，强调抽象和结构性，讲究整体的规划和体系设计，服务对象是组织和机构。如果将 B 端系统进一步拆分，也可以分为两类，第一类是商家端，常见于双边模式的平台型互联网公司，例如淘宝的卖家管理系统，美团的商家管理后台；第二类是内部业务系统，支持企业经营、管理、业务运转。本文所说的业务系统，是指 B 端产品线中企业内部业务系统。虽然B 端系统也可以分为两类，但因为都是面向业务的系统（Business），服务于组织而非个人，其设计思想和原理都是相同的，所以本文讲解的内容可以应用于

所有B 端系统的设计场景。常见的业务系统包括ERP （EnterpriseResource Planning），CRM（CustomerRelationship Management），SCM（Supply ChainManagement），WMS （WarehouseManagement System），TMS （TransportationManagement System），OA（Office Automation），HRM（Human ResourceManagement）等等。因为绝大多数互联网公司都有独特的业务模式，所以很多时候类似于CRM、WMS、TMS 这类系统都自主研发，OA、HRM 这类系统由于业务模型区别不大，多数都会采购标准软件。有些互联网巨头也会自主研发OA、HRM。习惯上，CRM、WMS 这类系统被称为业务系统，OA、HRM 这类系统被称为内部协同软件，但两类系统之间也并没有非常清晰的界定。如果从软件学的角度来看，所有软件系统分为两类，第一类是能够实时产生业务数据的系统，叫做OLTP（Online TransactionProcessing）系统，第二类是对数据进行加工、处理、探查、挖掘、展现的系统，叫做OLAP（Online AnalyticalProcessing）系统，很显然，业务系统属于OLTP 的范畴。当企业发展到一定阶段，业务系统对企业的高效管理和运转会起到不可替代的核心作用。例如，当一家公司只有几个销售人员时，客户资料用Excel 即可管理；而当销售发展到上千人时，必须通过一套OCRM 系统进行管理。总体来讲，业务系统对企业具有四点价值：提升管控能力控制经

营风险降低运营成本提升销售业绩很多时候，业务系统建设好坏决定了企业的核心竞争力，例如外卖公司之间的竞争，配送员的效率是业务成败的决定因素之一，而配送员的效率取决于TMS 系统建设的好坏。当然，TMS 系统建设的好坏，包括了软件系统本身，以及配套落地的管理运营体系的执行。为什么要学习业务系统的设计商业模式的创新是互联网行业最大的特点，商业模式的创新会带来业务模式的创新，业务模式的创新会带来运营、管理机制的创新。多数情况下，互联网公司独特的业务模式，导致无法采买市面上成熟的标准软件来支持业务，而作为技术驱动型企业，自主研发系统支持新业务成为不二之选。举个例子，滴滴公司是无法在市面上找到一款成熟的司机管理运营软件的，要么找外包公司开发，要么自主研发。自主研发似乎更靠谱一些，这时，就需要有专业经验的资深产品经理，结合业务，从0 到1 去设计一套司机（甚至是针对司机运营的机构）管理系统。再例如，美团有大量的地推人员和客户需要管理，传统的OCRM 软件根本无法支持美团这种强POI 诉求的客户管理，因为业务模式特殊，即便采购成熟的OCRM 做定制化开发，也难以使用。所以，只能靠自主研发一套全新的基于独特业务模式的OCRM 来支持业务。由此可以看出，互联网企业创新的本质，决定了必须有一批优秀的业务系统设计人员，能够结合公司特殊业务诉求，快速、合理地设计配套

系统，并落地支持业务。业务系统的产品经理，要具备企业经营管理、软件系统设计的多方面经验和知识储备，才能设计出合理的业务系统。业务系统设计的流程业务系统从无到有的设计，是有一套标准范式可以遵循的。实际上，随便一套《软件工程学》教程，讲述的都是业务系统的设计，但是软件工程已经不满足当前时代对专业人员的培养和要求。互联网时代下的软件设计，已经被拆分成多个细分职能：产品经理参与制定业务，设计应用功能；工程师负责技术架构，编码实施；而在传统软件工程中，这两项职能由一个角色承担。如今的现实情况是，软件设计人员更多地参与到了业务决策制定，软件研发人员越来越远离业务，只聚焦于技术。即便如此，软件设计中的经典思路、方法论，是没有改变的。业务系统的产品经理，必须理解软件工程学中的部分核心要素，才能真正设计出靠谱的系统。一般来讲，一套业务系统从0 到1 的构建，需要经历如下环节。业务方案设计PM 和业务负责人一起梳理、制定业务流程、制度与机制，理解业务的问题点，并确定软件系统解决方案。系统整体方案设计PM 结合业务诉求与目标，完成系统概要设计，包括界定业务、系统的边界，系统功能的抽象和演进蓝图，整体应用架构的设计，如何与公司已有系统拼接、交互。系统细节方案设计PM 完成细节方案的所有设计，包括建模、角色、界面与权限等。其中建模是最难的部分，建模好坏决定了系统

未来的灵活性、可扩展性。建模要求对业务的全面理解，需要极强的抽象归纳能力。实施验收PM 对最终项目落地负责，系统上线后要展开持续的迭代优化，深度参与产品运营、数据分析等。如果是从无到有设计系统，以上环节必须全面贯彻，尤其是架构设计和模型设计，是重中之重。案例：某电商公司的渠道销售系统设计接下来将结合一个虚拟的案例，逐步论述，帮助读者理解以上所有的设计环节。背景某电商企业A 公司，成立 5 年，主营生鲜商品，以 C 端客户为主，业务稳定，系统建设成熟。诉求公司在三个月前尝试开展分销业务，成立销售团队，开发分销商合作伙伴。业务试点在北京、上海开展，三个月以来发展迅速，现急需配套的软件系统提升业务效率，控制经营风险。评估经公司管理层评估，目前分销业务月流水五十万，以月增长率20% 的速度快速发展。在高速发展中若干流程、管理、风险问题突出，公司决定投入研发资源建设软件系统，支撑业务发展。任务公司要求在2~3 个月的时间内搭建出一套可以支撑分销业务 2 年高速发展的软件系统，提升效率，控制经营风险。项目期间CTO 全力提供人力资源支持。工作计划作为项目负责人，某高级PM 接到任务后，首先要理清工作思路，拆解任务，制定时间计划。只有严格遵循时间计划执行工作，才能保证整体工作有序展开，如期落地。根据经验和初步判断，产品经理制定了粗略的工作计划表如下。时间紧，