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

微信扫一扫,分享到朋友圈

B端产品如何支持组织与流程变革?
企业在经营中,业务流程变化,组织架构调整,是难以避免的事情;甚至随着市场环境、竞争格局变化的加剧,二者需要更敏捷的随需而变。

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

关于我:多年互联网产品经验,做后端产品居多,从0到N做过CRM、用户订单、商家平台、商家结算……

微信公众号:产品人晓明。

收购百科名医网,字节跳动布局医疗健康的野心

上一篇

防空反导系统的绝杀方式演进史(五):定向能新概念杀伤

下一篇

你也可能喜欢

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

长按储存图像,分享给朋友