如何从0到1设计业务系统.docx
- 文档编号:1634545
- 上传时间:2022-10-23
- 格式:DOCX
- 页数:7
- 大小:27.23KB
如何从0到1设计业务系统.docx
《如何从0到1设计业务系统.docx》由会员分享,可在线阅读,更多相关《如何从0到1设计业务系统.docx(7页珍藏版)》请在冰豆网上搜索。
如何从0到1设计业务系统
如何从0到1设计业务系统
作者|杨堃编辑|雨多田光本文转载自公众号goYangKun,聊聊架构已获授权发布。
本文以一个案例,向读者逐步揭示一套业务系统从0到1的设计过程。
重点讲述架构、模型等业务系统最本质的设计精要。
业务系统设计概述什么是业务系统互联网公司常常将产品方向分为两类,C端和B端,C端主要是面向客户和消费者的系统,B端的范围则相对模糊,给供应商或商家使用的系统,给内部业务人员使用的系统,都统称为B端系统。
C端和B端系统建设的出发点和侧重点完全不同。
C端系统偏重用户体验,强调感性,持续的数据分析优化,同一个按钮不同的摆放位置都要精心设计、论证,服务对象是个人;B端系统偏重流程、模块化,强调抽象和结构性,讲究整体的规划和体系设计,服务对象是组织和机构。
如果将B端系统进一步拆分,也可以分为两类,第一类是商家端,常见于双边模式的平台型互联网公司,例如淘宝的卖家管理系统,美团的商家管理后台;第二类是内部业务系统,支持企业经营、管理、业务运转。
本文所说的业务系统,是指B端产品线中企业内部业务系统。
虽然B端系统也可以分为两类,但因为都是面向业务的系统(Business),服务于组织而非个人,其设计思想和原理都是相同的,所以本文讲解的内容可以应用于所有B端系统的设计场景。
常见的业务系统包括ERP(EnterpriseResourcePlanning),CRM(CustomerRelationshipManagement),SCM(SupplyChainManagement),WMS(WarehouseManagementSystem),TMS(TransportationManagementSystem),OA(OfficeAutomation),HRM(HumanResourceManagement)等等。
因为绝大多数互联网公司都有独特的业务模式,所以很多时候类似于CRM、WMS、TMS这类系统都自主研发,OA、HRM这类系统由于业务模型区别不大,多数都会采购标准软件。
有些互联网巨头也会自主研发OA、HRM。
习惯上,CRM、WMS这类系统被称为业务系统,OA、HRM这类系统被称为内部协同软件,但两类系统之间也并没有非常清晰的界定。
如果从软件学的角度来看,所有软件系统分为两类,第一类是能够实时产生业务数据的系统,叫做OLTP(OnlineTransactionProcessing)系统,第二类是对数据进行加工、处理、探查、挖掘、展现的系统,叫做OLAP(OnlineAnalyticalProcessing)系统,很显然,业务系统属于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接到任务后,首先要理清工作思路,拆解任务,制定时间计划。
只有严格遵循时间计划执行工作,才能保证整体工作有序展开,如期落地。
根据经验和初步判断,产品经理制定了粗略的工作计划表如下。
时间紧,任务重,PM需要立即开展行动。
当然,计划表中的研发周期,纯粹是一个粗拍的时间,具体实施周期要结合一期项目范围,以及人力投入,在立项时细化。
业务调研与业务方案设计系统之前,必须透彻理解业务现状与业务目标,考虑如何结合系统改造、优化业务流程和模式。
此阶段可以由一个高级PM带领几个初级PM完成。
最好邀请技术负责人一起参与,有利于技术人员提前理解业务,为技术选型和方案设计做好准备。
此外,技术人员具备更好的抽象能力,深入理解业务,可以让技术负责人协助PM共同完成整体方案设计和细节方案设计。
业务调研的方法理解业务最好的方法,是轮岗参与业务环节。
此外更加便捷快速的方法,是调研访谈。
调研之前最好对业务能有大体的认知,安排好访谈的对象,提前准备好问题,让访谈更加高效。
以下是针对分销业务的访谈计划和调研表。
主持人员:
产品经理、研发经理调研对象:
业务负责人、一线主管、一线业务人员、合作伙伴调研方式:
访谈数据分析调研目标:
了解业务模式和业务特点了解业务目标和业务规划了解当前业务运转方式挖掘当前问题与痛点
业务调研总结组织架构通过调研,理清最基本的业务组织架构图,通过组织架构图理解管理体系和职能单元的设计,以及后续规划。
业务目标对关键业务指标和目标需要有相应梳理。
业务流程通过调研,梳理出目前的业务运作流程,如下图:
可以看出,目前业务开展以手工作业为主。
下单配送环节依托于公司已有的系统实现。
问题梳理基于目前手工作业流程,整理出如下业务问题:
手工下单容易出错,效率低;生鲜实时变价,每次下单要根据折扣表手工计算价格;无法实现客户总部集采,大区集采,城市集采,门店自采等混合采购模式;不支持特殊分拣、配送要求;账期客户不能及时控制回款进度和账期风险;对账和开票工作复杂,大量数据表处理,容易出错;当前流程一个运营专员只能跟进维护5个左右客户,每日处理10笔订单,人效极低。
基于业务调研的核心诉求分析基于整体调研结论,总结出分销系统解决业务难题的核心诉求如下。
客户自主下单(高优);系统自动定价(高优);支持客户多门店分别定价与下单(高优);对账报表(高优);运营人员聚焦参数设置、审核和异常问题跟进(高优);运营工作要下放到各城市分部(中优);支持账期和预付款模式(低优);系统实现账期风控(低优);我们将业务主链路确定为高优诉求,将扩展功能或针对部分客户的小众功能,以及风控功能列为低优,和业务达成一致,一期项目聚焦核心流程的实现。
业务主流程设计经过充分的沟通,设计出结合系统支持的核心业务流程。
其中,涉及到客户开发、合同审核等前置流程,依然通过线下处理完成,未来考虑实现分销业务的OCRM系统进行支持,本次项目暂不考虑。
创建一套系统或平台,支持客户签约后的账号管理、价格管理、自主下单等功能。
系统整体方案设计完成业务调研后,进入系统整体方案设计环节。
该环节需要由经验丰富的PM以及公司的架构师一起探讨完成,因为方案涉及到和公司现有应用架构融合,还需要经过产品委员会或架构组的评审和确认。
系统定位基于对业务的分析,考虑通过实现3套独立子系统来支持分销业务。
分销商城前台(H5):
分销客户的下单工具客户管理后台(PC):
分销客户的子账号管理、门店管理及业务辅助工具运营管理后台(PC):
分销业务部门对客户及商品定价管理的业务支持工具首先,客户希望能有一个便捷快速下单的工具,所以需要有一个手机版商城C端。
考虑到投入产出比,通过H5来实现,具有独立域名,外网可访问。
其次,需要有一套方便操作的管理后台,因为涉及到大量的商品编辑处理,账号、门店管理等功能,所以考虑PC版本实现,暂不支持手机版。
最后,考虑到公司运营和客户管理员的管理诉求不尽相同,操作功能和页面差异较大,所以决定将管理后台拆解为两个独立的系统,给客户管理员使用的客户管理后台,具备独立域名,外网可访问;给公司管理人员和运营人员使用的运营管理后台,具备独立域名,仅限内网访问。
设计业务系统常见的问题是为了图省事,把所有业务单元的功能糅合到一个系统中实现,造成管理的混乱,尤其是系统维护的混乱。
一般来讲,系统的抽象要结合业务完成,独立的业务职能单元,要有各自独立的系统来配合使用。
如果业务部门之间边界模糊,权责界定不清,也会导致系统之间存在模糊性。
清晰的系统定位,并划清边界,可以让彼此具备足够的独立性,是系统灵活性和可扩展性的基本前提。
整体架构设计现在,需要考虑分销平台的三个子系统,如何与公司的整体应用架构融合问题。
公司经过多年发展,系统架构体系已经非常完备,大量公共组件和模块可以复用,这样就减轻了新平台的实现成本和难度。
分销平台只需要聚焦自己业务特殊独立的地方,其他公
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 如何 设计 业务 系统