|
无论做什么事情时，我们总是希望能深谙其道、举一反三，找到底层逻辑和运转规律，这就需要我们多加观察、学习、积累、总结，继而形成自己的方法论。
上学、做研究、创业、做产品规划、系统设计无不如此。本篇文章以木笔本人切身经验分享一些B端系统设计的方法和步骤，希望对一些新老朋友有所帮助。
在做系统设计时，遇到一个业务提的一个新的需求丢过来时，新手小Z经常焦头烂额，就算对既有系统和流程已经很熟悉了，在设计新的功能时还是漏洞百出。
而老道的产品的老A却总能得心应手，即便对过往业务不是很了解，经过几天的学习，也总能设计出一份业务方比较满意的方案，而且漏洞较少。
两人的差距在哪呢？不是责任心，不是态度，而是产品底层设计能力。因为老A经过多年摸爬滚打，总结了一套放之四海而皆准的产品法则，这套法则足以让老A驰骋产品界，立马定江山。
小Z对老A仰慕至极，虚心求教，老A笑着送给了小Z9个字：理流程，定单据，填功能。而这9个字正是老A总结的产品箴言，可放诸四海，童叟无欺。
第一步：理流程。
当接到一个新的项目需求时，不要上来就开始聊系统实现，应该先和业务方一起把主干流程梳理一遍，保证流程是通畅无阻且切实可行的。
流程理顺了，业务方的诉求也就清晰了，是否可行，哪些环节有坑都一目了然了，同时在梳理的过程中，系统层面的流程节点也比较清晰了。
第二步：定单据。基于业务流程各关键环节的产出归纳出系统的单据和状态，用单据存储业务的过程数据，用状态管理流程的关键节点。
第三步：填功能。针对需要系统支持的环节，设计系统功能，并与流程和单据相对应。
做系统设计和盖实体大楼流程是一样的，理流程的过程就像做规划，是搞清楚业务诉求和分析可行性的过程，比如这块地未来是要做商业中心还是盖住房，楼间距几何、地面规划如何等。
定单据就是打地基，把楼宇的主体结构固定下来，确定结构框架、材质和关键施工环节，然后开始动工。
填功能是最后的装修阶段，是在主体结构上进行包装、把最终成果呈现出来。
流程是方向、单据是执行，功能是落地，流程决定了要什么，单据设计决定了怎么做，功能实现则决定做成什么样子，三者相应相辉，一起达成业务目标。
▲系统设计核心3要素：流程、单据和功能
一、理流程：庖丁解牛，理清业务和系统流程
在B端业务里，尤其是供应链这一类偏重业务流程和多系统交互的领域，流程是业务开展的基础，几乎所有的需求都来源于流程。
当我们接到一个新的需求时，应该花50%以上的时间用于梳理流程，流程的梳理分为业务流程和系统流程两部分。
业务流程由业务负责规划，用于描述操作流程的顺序，关键元素是[操作角色][操作节点]；系统流程由产品经理负责出具，是对业务流程分析后产出的系统交互流程，重在梳理系统之间的交互逻辑，关键元素是[操作系统][系统功能]，下图是业务流程和系统流程的泳道图对比。
▲系统流程图与业务流程图
根据不同的业务场景，流程可以分为主干流程、辅助流程、异常流程三种：
-
主干流程：处理业务必不可少的主流程，就像树的主干一样，不实现就没法满足业务诉求，比如采购的建单、仓库的收货、上架等；
-
辅助流程：从主干流程分出来的子流程，如同树的细枝末节，属于锦上添花，实现了有利于业务更好开展，不实现也不会影响，比如导入采购明细、批量收货、批量上架等；
-
异常流程：出现异常情况的处理流程，也必须实现，否则遇到异常了就出现了流程卡点，比如采购单的驳回、收货错误修改、出库拣货异常等；
通常来说，主干流程和异常流程优先级最高，必须在项目上线时就要具备，但异常流程因为不经常发生，如果工期赶不上，可以考虑用简单的方案替代（比如业务方线下处理）。辅助流程一般不紧急，可根据资源情况安排，如果项目第一期排不上，可放到后续迭代版本中。
▲如何梳理流程
在梳理业务流程时，我们可以遵循先主干再异常，最后分支的原则，尽量把项目中涉及到的流程以及每一个操作角色、操作环节都清晰地描绘出来，然后再对着操作节点梳理系统功能。
有些操作节点是需要系统功能支持的（比如采购建单、收货），就需要有与之对应的系统功能，还有一些是纯线下行为（比如搬运、清扫），则不需要系统功能。
另外，操作节点和系统功能并不是一对一的，有的操作可能需要多个功能支持，也可能多个操作只对应一个功能。
系统功能梳理出来以后，我们接着梳理每个功能对应的输入和输出，有些输入和输出只体现在信息流上，有些则需要其它形式的产出。
例如仓库收货完成时，我们需要对收货的结果和过程数据保存下来，这是信息层面的输出，同时还需要为收货员打印一张纸质的收货单，这是实体单据输出。在梳理的过程中要对各环节的输入和输出做详细的记录和拆解，这是我们下一步设计单据和状态的依据。
流程梳理的最后一步是做系统划分，将系统功能与当前已有的系统进行匹对，定位每个系统功能的系统边界，如果还没有系统，正好以此梳理结果为依据做系统规划。
系统的划分并没有严格的执行标准，有些处于两个系统交界的功能放在A系统也行，B系统也行（例如两个系统交互时，枚举值的映射），这时可以根据架构合理性、资源情况和操作便捷性等因素综合评估。
二、定单据：框架构建，明确单据和状态
在B端系统中，单据是用来存储和流转业务信息的凭证。系统流程及各环节的产出梳理出来以后，就可以以此规划系统单据和单据状态了。
单据有两大核心要素：关键属性和流转状态。关键属性来源于流程各环节的产出，记录业务开展过程中的详细数据，流转状态设计来源于系统关键节点的变化，记录流程的流转过程。
系统流程的每一个环节都会有输入和输出，输出的信息需要保存下来，这些信息就是单据的属性，也是最原始的单据数据，还是下一环节的输入数据。
我们试着对各环节的产出数据进行提炼，如果发现下一环节与上一环节的信息集合一样，只有个别信息不同，则可以将这两个环节设计为一个单据，但如果差异非常大，就需要设计成不同的单据。
例如下图中，采购的结果会生成采购单，我们需要设计一张采购单来承载采购的所有信息，收货的输入信息来源于采购明细。
但由于收货结论与采购明细相差很大，两者并不是一个维度的数据集合，采购单产生于采购系统，收货则是在仓储系统，一条采购明细会生成多条收货明细，所以收货结论需要单独设计一张收货单来承载。
另外，收货结论会作为验收的输入信息，但验收和收货只是入库流程中的两个环节，并无很大的差异，所以可以统一设计到收货单中，根据状态加以区分（当然不同业务形态下的流程不尽相同，如果验收需要对收货结论进一步拆分或合并，则二者就无法共用单据存储，就需要设计不同的单据了）。
▲如何定义单据
系统流程的流转是基于单据的流转状态来的，单据流转状态是单据的非常重要的属性，也是驱动流程流转的灵魂。
状态设计来源于系统关键节点的变化，在规划状态时，我们需要把系统流程从头到尾所有的节点都整理成线，然后挑出哪些是影响流程流转的关键节点，对节点的流向结果进行提炼，便得到了单据的状态。
例如仓库入库流程中，供应商到货以后，会分别进行①供应商签到→②仓库收货或拒收（合格品验收，不合格拒收）→③仓库验收→④仓库入门上架等4个节点，根据4个节点的输出结论，便能分别设计出供应商签到、收货完成、拒收、验收完成、上架完成等5个收货单状态（当然这只是最简单的举例，实际仓库收货流程会复杂的多），如图所示。
▲根据系统节点设计单据状态
我们在设计单据状态时，需要遵循几个原则：
-
状态之间应该是平行且互斥的，不能存在交集。
-
状态之间流转应该有清晰流向，是线型而不是网型，不要相互穿插跳跃。
-
状态的设计不是凭空捏造的，必须和某个关键节点相呼应，由节点触发状态机流转。
-
状态设计最好只有一个开始节点，但可以有多个结束节点（正常结束状态和异常结束状态分开）。
-
状态设计应该足够精简，只有对关键逻辑产生影响的节点，才适合设计为状态。
三、填功能：破茧而出，实现系统功能
当流程和单据梳理清晰以后，系统设计就成功了80% 了，最后20%在于系统功能的填充和实现，将功能按照业务需要的风格输出，形成系统原型和需求文档。
在填充系统功能时，也是有章可循的，我们需要依赖前面所做的流程梳理和系统单据：
1）首先，将流程节点中的线下操作流程和系统处理流程进行分类，只有系统处理流程是需要实现系统功能的。
2）接着，基于各环节的输入和输出信息设计对应的功能。功能包含带页面的操作性功能，以及不需要页面的系统逻辑处理功能，输入信息对应到系统功能上通常是查询条件、信息录入、导入等功能，输出信息通常对应查询结果、存储信息、操作日志、导出等功能。
3）然后，将关键功能与单据的状态变更结合起来，梳理出每个功能的详细逻辑以及对应的单据状态变更，系统功能便设计完成了。
4）最后，功能设计完以后，将系统功能和非系统功能串在一起验证一下是否和业务流程预期一致，不能出现流程盲区和卡点；若有，则继续完善，直到整个业务流程通畅无阻。
在设计B端系统功能设计时，可以参考尼尔森经典十原则，同时一定要遵循实用大于美观的原则，这里总结几个设计小贴士：
1）页面功能应该分清主次，页面越简单越好，这样的学习成本和实现成本最低，拒绝花里胡哨。
2）同一个系统内各页面设计的控件、页面布局、风格、颜色、字体应该统一，且符合大众操作习惯。
3）如果可以，页面应该聚焦，尽量在一个页面完成核心操作，少做跳转，因为每一次跳转都是动作和时间上的浪费。
4）批量操作很有用，例如查询时可以查多个SKU、操作时可以批量审核等，系统的一个批量功能，可能会给业务的操作效率带来飞跃。
5）操作记录很重要，当出现问题需要排查时，日志是案发现场最好的黑匣子，所以无论如何，核心操作的日志功能不要省，否则总有一天，会为自己的一时懒惰埋单。
6）设计一个好的灰度策略，通过新老流程并行，由老流程逐步过渡到新流程，有问题了也可以随时切换，可以极大的降低项目风险。
以上便是老A的系统设计9字箴言了，掌握了这个方法，再复杂的系统设计也能够层层剖析，直到最终落地，如庖丁解牛。
方法本身并不神奇，其实就是需求分析和拆解的过程，但知易行难，每一步的技能磨练都需要我们怀谦卑之心深扎到一线去摸爬滚打才能慢慢领悟，这个过程叫做经验，不经历就无法得验。
如果问我有没有更快的系统设计成长技巧，答案是肯定的，就两个字：实战！百闻不如一见，百看不如一试，唯有多加实战才能在真实的业务环境和项目压力中迅速成长，继而逐渐找到自己的方法论，以不变之策应万变之事。 到那时，你且看他……
注：本文转载自网络，如有侵权，请联系删除
| 
京公网安备 11010602105141号
