上上周末参加了『互联网早读课』举办的活动，主要是冲着爱屋及屋的吴斌讲的『内部系统产品观』去的。行业内传播广泛的文章大多数是C端产品，比如人人都是产品经理网站上，某某界面交互如何如何，如何易用。B端产品怎么做？几乎很少听到相关的，所以就根据他的演讲内容和自己的经验做了以下总结。

一个内部系统如果想要发挥最大的价值，人、系统、流程三个都是很重要的因素，三者缺一不可。

1. 人

1.1 需求沟通

产品经理首先要跟业务负责人或一线人员沟通需求，有些业务要涉及多个部门，多个人员要处理。每个部门的需求方会优先考虑自己部门的需求而忽视业务的上下游部门，而且他们大部分没有整理需求的能力，产品经理可能对业务没有全局的概念，他毕竟不是一线人员，很难接触到所有的业务细节。

如果需求方有一个对业务高度理解的人（中高层人员）对接，沟通效率也高，系统上线后的执行也会有保证；如果跟需求方多个人员对接，在系统还没正式开发前，一定要多个利益部门反复确认需求，保证大家目标一致。这个阶段没弄好，系统上线后可能有以下后果：

• 业务部门没人用，不是他们想要的，最悲剧的结果，浪费资源浪费时间。再过段时间产品经理很可能就要离职了。
• 业务部门觉得不好用，增加了业务部门的工作量，虽然能用，但还不如邮件+Excel来得高效，目标和预期在需求阶段没有沟通好。
• 业务部门不配合使用，现在很多O2O公司会招大量地推人员，人员素质良莠不齐，出现部分网点不配合使用也是非常正常的。吴斌举了个案例：新系统在表现最好的门店A和表现最差的门店B分别试用，结果门店B拒绝使用新系统，各种借口。但门店A在新系统的帮助下业务进展有显著提升，最后门店B被迫使用。

1.2 开发资源

内部系统的目的就是协助业务人员更快地完成工作，它的目标就是效率，效率，效率。相比C端产品，对UI界面、交互要求都低很多，一般都希望系统尽快开发完成，尽快投入使用。但用户体验低，业务人员的数据录入的积极性低，操作效率也会降低。产品经理需要衡量这个平衡点，尽可能地用少的开发资源去保证用户体验。

吴斌提到产品经理应尽可能地少打扰开发，如果开发在写代码的过程中你打断他5分钟，他这个半小时就废了，他需要花几十分钟时间才能把此前脑子里存储的东西找回来。

1.3 管理层

内部系统的开发使用一定要有中高层管理人员的支持。短期内研发资源还可以从C端产品挤一挤，但长期来看，内部系统的研发工作量绝对不会比C端产品低。另外内部系统在公司内推广使用，或多或少会产生一些阻力和问题，有老大的支持，哪怕刚上线的系统很挫，后续也是可以慢慢好起来的。

2. 流程

2.1 聚焦核心

需求边界尽可能地小，一个刚准备上内部系统公司，大部分都是中小型公司，公司流程甚至商业模式可能在几个月就会发生调整，如果需求边界过大，很可能在开发到一半的时候，需求就会有重大调整。

2.2 跳出流程

系统尽量不要根据流程来设计，流程可能随时会发生变更，根据流程来做内部系统，这系统后面要不就是大改（这个坑我跳过），要不就弃之不用。总之，越简单越好，无论是后续新增需求还是变更，都会保留较大的余地，系统也不用动大手术。

2.3 执行

流程和运营应根据系统做相应的调整，没有相应的流程和运营，系统的输入输出数据就无法结构化。如果专门有人盯着，能够避免一些不必要的业务风险及大量的脏数据，也能强化根据系统产生的流程及运营规范。

3. 系统

3.1 实施

自主开发还是寻找外部方案？互联网公司的内部系统大部分都是自主研发的，为什么？内部系统是公司核心竞争力相关的，岂能借他人之手，假如美团的CRM系统采购SAP，其它公司直接花钱买SAP的就是了，IT系统都一样，如何跟别人拉开差距呢？最后只能拼谁人多，谁钱多。公司核心系统的相关信息也可能被系统提供商泄露给竞争对手。

为了协助内部人员使用内部系统，相应的反馈系统、帮助系统、公告系统、运营工具都应考虑到。

3.2 终端

App、Web定位一定要区分开。内部系统的App侧重数据的输入，便于地推人员随时输入信息及时反馈业务进展。Web端侧重数据的流转及展示，帮助决策分析。

内部系统使用App有一个很大的弊端就是适配成本太高了。爱屋及屋的解决方法是统一所有人都使用小米手机，这个内部阻力还是挺大的，尤其是有人买了联通等套餐手机。统一机型的好处就是降低开发工作量，加快内部系统的版本迭代节奏。当然如果App端承载信息和交互不是很重的话，放在微信企业号里做也是可以，升级适配的成本都很低。

3.3 数据

系统每天都会查看大量的数据，要保证历史的数据无论什么时候查看都是一样的，且不能轻易修改，否则数据报表的意义就彻底丧失了。另外为了防止信息泄露，相应的权限必须跟上。在房地产行业，谁能独家掌握房地产信息谁就领先了，爱屋及屋是以手机号码作为帐号，每次登录需短信验证。

图片来自Vennli官网