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

　　系统思维是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，更甚地是，客户认为没啥卵用。所以回到前面所说，产品经理提供的服务，绝不仅仅是一个后台、一个工具那么简单，还包括了各环节人力的投入。如何让每个系统能力的效率得到最大化，是利用系统思维解决客户问题关键的一步。