互联网公司常常将产品方向分为两类，C端和B端，C端主要是面向客户和消费者的系统，B端的范围则相对模糊，给供应商或商家使用的系统，给内部业务人员使用的系统，都统称为B端系统。C端和B端系统建设的出发点和侧重点完全不同。C端系统偏重用户体验，强调感性，持续的数据分析优化，同一个按钮不同的摆放位置都要精心设计、论证，服务对象是个人；B端系统偏重流程、模块化，强调抽象和结构性，讲究整体的规划和体系设计，服务对象是组织和机构。

　　如果将B端系统进一步拆分，也可以分为两类，第一类是商家端，常见于双边模式的平台型互联网公司，例如淘宝的卖家管理系统，美团的商家管理后台；第二类是内部业务系统，支持企业经营、管理、业务运转。

　　本文所说业务系统，指B端产品线中的企业内部业务系统。虽然B端系统也可以分为两类，但因为都是面向业务的系统（Business），服务于组织而非个人，其设计思想和原理都是相同的，所以本文讲解的内容可以应用于所有B端系统的设计场景。

　　如果从软件学的角度来看，所有软件系统分为两类，第一类是能够实时产生业务数据的系统，叫做OLTP（Online TransactionProcessing）系统，第二类是对数据进行加工、处理、探查、挖掘、展现的系统，叫做OLAP（Online AnalyticalProcessing）系统，很显然，业务系统属于OLTP的范畴。

　　当企业发展到一定阶段，业务系统对企业的高效管理运转具备不可替代的核心作用。例如，当一家公司只有几个销售人员时，客户资料用Excel即可管理。当销售发展到上千人时，必须通过一套OCRM系统进行管理。

　　总体来讲，业务系统对企业具有四点价值：提升管控能力、控制经营风险、降低运营成本、提升销售业绩。很多时候，业务系统建设好坏决定了企业的核心竞争力，例如外卖公司之间的竞争，配送员的效率是业务成败的决定因素之一，而配送员的效率取决于TMS系统建设的好坏。当然，TMS系统建设的好坏，包括了软件系统本身，以及配套落地的管理运营体系的执行。

　　商业模式的创新是互联网行业最大的特点，商业模式的创新会带来业务模式的创新，业务模式的创新会带来运营、管理机制的创新。多数情况下，互联网公司独特的业务模式，导致无法采买市面上成熟的标准软件来支持业务，而作为技术驱动型企业，自主研发系统支持新业务成为不二的选择。

　　例如，滴滴公司，是无法在市面上找到一款成熟的司机管理运营软件的，要么找外包公司开发，要么自主研发，自主研发似乎更靠谱一些，这时，就需要有专业经验的资深产品经理，结合业务，从无到有设计一套司机（甚至是针对司机运营的机构）管理系统。

　　再例如，美团有大量的地推人员和客户需要管理，传统的OCRM软件根本无法支持美团这种强POI诉求的客户管理，因为业务模式特殊，即便采购成熟的OCRM做定制化开发，也难以使用。所以，只能靠自主研发一套全新的基于独特业务模式的OCRM来支持业务。

　　由此可以看出，互联网企业创新的本质，决定了必须有一批优秀的业务系统设计人员，能够结合公司特殊业务诉求，快速、合理的设计配套系统，并落地支持业务。业务系统的产品经理，要具备企业经营管理、软件系统设计的多方面经验和知识储备，才能设计合理的业务系统。

　　业务系统从无到有的设计，是有一套标准范式可以遵循的。实际上，随便一套《软件工程学》教程，讲述的都是业务系统的设计，但是软件工程已经不满足当前时代对专业人员的培养和要求。互联网时代下的软件设计，已经被拆分成多个细分职能，产品经理参与制定业务，设计应用功能；工程师负责技术架构，编码实施；而在传统软件工程中，这两项职能由一个角色承担。如今的现实情况是，软件设计人员更多的参与到了业务决策制定，软件研发人员越来越远离业务，只聚焦于技术。

　　即便如此，软件设计中的经典思路、方，是没有改变的。业务系统的产品经理，必须理解软件工程学中的部分核心要素，才能真正设计出靠谱的系统。

　　PM和业务负责人一起梳理、制定业务流程、制度、机制，理解业务的问题点，并确定软件系统解决方案。

　　PM结合业务诉求与目标，完成系统概要设计，包括界定业务、系统的边界，系统功能的抽象和演进蓝图，整体应用架构的设计，如何与公司已有系统拼接、交互。

　　PM完成细节方案的所有设计，包括建模、角色、界面、权限等。其中建模是最难的部分，建模好坏决定了系统未来的灵活性、可扩展性。建模要求对业务的全面理解，极强的抽象归纳能力。

　　公司在三个月前尝试开展分销业务，成立销售团队，开发分销商合作伙伴。业务试点在北京、上海开展，三个月以来发展迅速，现急需配套的软件系统提升业务效率，控制经营风险。

　　经公司管理层评估，目前分销业务月流水五十万，以月增长率20%的速度快速发展。在高速发展中若干流程、管理、风险问题突出，公司决定投入研发资源建设软件系统，支撑业务发展。

　　公司要求在2~3个月的时间内搭建出一套可以支撑分销业务2年高速发展的软件系统，提升效率，控制经营风险。项目期间CTO全力提供人力资源支持。

　　作为项目负责人，某高级PM接到任务后，首先要理清工作思路，拆解任务，制定时间计划。只有严格遵循时间计划执行工作，才能保证整体工作有序展开，如期落地。根据经验和初步判断，产品经理制定了粗略的工作计划表如下。

　　时间紧，任务重，PM需要立即开展行动。当然，计划表中的研发周期，纯粹是一个粗拍的时间，具体实施周期要结合一期项目范围，以及人力投入，在立项时细化。

　　设计系统之前，必须透彻理解业务现状与业务目标，考虑如何结合系统改造、优化业务流程和模式。此阶段可以由一个高级PM带领几个初级PM完成。最好邀请技术负责人一起参与，有利于技术人员提前理解业务，为技术选型和方案设计做好准备。此外，技术人员具备更好的抽象能力，深入理解业务，可以让技术负责人协助PM共同完成整体方案设计和细节方案设计。

　　理解业务最好的方法，是轮岗参与业务环节。此外更加便捷快速的方法，是调研访谈。调研之前最好对业务能有大体的认知，安排好访谈的对象，提前准备好问题，让访谈更加高效。以下是针对分销业务的访谈计划和调研表。

　　通过调研，理清最基本的业务组织架构图，通过组织架构图理解管理体系和职能单元的设计，以及后续规划。

　　我们将业务主链路确定为高优诉求，将扩展功能或针对部分客户的小众功能，以及风控功能列为低优，和业务达成一致，一期项目聚焦核心流程的实现。

　　经过充分的沟通，设计出结合系统支持的核心业务流程。其中，涉及到客户开发、合同审核等前置流程，依然通过线下处理完成，未来考虑实现分销业务的OCRM系统进行支持，本次项目暂不考虑。

　　完成业务调研后，进入系统整体方案设计环节。该环节需要由经验丰富的PM以及公司的架构师一起探讨完成，因为方案涉及到和公司现有应用架构融合，还需要经过产品委员会或架构组的评审和确认。

　　首先，客户希望能有一个便捷快速下单的工具，所以需要有一个手机版商城C端。考虑到投入产出比，通过H5来实现，具有独立域名，外网可访问。

　　其次，需要有一套方便操作的管理后台，因为涉及到大量的商品编辑处理，账号、门店管理等功能，所以考虑PC版本实现，暂不支持手机版。

　　最后，考虑到公司运营和客户管理员的管理诉求不尽相同，操作功能和页面差异较大，所以决定将管理后台拆解为两个独立的系统，给客户管理员使用的客户管理后台，具备独立域名，外网可访问；给公司管理人员和运营人员使用的运营管理后台，具备独立域名，仅限内网访问。

　　设计业务系统常见的问题，是为了图省事，把所有业务单元的功能糅合到一个系统中实现，造成管理的混乱，尤其是系统维护的混乱。一般来讲，系统的抽象要结合业务完成，独立的业务职能单元，要有各自独立的系统来配合使用。如果业务部门之间边界模糊，权责界定不清，也会导致系统之间存在模糊性。

　　现在，需要考虑分销平台的三个子系统，如何与公司的整体应用架构融合问题。公司经过多年发展，系统架构体系已经非常完备，大量公共组建和模块可以复用，这样就减轻了新平台的实现成本和难度。分销平台只需要聚焦自己业务特殊独立的地方，其他公共组建和模块复用已有系统即可。

　　关于如何理解公司应用架构图，可参考本人之前的文章《从一个故事说起，谈谈企业应用架构的演变史》。

　　电商是公司的主营业务，有成熟的订单体系和仓配体系，分销业务的独特性在于前置客户管理维护，下单后的分拣配送业务流程都一样，所以分销商城的订单中心直接复用已有订单中心，订单写入后续的处理流程完全不变，只需要订单中心稍作改造即可支持，这样也可以保证整个订单台账、财务、仓储、配送基本都不需要重写或改造。另外分销平台的商品中心复用已有商品中心SKU数据，只是价格管理模块部分需要新做一套独立的，以支持特殊报价业务。

　　分销业务的账户体系、权限管理体系、在线支付，都利用已有系统实现，其中账户体系要做改造，支持子母账号管理，在线支付完全复用即可。

　　客户资料的存储，利用已有的客户主数据（MDM）实现，MDM改造较大，要新做一套企业客户数据模型。虽然是新做，但是在架构上，必须将客户资料作为主数据来建设，统一管理维护。

　　最后一个问题，既然公司已经有C端商城，为什么要单独再做一套针对分销客户的C端商城？经过分析评估，两套商城整体区别较大，如果对原有商城进行改造支持分销业务，第一工时投入比新做一套还要大，第二会影响主营业务系统的健壮性，因此最终决定新做C端商城支持分销业务。

　　功能模块图，是对业务诉求系统化设计的进一步高度抽象。模块的设计，要体现出同一个业务职能单元中不同业务场景和操作的集合，模块也代表了系统中的一二级导航菜单的设计。常见的问题，是设计人员对模块设计的随意和混乱，以及后来新增功能的随意摆放，会造成用户使用系统时产生困惑，同时还会导致开发人员编码设计的混乱。

　　功能模块图，代表了设计师对业务和系统本质的理解和提炼，包含了对业务、系统未来发展的展望。我们常说，系统建设要有规划和节奏，实际上功能模块图就是一幅远景规划蓝图，是系统的骨架，决定了系统的整体结构，结合业务需求，每一个具体功能的实现，都是在对骨架不断地填充血肉，让他更真实，更立体，更丰富。

　　随着业务的开展，变化，功能模块图可能会有新的规划和调整，但如果业务单元的本质和模式没有变化，功能模块图不应该出现结构性的调整和改动。

　　我们已经绘制了系统的功能模块图，体现了业务和系统规划的脉络，现在，让我们开始研究这套“体系”，大概需要几期实现，每期实现的侧重点是什么，也就是常说的演进蓝图，Roadmap。

　　白色部分，是一期的项目范围，聚焦解决最基本的业务流程线上化问题，以及最痛的痛点，例如对账功能。一期功能有一个原则，凡是可以手工处理和解决的问题，都不做系统支持。所以，类似于“报表”，可以定期跑sql实现；类似于“价格系数设置”，考虑到维护频率低，可以由RD在后台改数据库完成；类似于“搜索、推荐”，并不影响客户下单，因为根据调研目前每个客户维护的最多sku数量只有二十个，没有搜索功能并不会严重影响客户下单效率。

　　绿色部分，是二期的项目范围，二期将解决部分特殊业务刚需的诉求，例如要支持“预付款”模式，“账期”模式，“管理”，如果时间允许，可以一并实现若干报表查询功能。

　　蓝色部分，是三期的项目范围，三期将聚焦风险控制，并强化运营功能。一般来讲，很多互联网公司初期会先跑业务，走流水，验证可行。