TOB产品经理的系统思维，这3个要点要注意

　　系统思维是TOB产品经理必备的思维之一，利用好系统思维为客户提供有价值的服务，需要注意流程、系统和效率三个要点。
　　刘润老师的一念之间
　　前阵子刘润老师写了一篇文章，吐槽改签火车票流程太麻（sha）烦（bi），主题表达的是我们都活在产品经理的一念之间。其实我理解刘润老师讲述的“一念之间”是指产品经理在深思熟虑后那一刻做的决定影响面大。但其实言者无心，听者有意，大部分的第一反应一定是：对！产品经理啥都不会，只会拍脑袋想需求，做出来的产品都很欠（打）思考。
　　首先，我要解释一下，刘润老师不是那个意思。当然，就算是拍脑袋，你们打我啊
　　其次，刘润老师讲述的是一个面向铁路乘客的改签流程待优化问题，而这种流程化其实就是用户服务过程，如果流程没有在产品中设计好，一方面苦的是用户，要折腾来折腾去，还浪费了时间耽误了行程；另一方面苦的也是车站窗口的小姐姐们（车站大哥表示不服）：本来是想让乘客在APP上做操作，减少窗口服务压力，结果：又来了老弟儿。也就是说，互联网带给订票服务的提效，还不到位呢。
　　产品经理需要系统思维
　　好了，终于要强行引出题目中的关键词：系统思维。私以为，铁路乘客的改签流程恰恰是没有系统化思考产品的结果。
　　先来讲讲什么是系统思维，定义如下：把认识对象作为系统，从系统和要素、要素和要素、系统和环境的相互联系、相互作用中综合地考察认识对象的一种思维方法。
　　对TOB来说，客户花钱购买的是一个服务，而无论是产品功能也好，后台系统也好，都只是整个服务中的一个环节。如果将服务理解为一个系统，那么其中每个流程都是其中要素，产品经理需要对服务中各要素及联系有更全面的解析，才能更好地给客户带来价值。
　　我讲个之前工作中的小故事：
　　很久很久以前啊，我们做的B端产品还在从0到1阶段，大家的精力都花费在功能迭代。有一天，老板下了个order：“把后台的交互改一改，让整体交互更清晰点”。
　　我当时第一反应是：whatyourproblem？公司现在是需要赶紧让客户满意我们的功能，从而扩大客户规模。况且B端产品也不需要太注重交互吧？这有点本末倒置了！所以，我态度坚定，毅然决然地跟老板说：“好的，么问题，这个意见很棒呢！”
　　后来我深入业务，发现由于后台交互不清晰，运营同学经常要跟客户做解释。一方面导致运营工作效率低下，长期陷入培训的琐事中；另一方面也极大降低了客户体验，甚至因为不会用就不用了。而站在老板层面上，运营成本花在这些ROI很低的事情上面，明显是亏本生意。所以我突然就明白老板的意图了，一句话：钱得花在刀刃上！
　　当我们提供一个服务时，如果交互不清晰（不用好看），客户在使用上需要投入更多时间，必然会影响其满意度；若乙方通过人力协助，则提升了自己的运营成本。这个就是整个系统化服务中每个环节的相互影响结果。（P。S。后续我们通过改善交互、增加帮助说明、操作指引等方式，让客户愉快地享受我们的服务）
　　TOB产品经理用好系统思维
　　那么，TOB产品经理该如何利用系统思维为客户提供有价值的服务呢？七爷认为有三个重要的点，且听我娓娓道来
　　1。了解服务流程
　　企业服务顾名思义，先有企业，再有服务。所以这个点的核心在于：去了解企业，了解客户！（心里默念三遍）。
　　TOC产品经理往往研究的是群体特征，满足一群人的通用需求；TOB产品经理研究的是一个个客户的需求，每个客户需求又往往不同，比如大客户有更多定制化需求，小客户只需要基本需求（俗称大B和小B）。
　　那么如何确定大客户哪些需求具有可延展性（适用于小客户），小客户需求是否具备通用性，这时候就需要产品经理深入了解实际业务流程，沟通每个需求的问题背景，以解决客户核心问题，带来真正的价值。
　　B端产品经理做业务调研的方式有很多，比如用户访谈、轮岗实习、调研问卷等，但万变不离其宗，绝不能闭门造车。注意，任何服务都可以用人工运营的方式实现，之所以要优化，其实就是效率问题。
　　那么产品经理在调研业务过程，不能只是管中窥豹，而要有更宽的视野，自顶向下去了解全局业务，否则就可能只解决了订票问题，但忽略了改签问题
　　2。定义系统能力
　　梁宁曾经讲过系统能力的case：一台ATM机。她提到一个简单ATM若要提供完整的系统能力需要七个岗位：战略、运营、现金、密码、硬件、客服、技术。同样的，当产品经理提供一项系统化服务时，需要定义好各环节的能力，否则整个系统就会乱套。
　　当然，不同服务所需要的系统能力不尽相同，比如刚才讲到的ATM，需要现金；而如果是电商服务，需要供应链数据。在这个过程中，可以利用结构化思维，根据业务的上下游或者流程步骤，定义整个服务所需要的能力。
　　当然，战略、运营、技术甚至是客服，都属于B端服务的基本能力。比如客户对后台有疑惑，就需要客服同学去解决；后台系统出现故障，就需要技术同学及时处理以保持稳定；每个功能的价值传递，需要运营同学做数据分析及价值评估。
　　对此，有些产品同学可能认为这是公司层面的考虑，而我只负责需求产出和功能稳定即可了。对于这种观点，先不说高级产品与初级产品的思考层次。咱作为一个产品经理，最爽的快感是产品解决了客户问题，带去了价值。而客户的视角往往是认可了购买的服务，而不是其中某个功能。
　　如果产品经理只顾着自己的一亩三分地，不去care其他资源调配，最后服务出问题了，其实。锅还是产品经理的，哈哈哈哈哈哈
　　3。系统能力效率最大化
　　产品经理利用系统思维定义好服务后，要考虑各系统能力的相互影响，从而协调好资源。就如同系统思维的定义，每个环节的能力都是生生相克的。
　　如果产品经理定义了一个天马行空的交互，那么客户在使用过程中就会有诸多疑惑，导致使用成本指数上升，也在无形中决定了客服需要花费更多时间去做培训。
　　如果产品经理定义了一个硬件有问题的ATM，并且也不协调资源解决根因，任其随处爆bug，那么技术人员、客服人员都会陷入解决bug、解释bug的漩涡中无法自拔。
　　如果产品经理定义了一个杂乱无章的数据统计，当运营需要数据来传递服务价值时，就得花大量时间整理数据，甚至协调资源单独跑数据，一方面延误了价值传递的及时性，客户无法感受服务价值，另一方面也导致运营、技术在各种琐事上折腾，影响工作效率。
　　可以看到，每个系统能力如果定义有缺漏，整体服务质量会受到蝴蝶效应般地影响，不只是降低了服务提供者的ROI，更甚地是，客户认为没啥卵用。所以回到前面所说，产品经理提供的服务，绝不仅仅是一个后台、一个工具那么简单，还包括了各环节人力的投入。如何让每个系统能力的效率得到最大化，是利用系统思维解决客户问题关键的一步。