时间: 2021-08-03 08:25:49 人气: 19 评论: 0
编辑导语：当我们在从事某一职位时，我们是否能真切地认识到该职位所做的事情的价值与意义？对于运营中后台的朋友们，其中的产品业务及其运营价值，该如何衡量？作者分享了自己对于该话题的看法，我们一起来看看吧。
当你从事服务公司内部爸爸的中后台产品，服务内部运营职能的运营产品，服务企业进行经营生产的企业服务产品或系统工作时，经常有这样的困惑，我产品价值如何衡量？
管理者常用前端产品的思路和规划要求中后台产品。产品觉得运营笨，运营觉得业务太傻，业务和运营共同指责产品慢…….最后大家一起变成“笨傻慢”。后续，小珠**写文分析“产运研协同“。
要么硬套C端产品的思维，直接上商业指标，要不贴上粘性和拉新，要不弱化为及时上线了多少功能，被业务追赶着跑, 中后台产品沦为业务的附庸，当部署能力差时，又经常落后业务一步。这就是中后台产品定位和价值的尴尬现状。
以往，我的文章更多的聚焦高视角体系架构，今天我们从高视角到实操谈谈作为中后台产品价值定位，产品负责人如何在中后台产品上凸显产品价值，产品从业者如何不必硬凹你的功能效和迭代kpi。
曾经有人问我，小珠，拿CRM讲，你做的究竟是营销系统，是b端产品， 还是企业产品？抑或是中后台产品？在此一并澄清。
CRM是帮助企业进行客户全生命周期的转化的，这属于营销业务的范畴，也经常服务于市场和销售及其他类销售职能，所以它属于营销体系当家大系统。
同时CRM、ERP、客服等系统往往服务于企业经营生产，由企业内部人员完成企业目标，所以，属于2b系统。
在这说明的是，起家与链接b端和c端的互联网平台业务中，很多公司把b端的App, 中后台都叫2b产品团队和职能，而实际上脱离平台模式更广阔的视角是企业服务系统，一般的b端对应企业都比较小规模，只是隶属于企业服务系统内涵的一类别。
而这些客户直接交互的端系统，app不同，属于交互端层面的第二层，或者第三层，故称为中后台系统。
有些本身产品服务属于2c业务，使用渠道来进行销售时，业务要管理的是渠道的开发、赋能、合作、激励所以这种业务有属于2b的思路和范畴，所以站在哪里，就什么范畴说什么？视角非常重要。
角色定位：中后台产品，和运营和业务的关系一定是跟随，协同，推动，主导业务规则，业务优化以及由规则制定和优化演化而来的产品需求。
明确的说，高段位中后台产品是可以主导业务规则制定及优化的，而且必须有能力主导。在产品价值上，大多数情况，如果不推动业务优化，单单上线功能是无法带来业务价值的。新系统的架构也往往伴随业务体系的兴起和大范围变革。
所以，不要犹豫是不是该主导！
重点是能不能主导，当产品在一定程度上说，一定不如业务懂得业务，但是当做完充分的业务分析及公司中远期战略理解后，一定可以将业务结构化，归属其业务范畴，前瞻其业务发展，整体构架产品体系及其缺失的业务管理范畴，回归本质来推动和主导业务优化。
产品的优势为结构化，系统化，整体性思维方式，更有在其他相似范畴产品建设中积累的业务经营和智慧，也就是回归本质了解业务和产品。
做到这点的中后台产品比较少。但在一定意义上说，产品可以做到比业务还要懂业务，这样给高阶中后台产品晋级指明了方向。
产品负责人能带运营，产品经理能做运营分析，一个高级咨询顾问，能快速的给一个企业做优化方案都是基于这些能力。
如我们把业务的营销模式能理解到大b的特点，那么你一定可以从客户主体形态，销售周期，销售协同模式，业务管控特点推断出需要的产品架构和未来需求。
产品团队能力成长维度，要经历跟随，协同，推动，主导。当我们刚刚入驻一家企业，即使你具有主导的能力，可能也要先采用跟随策略，完成业务详细分析和主动型架构后转为协同，推动乃至主导。
这里面还有渗透管理层及合作伙伴的功夫要做。改变“傻笨慢”到”高效协同“。
CRM等中后台产品建设，往往被称为CEO工程，在资源及项目组织不同的互联网企业，往往讲系统做的碎乱是因为互联网快速迭代和小项目的运行分不开的，在系统性强，规划性强的中后台产品建设上并不匹配，所以在中台真正建立起来，系统往往追求单点突破。
中后台产品的用户往往是企业内部的市场，销售，客服，电销，运营人员，这些人及其管理者对优化的认同，主导，以及上线后使用，及运营闭环的实施，是发挥系统真正价值不可或缺的因素。
产品可以主导，绝不是在大环节上的闭门造车，更聪明的做法，提供框架，推动业务孵化，关键节点，可以引导决策，尽量让业务以主人翁的姿态参与，否则，即使功能上线，数据可能不可靠，业务还是**衍生出线下的功能和小表格。
产品可以主导，甚至符合在线角色，和自动触达的业务模式，孵化a/b测试，甚至自身孵化新的营销链路。要在对于我充分理解和测试资源闭环的情况下。
数字化时代，CRM都可以由SCRM部分逐步跻身上流社**，直接和客户交互而提炼直接业务价值。
产品不必拘泥，但不可从跟随的现状整体跳到另一个极端，特别没有做到比业务还懂业务的情况下。主导点可以孵化单点的形势进行，来提升产品价值。
综合来看，中后台产品不断进行业务理解，提升业务结构化，在线化，逐步实现数字化，并孵化单点的智能化，有序进行。
姿势正确，知识足够！
当你具体提炼中后台产品业务价值时，可以从指标及价值的类型维度，及你产品和这个价值的关系维度2个方面进行抽象和思考。
第一，你的产品所服务的业务职能其自身所承担的业务指标，如销售，销售承担的人效、转化率，稍微细分的下一层比如业务本身管控的w通时、通次，客服的满意率，回答问题率，电销的有效线索数据，可宏观可中观。你的工具帮他作业，他的作业指标你一定要清楚，一定意义上一定和你的系统价值相关。
第二，直接在你的系统上反映的作业量，比如电话拨出量，通时通次、访问等。1和2有时候有部分重合，不必困惑，这个分类是让你系统的理解指标，指标2序列往往是1的下辖动作，比如客户的首单转化一般是有多次通话带来的。
第三，类似埋点思维，去分析系统的使用频率，人数，人次等数据和指标。
第四，系统带来的作业效率的提升，比如审批流程加快50%，某操作提升速度，作业准确率等。
第五，数据透明的价值，原来不清楚的现在清楚了，原来盲打，盲捞线索使得业务的的管理，决策，执行效果更好。（5维度往往和1，2交叉）
就是明确A维度的情况下思考，这些指标和你系统的关联关系。直接由系统及其优化带来的，还是明确正相关，还是只提供了透明的，还是不明确关系？
比如3、4一定是直接强关联，1、2关联性依赖系统和业务成熟度，系统成熟时完全可以和业务指标强相关的。
2个维度**清楚了，你就不必硬凹指标，不必不自信，也**给系统的各层级优化明确方向。
特别是1，没有形成2个维度的思考前经常困惑，不敢想，好像业务指标和我关系不大，但是不提又觉得系统没价值。
其实一定要整理清楚，要明确你所服务的业务及在你系统的作业人员自己承担什么样的业务指标，服务好他们就是你的目的，系统建设无论成熟与否，都要心中有规划，往上走，但是清楚你的目标是什么。
很薄弱的时候，我们就是先达到3和4，同时通过系统的数据功能不断证明系统和业务人员某些作业行为与结果的关系。
如果是企业服务软件或者平台，是一样的道理，明确你的B端客户要用你的系统取得什么样的成功，这就是所谓的客户成功学。
指标样例：
一个处于初级阶段的系统指标体系规划，明确业务在进行的优化，同步产品规划，提炼产品指标。
本文由 @小珠CRM 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
