当前位置: 主页 > 组织机构 >

组织机构从 0 1 教你设想营业系统

发布时间:2018-03-26 23:19|作者:admin|       来源:未知|浏览次数:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  项目落地负责PM对最终,开持续的迭代优化系统上线后要展,产品运营深度参与,分析等数据。

  到有设计系统如果是从无,须全面贯彻以上环节必,计和模型设计尤其是架构设,中之重是重。

  业A公司某电商企,5年成立,鲜商品主营生,客户为主以C端,稳定业务,设成熟系统建。

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

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

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

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

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

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

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

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

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

  能跟进维护5个左右客户当前流程一个运营专员只,10笔订单每日处理,极低人效。

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

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

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

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

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

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

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

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

  系统定位清晰的,清边界并划,备足够的独立性可以让彼此具,扩展性的基本前提是系统灵活性和可。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  织机构树通过组,权限配置结合功能,客户的管理诉求可以实现集团。存在三个对象上图中实际上,构节点组织机,号账,店门。建模ER图通过实体,三者的关系可以描述出,下如。

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

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

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

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

  现一颗非常简单的树这样系统只需要实,根节点而没有子节点每个客户只有一个,需要编写大量的遍历算法以便业务系统开发时不,了开发难度大大降低。

  可以发现仔细观察,一个模型相比该模型与前,的变化唯一,象之间建立了关联关系是在账号和门店两个对,构不变其他结。这样处理实际上,未来的扩展性保持了模型。现组织机构管理时当未来需要全面实,间的对应关系打断将账号、门店之,实现遍历算法在业务系统中,理维护功能即可以及组织树管,基本不需要调整整个数据底层。

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

  针对门店单独报价的场景该模型体现了真实世界,系数表的设计思路同时也体现了价格。

  价单、价格系数表之间的关系理清了账号、门店、机构、报,水到渠成的事情功能设计都是。清楚这些关系如果没有梳理,计时必然是一头雾水功能设计、界面设,百出漏洞。

  后最,错误导致灾难的例子我们来看一个建模。图数据模型中如果我们将上,关系调整成一对多账号和门店的对应,下如。

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

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

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

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

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

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

  所有软件界面设计的基本前提流程图(以及页面流转图)是,异常情况的分支描述清晰的流程图和各种,面设计事半功倍可以让后续的界。晰地流程图如果没有清,对会陷入混乱界面设计绝。

  合理建模,清晰流程,变的非常简单界面设计会。计的文章也非常多网上关于界面设,也很多方法论,大可用性原则比如尼尔森十,自行查阅读者可,再赘述本文不,几个建议这里只讲。

  的软件系统的设计研究并借鉴成熟,设计能力可以提升,弯路少走。开放试用的系统网上有很多免费,用来参考都可以,Analytics比如Google,统计百度,云ERP管家婆,Force等Sales。的软件形态结合你设计,的SASS软件找到行业内相似,其排版、布局借鉴并参考,效率与合理性可以提高设计。

  系统业务,哨的前端不需要花,意的控件不需要创。入行的PM有很多初,做太多的发明创造喜欢在交互设计上,务系统对于业,不大价值,研发的工作量并且会增加。一个业务系统我曾经见过,件做的异常复杂把其中的多选控,其他的交互形态多选框中隐含了,的精力去定制开发实现导致前端需要耗费大量,有必要实在没。控件方案选用准的,前端的大量时间可以节约PM和。

  o或Axure里提供的可以绘制的控件什么叫标准的控件呢?MS Visi,准控件就是标。以外去发明创造控件不要在这些标准控件!

  报表和仪表盘设计对于复杂一点的,个组件库推荐两,ECharts一个是百度的,pse Birt一个是Ecli,经典的设计方案里边包含了大量,是开源的这两者都,接拿来用可以直。

  设计权限,中最重要的一部分是业务系统设计。体系岗位和流程的理解和拆解权限设计代表了对整个业务。

  设计包含两部分软件系统的权限,和数据权限功能权限。以操作的界面、按钮等等功能权限是指不同角色可,查询页面能看到哪些字段例如某一个角色在订单,哪些按钮能操作;同一页面中看到的数据范围数据权限是指不同角色在,页面能看到分公司的所有订单例如分公司管理员在订单查询,到所在区域的订单而区域主管只能看。

  e Based AccessControl)功能权限设计的经典方法论是RBAC(Rol,色、权限组的设计理念描述了一套用户、角,为以下实体关系图简单的可以抽象。体的讲解该理论具,络上自行查阅读者可在网,AC的数据模型图请读者理解RB,看出可以,统的设计软件系,管理体系设计即便是权限,象到数据模型的设计最终也都会归结抽。可见由此,模能力抽象建,握的核心技能是PM必须掌。

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

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

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

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

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

  其修远路漫漫,是一个厚积薄发的过程后端产品经理的成长,持、积累、思考需要长期的坚。的设计有一个大体的认知和理解希望本文能够帮助读者对系统,到工作中并融入,层次的思考形成更深。


Power by DedeCms