ToB的产品设计，如何在客户定制化需求下避免产品越来越笨重？美团外卖|国标|发布|实施|接触

编辑导读：To B产品因为面向的客户是企业，其业务多且复杂，对产品的定制化需求较高。但是作为一个标准化的产品，定制化越多，整合融入的系统、功能越多、系统也越来繁雍笨重。那么，如何在满足用户定制化的需求下，避免产品变得笨重呢？本文作者对此给出了一些建议，与你分享。

文章插图
一、明晰：ToB 的商业模式ToB 的全称是“To Business”，即面向企业。企业往往拥有比较复杂的业务，且个性化很强，通常需要他们自掏腰包来解决自己的困难。这就会要求所购买的产品必须能够满足自己的全部需求，产品价格要跟产品价值（满足需求）相匹配。当 B 端客户需要你的某个功能时，你可以编各种各样的理由来搪塞他或者说正在开发中，但不可以说你没有，否则会给人一种很不专业的感觉（侧面反映产品不成熟、积累案例少、不能快速响应信息化建设。所以对于大部分 ToB 产品，不存在直接拿 MVP 去卖的情况。因为客户需要你能给出对某一项业务完整的解决方案（思路），哪怕是低保真产品原型或 PPT ，都比一个没做好的 MVP 更具说服力。
【ToB的产品设计，如何在客户定制化需求下避免产品越来越笨重？】问题：定制化越多、功能越繁雍笨重
ToB的产品目前最流行的模式是高度灵活、自由可配置；公司设计研发出一套所谓能够涵盖行业80%标准化的系统流程，在用户购买之后采用根据客户不同需求做配置，满足用户需求。这是一个理想状态，现实中，每个企业、学校、机构的实际业务不同，使用者关心的业务和流程不尽相同，就出现很多的需求无法通过配置满足的现实需求状况。由此定制化开发的模式就被各厂商放到了桌面。
定制化开发过程中会有新的流程、功能被挖掘，这些确实能解决现实行业中的出现的一些个性化、特殊化的实际问题；但是如果不加辨别，认为只要能够解决行业问题的方案就应该纳入系统，进而考虑把每个客户需求进行整合，弥补现有系统的不足，设计研发出“大而全”的系统，对于想做平台或者垄断行业利润的厂商，具有巨大的诱惑力。
这样一来，定制化越多，整合融入的系统、功能越多、系统也越来繁雍笨重；造成系统万能，却又没有什么卖点，对内公司人员怨声载道，对外给人系统拼拼凑凑的印象，在市场没有什么竞争力，什么都有，什么都不强，又冗余难用；尽管付出这么大的代价，事实上这样的系统依然无法覆盖用户所有需求，因为你永远不知道下一个客户需要什么？
二、系统臃肿问题实质与避免建议系统臃肿问题实质：

多模块多页面信息存在大量重复（即有些字段信息没必要每个地方都显示，具体看需求）；
功能点堆砌，即可能存在需求但是没有场景化。即有些功能点应该是连贯性和，应该是一步接一步的（如买火车票：提交完订单后，下一步当然是付款，你总不能让这两个功能分开放吧？）
存在部分“低需求功能点”，有些功能点现在基本没怎么用还留在系统中。
系统业务组织架构、功能权限、数据权限等模型不能支撑现在的业务发展（这是最蛋疼的，基本是最大系统的问题），导致每次增加新功能点时只能在逻辑上写死，没有任何逻辑和程序上的扩展性。

解决问题建议：
先梳理下现在的公司业务流程和组织架构（找公司各部门负责人多问问）；
根据上面四点对系统现在的业务流程、组织架构、功能模块、功能点进行梳理，找出存在问题的地方，分别列出问题表单和问题点；
拿着问题表单和问题点去调研各个部门的负责人和使用者，看看反馈结果；并顺便调研现在的业务需求和流程场景细节（多问问未来可能存在的业务需求-有助于考虑逻辑扩展性和全面性）；
然后根据调研考虑3套方案：

不动系统组织架构、功能权限、数据权限的基础上，对各个功能模块考虑解决方案（即如何解决系统现在存在的问题？），然后列出优缺点。
重做系统组织架构、功能权限、数据权限的基础上，对各个功能模块考虑解决方案（即如何解决系统现在存在的问题？），然后列出优缺点。（基本上动这个可以考虑重新设计了）
考虑重新设计的方案：从组织架构、功能权限、数据权限、业务流程、各个功能模块等全方位考虑，以及特殊事件处理方案。（列出优缺点）

大体方案方向出来后找研发和项目评估下大概的难度和工期，不用估计太准，只要个大概就行。然后评估下现在的时间、资源等是否允许？ROI是否值得？