本文介绍了3个企业在流程变化、组织架构调整时，如何减少、甚至避免B端产品伤筋动骨大调整的技巧。
企业在经营中，业务流程变化，组织架构调整，是难以避免的事情；甚至随着市场环境、竞争格局变化的加剧，二者需要更敏捷的随需而变。
当业务流程或组织架构变革时，不但带来B端产品使用角色的调整，而且经常需要产品流程的大调整、产品功能的大升级。
有些城市道路管道铺线，经常扒开马路，扒了填，填了扒，段子手就把建设工人称为“扒路军”。其实是嘲讽规划不到位，设计不科学，甚至各自为政，管线规划缺乏通盘考虑。
B端产品如果规划不合理，产品设计耦合性过高，企业每次流程变化、组织架构调整时，产品技术人员，也是充当“扒路军”的角色，把产品反复扒开改，改了扒。产品技术团队，轻则加班加点，重则拉出去封闭，把原有产品重构，翻个底朝天。
其实，SaaS（是Software-as-a-Service的缩写名称，意思为软件即服务，即通过网络提供软件服务。）软件服务商在产品设计时，对业务流程变化、组织架构调整的适应程度是挺高的。但是，大多B端产品经理并没有SaaS软件服务商的工作背景，这也难为他们了。
那么，在企业流程变化、组织架构调整时，如何减少、甚至避免B端产品伤筋动骨的大调整呢？
我结合以前在SaaS软件服务商的工作经历，提供如下几种策略。
C端订单，一个单据五六个、甚至七八个状态很正常，因为大多数这些订单状态的变化都跟用户操作有关，或者这些状态的变化都要通知用户。
比如我们常见的电商订单至少有“待支付、支付成功、已发货、已完成、已关闭”这五个状态，且这五个状态都是用户这个角色关心的。
再比如我做的旅游度假订单，用户能够看到的订单状态至少有“待支付、定金已付待付尾款、尾款分批支付中、已付全款、尾款支付超时关闭、出行中、服务完成、退改中、订单关闭”，这九个状态。
对于B端产品，就不适合在一个单据上设计多个状态了。因为，B端一个业务中，有不同的角色来处理。比如采购业务，采购员负责下单、质检员负责到货验收、仓库负责入库、采购员或财务负责对账、财务负责支付结算等。
若是B端采购业务，把所有信息都设计在采购订单上，状态复杂不说，而且不易于不同角色的人员进行操作。更重要的是，各类信息都依附于采购订单，难以支持业务流程的变化，更无法根据不同采购物资设置不同的采购流程。
试想一下，重要物资，每次采购入库都需要检验，而某些常见低价值的标准物料入库无需检验，若采购质检、采购入库信息都填在采购订单上。会造成有些单据有采购合格数量，有些物料要么自动默认合格，要么空着，多乱啊。
若哪一天采购质检标准变了，原来不需要质检的某物料现在需要质检了，当统计此物料的质检数据时，还需人为记着从什么时间开始质检的，否则，统计的数据不易解读。
解决这些问题，一般本着“高内聚、低耦合”的思路，把流程中各个节点打散，支持自由组合。
比如在采购流程中，下单、到货、质检、入库、对账、支付等环节，都是独立设计单据，每类单据可以根据上游单据生成。也可以根据业务需要省略某些单据，比如不需要质检的物资，省去采购检验单。
每类单据都单独设计单据状态，比如采购订单设计“已保存、已审核”的状态，已审核的采购订单支持生成采购到货单或采购入库单。
这样，就把长链条的采购流程解耦开了，就非常方便的支持采购流程的按需组合。当业务流程变化、企业架构变化时，按照角色重新赋予每类单据的权限就可以了。
比如采购业务某类物资，无需做到货单据，甚至无需做采购订单，直接办理采购入库。销售业务的某类产品不用依据发货单出库，直接根据销售订单出库。这种“高内聚、低耦合”的设计方式都能很好的支持。
当企业管理改善，或组织架构调整后，经常伴有业务流程的变化、管理要求的不同。对于业务流程变化的支持，在前面已给出了解决方案。而对于管理要求变化的支持，单据信息若能灵活定义，便能解决相当一部分。
比如公司要提高某类重点物资的采购到货及时率，在下达采购订单时，采购员必须要给供应商先约定采购到货周期，同时还要清楚此物资的当前可用量、日均消耗量；甚至还要针对物料填写一些备注信息。
这样做，一是明确到货时间、约定采购细节，二是可以知道余量够不够吃，避免青黄不接时断粮。
但是，没有必要每种物料这样搞，尤其是到货日期，不能采购员都填一个吧，这样也无意义呀。那怎么办呢？
临时风风火火的加班改产品方案、改程序，是一种办法。那要经常做这种调整呢？显然这不是一个好路子。
SaaS软件服务商常用的办法是，把重要单据进行模板化，在下单时，支持设置默认版本，支持选择版本。
互联网企业，在B端产品上，也可以采用这类办法，给重要的单据，先设置模板。
此单据涉及的所有数据，在单据模板上都支持设置是否显示、是否必输。支持模板多版本、支持模板复制、支持模板的停启用、支持模板的重命名、支持模板设置默认等。
除此之外，还支持字段的自定义。比如在单据头（单据主信息）、单据体（单据明细信息）分别支持16个自定义字段名的字段。给这些字段提前定义好数据类型，支持设置是否必填等。当需要使用时，根据所增加的信息是否日期类型、文本类型、枚举类型等，按需使用。
当这样进行产品设计时，需求方也不会天天背后盯着加信息、改信息了；技术小伙伴也不用急慌慌的着急上线了；管理变化、业务变化的很多需求自然也随时支持了。
仔细想一下，很多时候业务的小调整、小优化，不是某类选项在“是否”间调整，就是某个阈值调整，或者增加或减少一个选项。虽然这三类调整涵盖不了全部，但是也能应付大部分日常业务优化与调整。
比如销售业务，原来销售出库必须依据销售订单，即“销售出库必有订单”选项，选择“是”。现在针对某些商品，可以直接填写销售出库单，即“无订单出库”。若系统有参数支持“销售出库必有订单”在“是否”间调整；那么，销售出库单既可以根据销售订单生成，也可以手工添加了。
比如采购到货预警日期，原来在预计到货日期前1天预警，现在调整到预计到货日期2天前预警。系统若设置了此参数，也不用每次调整时，找技术同学操作了。
再比如库存可用量，通常包含现存量，还可以包括“采购在途量、质检在途量、生产在途量”等可选项，那么是否必须包括这些呢？这就可以根据企业需要及业务变化进行灵活调整了。
其实，这些参数化，可以做的更细。比如按商品品类设置是否支持无订单出库。再比如是否按仓库设置库存可用量等。
B端产品要想快速的支持组织与流程变革，是要付出研发成本的，这点大家要清楚。互联网公司讲究MVP（Minimum Viable Product，最小可用产品），讲究快速迭代，在这种背景下，讲究快速上线。
但是，一旦MVP上线后，经常没有动力或总感觉这类重要不紧急的“磨刀类”需求优先级不高，导致上述三类需求永远排不上期。当再有业务变化时，又是着急忙慌的改方案、改产品。
这样就进入了一个死循环，不断的改产品，产品技术同学，成了名副其实的产品“扒路军”。
不断地扒开改，改了扒，最后算下来，投入的资源、精力更多。甚至到了某一天，改不动了，只好推翻重来。
在这里，需要提醒大家的是：首先知道什么是好的、什么是对的，然后，在综合评估资源投入的前提下，需要朝正确的方向进军！
··················END··················
关于我：多年互联网产品经验，做后端产品居多，从0到N做过CRM、用户订单、商家平台、商家结算……
微信公众号：产品人晓明。
特别申明：本站的主旨在于收集互联网运营相关的干货知识，给运营小伙伴提供便利。网站所收集到的公开内容均来自于互联网或用户投稿，并不代表本站认同其观点，也不对网站内容的真实性负责，如有侵权，请联系站长删除，转载请注明出处：B端产品如何支持组织与流程变革？：https://www.zcly.cn/40023.html。
微信扫一扫 
支付宝扫一扫 
