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

本文介绍了如何减少甚至避免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软件服务提供商常用的方法是模板重要文件，支持默认版本和选择版本。在B端产品中，互联网企业也可以采用这种方法，先为重要文件设置模板。本文件涉及的所有数据都支持设置是否显示，是否必须在文件模板上丢失。支持多版本模板、复制模板、停止使用模板、重命名模板、默认设置模板等。此外，还支持字段的自定义。例如，16个自定义字段名的字段分别支持在单据头(单据主信息)和单据体(单据明细信息)。提前定义数据类型，支持设置是否必须填写。需要使用时，根据增加的信息是否日期、文本、枚举等。当产品设计以这种方式进行时，需求方不会每天盯着添加信息和更改信息；技术合作伙伴不必急于上线；自然，随时支持管理和业务变化的许多需求。大家都开心，都开心，多香啊！3、仔细考虑频繁变化的业务流程或重要节点。大多数时候，业务的小调整和优化要么是是否之间的某种选项，要么是阈值调整，要么是增加或减少选项。这三种调整虽然不能全部覆盖，但也能应付大部分日常业务优化和调整。比如销售业务，原来的销售出库必须根据销售订单，即销售出库必须有订单选项，选择是。现在有些商品可以直接填写销售出库单，即无订单出库。如果系统有支持销售必需订单在是否之间调整的参数；那么，销售订单可以根据销售订单生成，也可以手动添加。例如，采购到货预警日期在预期到货日期前1天预警，现在调整到预期到货日期前2天预警。如果系统设置了这个参数，每次调整都不需要找技术同学操作。另一个例子是库存可用性，通常包括现有量，也可以包括采购在途量、质量检验在途量、生产在途量等可选项，那么必须包括这些吗？这可以根据企业的需务变化灵活调整。事实上，这些参数可以做得更详细。例如，根据商品类别设置是否支持无订单出库。另一个例子是否根据仓库设置库存可用性。四、最后提醒B端产品要想快速支持组织和流程变革，就要付出研发成本，这一点大家都要清楚。互联网公司讲究MVP（Minimum Viable Product，最小可用产品)，注重快速迭代，在此背景下重快速上线。但是，一旦MVP上线后，往往没有动力或总觉得这种重要不紧急的磨刀需求优先级不高，导致上述三种需求永远不会上期。当再次发生业务变化时，他们急于改变计划和产品。这样进入了一个无限循环，不断改变产品，产品技术学生，成为真正的产品扒路军。不断挑开改，改了扒，最后算下来，投入更多的资源和精力。即使有一天，也改不了，只好推翻重来。在这里，我们需要提醒你：首先要知道什么是好的，什么是对的，然后，在综合评价资源投资的前提下，我们需要朝着正确的方向前进！相信长痛不如短痛，这是智者的选择。··················END··················关于我：多年的互联网产品经验，大多数后端产品，从0到NCRM、用户订单、业务平台、业务结算…… 微信微信官方账号:产品人知明。 特别说明：本网站的主要目的是收集与互联网运营相关的干货知识，为运营伙伴提供便利。本网站收集的公共内容来自互联网或用户的贡献，这并不意味着本网站同意其观点，也不对网站内容的真实性负责。如有侵权行为，请联系网站管理员删除，。