B端产品如何支持组织与流程变革 .docVIP

B端产品如何支持组织与流程变革 本文介绍了3个企业在流程变化、组织架构调整时，如何减少、甚至避免B端产品伤筋动骨大调整的技巧。 企业在经营中，业务流程变化，组织架构调整，是难以避免的事情；甚至随着市场环境、竞争格局变化的加剧，二者需要更敏捷的随需而变。 当业务流程或组织架构变革时，不但带来B端产品使用角色的调整，而且经常需要产品流程的大调整、产品功能的大升级。 有些城市道路管道铺线，经常扒开马路，扒了填，填了扒，段子手就把建设工人称为“扒路军”。其实是嘲讽规划不到位，设计不科学，甚至各自为政，管线规划缺乏通盘考虑。 B端产品如果规划不合理，产品设计耦合性过高，企业每次流程变化、组织架构调整时，产品技术人员，也是充当“扒路军”的角色，把产品反复扒开改，改了扒。产品技术团队，轻则加班加点，重则拉出去封闭，把原有产品重构，翻个底朝天。 其实，SaaS（是Software-as-a-Service的缩写名称，意思为软件即服务，即通过网络提供软件服务。）软件服务商在产品设计时，对业务流程变化、组织架构调整的适应程度是挺高的。但是，大多B端产品经理并没有SaaS软件服务商的工作背景，这也难为他们了。 那么，在企业流程变化、组织架构调整时，如何减少、甚至避免B端产品伤筋动骨的大调整呢？ 我结合以前在SaaS软件服务商的工作经历，提供如下几种策略。 一、多状态单据需要拆单，并支持流程可定义 1. B、C端订单状态个数对比 C端订单，一个单据五六个、甚至七八个状态很正常，因为大多数这些订单状态的变化都跟用户操作有关，或者这些状态的变化都要通知用户。 比如我们常见的电商订单至少有“待支付、支付成功、已发货、已完成、已关闭”这五个状态，且这五个状态都是用户这个角色关心的。 再比如我做的旅游度假订单，用户能够看到的订单状态至少有“待支付、定金已付待付尾款、尾款分批支付中、已付全款、尾款支付超时关闭、出行中、服务完成、退改中、订单关闭”，这九个状态。 对于B端产品，就不适合在一个单据上设计多个状态了。因为，B端一个业务中，有不同的角色来处理。比如采购业务，采购员负责下单、质检员负责到货验收、仓库负责入库、采购员或财务负责对账、财务负责支付结算等。 2. B端单据设计不合理，是症结所在 若是B端采购业务，把所有信息都设计在采购订单上，状态复杂不说，而且不易于不同角色的人员进行操作。更重要的是，各类信息都依附于采购订单，难以支持业务流程的变化，更无法根据不同采购物资设置不同的采购流程。 试想一下，重要物资，每次采购入库都需要检验。而某些常见低价值的标准物料入库无需检验，若采购质检、采购入库信息都填在采购订单上，会造成有些单据有采购合格数量。有些物料要么自动默认合格，要么空着，多乱啊。 若哪一天采购质检标准变了，原来不需要质检的某物料现在需要质检了；当统计此物料的质检数据时，还需人为记着从什么时间开始质检的。否则，统计的数据不易解读。 3. 解决方案 解决这些问题，一般本着“高内聚、低耦合”的思路，把流程中各个节点打散，支持自由组合。 比如在采购流程中，下单、到货、质检、入库、对账、支付等环节，都是独立设计单据，每类单据可以根据上游单据生成。也可以根据业务需要省略某些单据，比如不需要质检的物资，省去采购检验单。 每类单据都单独设计单据状态，比如采购订单设计“已保存、已审核”的状态，已审核的采购订单支持生成采购到货单或采购入库单。 这样，就把长链条的采购流程解耦开了，就非常方便的支持采购流程的按需组合。当业务流程变化、企业架构变化时，按照角色重新赋予每类单据的权限就可以了。 比如采购业务某类物资，无需做到货单据，甚至无需做采购订单，直接办理采购入库。销售业务的某类产品不用依据发货单出库，直接根据销售订单出库。这种“高内聚、低耦合”的设计方式都能很好的支持。 二、单据模板化，需支持多版本 1. 需求场景 当企业管理改善，或组织架构调整后，经常伴有业务流程的变化、管理要求的不同。对于业务流程变化的支持，在前面已给出了解决方案。而对于管理要求变化的支持，单据信息若能灵活定义，便能解决相当一部分。 因采购业务好理解，还是拿它举例子。 比如公司要提高某类重点物资的采购到货及时率，在下达采购订单时，采购员必须要给供应商先约定采购到货周期，同时还要清楚此物资的当前可用量、日均消耗量；甚至还要针对物料填写一些备注信息。 这样做，一是明确到货时间、约定采购细节；二是可以知道余量够不够吃，避免青黄不接时断粮。 但是，没有必要每种物料这样搞。尤其是到货日期，不能采购员都填一个吧，这样也无意义呀。 那怎么办呢？ 2. 解决方案 临时风风火火的加班改产品方案、改程序，是一种办法。 那要经常做这种调整呢？ 显然这不是一个好路子。 SaaS软件服务商常用的办法是：把重要单据进行模板化，在