ToB的产品现在最流行的方式是高度活络、自在可配备

ToB 的全称是“To Business”，即面向企业。企业往往具有比较复杂的业务，且个性化，一般需求他们自掏腰包来处理自己的困难。这就会要求所购买的产品有必要能够满足自己的悉数需求，产品价格要跟产品价值（满足需求）相匹配。当 B 端客户需求你的某个功用时，你能够编林林总总的理由来搪塞他或许说正在开发中，但不能够说你没有，否则会给人一种很不专业的感觉（侧面反映产品不成熟、堆集事例少、不能快速响应信息化建造。所以关于大部分 ToB 产品，不存在直接拿 MVP 去卖的情况。因为客户需求你能给出对某一项业务完整的处理计划（思路），哪怕是低保真产品原型或 PPT ，都比一个没做好的 MVP 更具说服力。

问题：定制化越多、功用越繁雍笨重

ToB的产品现在最流行的方式是高度活络、自在可配备；公司规划研宣布一套所谓能够包括工作80%标准化的系统流程，在用户购买之后采用根据客户不同需求做配备，满足用户需求。这是一个抱负状态，实际中，每个企业、校园、组织的实践业务不同，使用者关心的业务和流程不尽相同，就出现许多的需求无法通过配备满足的实际需求情况。由此定制化开发的方式就被各厂商放到了桌面。

定制化开发过程中会有新的流程、功用被发掘，这些确实能处理实际工作中的出现的一些个性化、特殊化的实践问题；可是假如不加辨别，认为只要能够处理工作问题的计划就应该归入系统，进而考虑把每个客户需求进行整合，补偿现有系统的缺少，规划研宣布“大而全”的系统，关于想做平台或许垄断工作赢利的厂商，具有巨大的诱惑力。

这样一来，定制化越多，整合融入的系统、功用越多、系统也越来繁雍笨重；形成系统万能，却又没有什么卖点，对内公司人员怨声载道，对外给人系统拼拼凑凑的形象，在市场没有什么竞争力，什么都有，什么都不强，又冗余难用；虽然支付这么大的代价，事实上这样的系统仍然无法掩盖用户所有需求，因为你永久不知道下一个客户需求什么？

二、系统臃肿问题实质与避免建议

系统臃肿问题实质：

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

处理问题建议：

先整理下现在的公司业务流程和组织架构（找公司各部门担任人多问问）；

根据上面四点对系统现在的业务流程、组织架构、功用模块、功用点进行整理，找出存在问题的当地，别离列出问题表单和问题点；

拿着问题表单和问题点去调研各个部门的担任人和使用者，看看反馈结果；并趁便调研现在的业务需求和流程场景细节（多问问未来或许存在的业务需求-有助于考虑逻辑扩展性和全面性）；