软件开发系统类别记录

主流软件系统类别主要有以下：

 1 OA系统 ： 办公自动化（Office Automation,简称OA）是将现代化办公和计算机 络功能结合起来的一种新型的办公方式。

                        OA的核心为ezOFFICE（easyoffice），强调的就是办公的便捷方便，提高效率。

2 CRM系统： CRM（Customer Relationship Management）即客户关系管理。是指企业用CRM技术来管理与客户质检的关系。

3ERP系统： ERP是Enterprise Resource Planning（企业资源计划）的简称。

                    ERP是针对物资资源管理（物流）、人力资源管理（人流）、财务资源管理（财流）、信息资源管理（信息流）集成一体化的企业管理软件。

++++++++++++++++++++++++++++++++切割+++++++++++++++++++++++++++++++++++++

OA 、CRM、ERP都是基于MIS（信息管理）系统

导读

一、业务系统设计概述

1、什么是业务系统

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

如果将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系统建设的好坏，包括了软件系统本身，以及配套落地的管理运营体系的执行。

2、为什么要学习设计业务系统

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

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

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

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

3、业务系统设计的流程

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

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

一般来讲，一套业务系统从0到1的构建，需要经历如下环节。

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

二、业务调研与业务方案

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

1、业务调研的方法

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

主持人员：产品经理、研发经理

调研对象：业务负责人、一线主管、一线业务人员、合作伙伴

调研方式：

nbsp;      访谈

nbsp;      数据分析

调研目标：

nbsp;      了解业务模式和业务特点

nbsp;      了解业务目标和业务规划

nbsp;      了解当前业务运转方式

nbsp;      挖掘当前问题与痛点

业务目标
对关键业务指标和目标需要有相应梳理。

可以看出，目前业务开展以手工作业为主。下单配送环节依托于公司已有的系统实现。

问题梳理

基于目前手工作业流程，整理出如下业务问题。

• 手工下单容易出错，效率低；
• 生鲜实时变价，每次下单要根据折扣表手工计算价格；
• 无法实现客户总部集采，大区集采，城市集采，门店自采等混合采购模式；
• 不支持特殊分拣、配送要求；
• 账期客户不能及时控制回款进度和账期风险；
• 对账和开票工作复杂，大量数据表处理，容易出错；
• 当前流程一个运营专员只能跟进维护5个左右客户，每日处理10笔订单，人效极低； 
  

3、基于业务调研的核心诉求分析

基于整体调研结论，总结出分销系统解决业务难题的核心诉求如下。

• 客户自主下单（高优）；
• 系统自动定价（高优）；
• 支持客户多门店分别定价与下单（高优）；
• 对账 表（高优）；
• 运营工作要下放到各城市分部（中优）；
• 支持账期和预付款模式（低优）；
• 系统实现账期风控（低优）；

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

4、业务主流程设计

创建一套系统或平台，支持客户签约后的账 管理、价格管理、自主下单等功能。

深绿色部分是分销平台的三个独立子系统，墨绿色部分是涉及打通和复用的已有系统。

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

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

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

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

 3、功能抽象

基于对业务的分析，以及三套系统的定位，可以抽象并绘制完整的系统功能蓝图。

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

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

蓝色部分，是三期的项目范围，三期将聚焦风险控制，并强化运营功能。一般来讲，很多互联 公司初期会先跑业务，走流水，验证可行性，成本和风险控制并不是特别在意，当业务具备一定规模时，则必须引入系统风控机制，做到事前、事中、事后的风险控制。此外，基于本案例B2B业务的特点，设计中并没有考虑太多的C端功能。实际上C端只需要保证客户能够方便下单，并做一些很粗的运营、通知即可。 

四、系统细节方案设计

系统整体架构和蓝图设计完成后，进入细节方案设计环节。建模部分建议由高级PM和技术负责人共同完成，界面、权限设计可以由高级PM带领初级PM共同完成。

1、实体建模

实体建模是细节设计中最难，也是最重要的环节。实体建模代表将客观世界的对象，抽象成结构化的描述。实体建模有问题，会导致后续业务和系统完全丧失扩展性和灵活性，甚至会很快就无法支持业务，需要推倒重做。

实体建模实际上是数据库设计中最重要的部分，会影响数据库表结构的设计，但更多体现了对业务本质的理解和认知。很多产品经理常常忽略实体建模，只关注功能界面设计，最终会陷入逻辑的混乱和旋涡中。

只要模型清晰合理，功能设计、界面设计都是水到渠成的事。我们将结合案例，以客户模型设计为起点，详细阐述实体建模的设计思路。

理想化的客户模型

首先回顾客户诉求。目前的分销客户中，有比较大型的集团客户，下设若干省市机构和库房、门店。调研时，集团客户有如下诉求：

• 上海是中央仓库，需要由上海采购员账 下单配送到上海中央仓库；
• 广州天河区是中央仓库，需要由天河采购员下单配送到天河中央仓库；
• 广州其他区是门店自采，需要由各门店采购员下单配送到各门店；
• 广东省需要有一个高级别采购员账 ，能够帮广东各仓库和门店代下单；

以上诉求，是业务系统建设中，最经典常见的树形组织机构管理诉求。不论是公司，还是客户，作为企业，都有多层级管理的要求，希望软件系统能够支持多层级业务体系。

多层级机构管理，通常使用组织机构树实现，在一颗树上绘制出业务的管理层级体系。我们将分销业务作为组织机构管理树的根节点，客户属于子树，树形结构可以体现出客户的行政管理层级结构。将账 和门店（收货对象，可以是中央仓，也可以是店铺）作为叶子，挂在机构节点下。账 管理的数据范畴（包括能给哪些门店下单，能查看哪些门店的数据），可以遍历所在节点的子树来实现。绘制示意图如下。

每个机构都有一个“上级机构”字段，通过该字段描述的关联关系，可以绘制出完整的组织机构树。每个账 或门店，只允许隶属于一个组织机构节点，每个门店下可以维护多个收货人。

实体建模的过程，就是将业务对象抽象，并描述之间的对应关系。例如以上ER图，看似简单，但却是对组织机构树以及账 、门店管理体系的高度抽象。如果实现以上模型，可以支持任意灵活地集团客户管理诉求。

简化版的客户模型

实现组织树模型，开发复杂度很高。经过和开发、业务沟通，最终决定采用一套简版的客户模型来支持一期业务，该简版模型在需要时完全可以升级到理想版的客户模型。

首先，和业务以及客户沟通确认，一期暂不支持复杂的行政层级管理，只需要给客户实现若干子账 可以管理若干门店即可，示意图如下。

更丰富一些的客户模型

业务需求中很重要的一条，能够针对每个客户每个门店的个性 价，设置不同的系数表，结合时价动态计算商品价格。这里涉及到几个新的对象，系数表， 价单，为了让管理可控，系数表是全公司通用的多套参数集合，包括了商品和价格系数，给每个门店关联并且只能关联一个有效的 价单， 价单关联系数表，以保证运营人员只需要调整一次系数表，就能刷新到所有需要修改的门店的价格表。数据模型设计如下。

设计人员可能会认为，目前的业务诉求很明确，一个门店只能被一个账 管理，所以账 和门店被设计成一对多关系。

如果有一天，客户明确并要求必须支持一个门店被多个账 管理，也就是要实现账 和门店多对多的设计。实现此诉求，难度将非常非常大，因为从数据底层，到前端功能实现，都认为是一对多结构，如果要改成多对多，首先底层数据库结构得调整，所有历史数据要处理，其次，基本上所有涉及到读取账 和门店关系的功能代码需要全部重写，看似简单的一个改造，会造成一场灾难。

设计人员应该在设计之初，就要做好设计的预判。即便早期业务诉求是一对多，但是模型要按照多对多设计，因为这是在现实世界中合理的一种逻辑存在。即便早期没有多对多管理的诉求，但只要模型和数据底层设计好，后续再调整会简单很多。

那么问题来了，是不是所有对象的关系，都应该设计成多对多就行了呢不对，比如门店和订单的关系，只可能是一对多，不可能是多对多，一个订单只能是一个门店提交的，现实世界中不存在门店和订单多对多的逻辑关系。

建模的难点和重点，就是将现实世界抽象成对象，描述其关联关系。如果这些对象和关系没有梳理清楚，流程、界面的设计都会是一笔糊涂账。

2、用户角色设计和流程图

在整个方案中，我们设计了4个角色，来支持业务。

电商公司分销业务部

• 分销运营 – 负责分公司客户的账 维护， 价管理

客户

• 客户管理员 – 负责下单账 和门店的管理、维护，订单查询，对账结算
• 客户采购 – 负责给门店下单

角色的设计，取决于业务对权责的划分。用户角色设计完成后，可以绘制更加详细的，基于系统的流程图，如下。

我们将权限管理部分，进一步做一个延伸讨论。

假设我们实现了前文提到的完整的组织机构树，同时也有完善的权限控制体系，此时，系统可以完美的支持各种复杂的业务场景诉求。

我们在之前的角色设计中，新增一个角色“客户采购员2”，其中“客户采购员2”和“客户采购员1”的区别是，前者的数据权限范围，是查询用户当前所在组织机构树叶子上的数据，而后者能够查询用户当前所在组织机构树叶子，以及叶子下边所有子节点的数据。

不同账 ，所能看到的数据权限范围见下表。请读者结合上图和下表，自己做出判断，账 4能查看哪些门店的订单数据。如果您理解了这个案例中隐含的逻辑，则掌握了业务系统权限管理体系的主要核心思想。

 5、技术方案与项目实施

产出PRD以后，进入了技术设计和实施环节。当然，对于一套全新的系统，技术设计可能很早就已经启动。再往后，就进入实施环节，以及上线后的持续迭代和产品运营环节。以后有机会单独介绍此部分话题。

 六、总结

至此，我们结合一个实际案例，完整的介绍了一套系统从无到有的设计。介绍的重点是调研、架构、模块、建模、权限，对于交互、界面等细节一笔带过。实际上，文中已经多次强调，并且读者现在应该也有了充分的认识，抽象、流程、建模才是业务系统设计的重点和核心，只有将业务最本质的东西高度剥离并正确抽象，才能构建一套灵活强大的系统。

对于一名后端产品经理来讲，以下经验和技能必不可可少。

• 具备基本的商业、管理、运营常识；
• 理解商业模式、业务目标、组织、流程；
• 理解公司的企业应用架构和系统现状；
• 具备将客观世界抽象成架构、模块、模型的能力；