导读：针对于主数据类的B端产品上线后，面临着迫切需要开展的运营推广工作，除了产品经理，运营推广还会涉及产品运营人员和业务运营人员。而且，主数据平台产品经理、产品运营人员、业务运营人员三者的工作职责往往有很多交叉和重叠，这就可能导致冲突，影响工作效率。我们需要深刻理解三者的工作目标、工作方式，处理好协作关系，这样才能保证工作顺利开展。
一、理解主数据产品的运营管理职责
目前主数据类的产品运营岗位在行业内没有公认的定位或定义，但是既然是产品运营，肯定要围绕产品展开，而不是仅仅做纯粹的业务管理工作。
但是作为主数据类的产品运营又和C端的产品运营大相径庭，所以我们在理解管理职责上需要尽可能的避免陷入C端产品运营工作的泥潭中，导致资源浪费且得不到运营的效果。这里说明一下与常见C端产品运营的差别：
- **工作目标不同：**主数据平台产品运营是需要通过充分挖掘产品能力，帮助业务线提升管理效能、改善核心指标，最终实现数据拉通。如何让目标客户用的爽，实现业务价值是运营的首要任务；但是C端产品运营核心更多是关注转化率，常常包括用户量、点击量、活跃度、转化率和收入等。
- **技能要求不同：**主数据产品的运营人员要掌握相关业务领域的专业知识，例如房地产开发全周期、货值管理、资金计划、财务核算等业务知识，以及数据分析、文案编写等辅助技能；C端产品运营人员要具备创造性思维，掌握热点时事和各种新媒体运作方式，并进行文案编写。
- 目标客户不同： 主数据产品的运营管理对象相对复杂，主要有三类：数据生产者 （关注质量、及时性）数据联通者 （关注取数口径、业务场景）数据使用者（关注内部指标开发实现、以及概况展示）。
总之，针对于主数据产品，我想产品运营工作会更加务实一些，同时他们是需要和产品经理保持持续的沟通配合协作的。具体的工作职责包括且不仅限于如下：
产品培训推广、问题答疑处理、需求采集过滤、项目效果价值分析、业务诊断监控。
二、主数据产品经理、产品运营与业务运营三者之间的高效协作
由于主数据属于公共类的系统建设，实际上对于业务所属方的概念非常模糊，一般情况下，大多是由集团中心办公室进行作为业务方。
那么，关于产品经理、产品运营与业务运营三者之间形成的组织决定了后续是否能够持续产生价值的关键因素。
合理的组织架构可以正向地引导组织和业务朝好的方向发展，不合理的组织架构会造成各种问题。组织架构需要根据业务发展情况随时调整变化，没有最好的组织架构，只有最适应当前阶段的组织架构。通过调整组织架构，绑定利益共同体，可以解决很多业务管理问题。
目前针对这三者的关系主流有以下三种方案：
1，产品 运营隶属于业务部门，与业务运营进行融合优势是能充分贴近业务场景，不至于双方"鸡同鸭讲"。但是主数据平台在刚才讲到，是属于公共类性质的产品，很难去找到一个确定的业务中心进行融合。例如主数据平台的录入部门如果绝大部分在运营部门，那么录入审核的运营工作放在运营部门就显得更为高效一些。
2，产品 运营单独形成一个部门，这个方案避免了多头领导的汇报，但问题是这种方式会有资源浪费的风险，且与产品经理、业务运营又失去了较强的关联性。如果该企业是属于多元化集团，且涉及的行业较多，涉及的主数据管理项较多（项目域、人力域、财务域、供应商等等）那么作为集中管控的方式，单独成立一个产品运营的部门，结合技术与业务相应人员，是很有必要的。但是一般情况，都是多个角色，身兼多职的情况。
3，产品运营隶属于产品线，产品运营人员直接向产品经理汇报，不仅是岗位管理关系的调整，也代表着将产品相关的工作全盘授权给产品经理来管理、安排、控制。从功能方案的设计、实施，到意见反馈、效果分析、持续优化，一套完整的产品方案都由产品经理操盘管理，让一名优秀的产品经理能够尽情发挥才能。但是问题也存在，例如产品经理一言堂的情况，缺乏牵制力。
目前很多比较成熟的主数据产品，例如SAP的主数据管理平台（MDG）由于涉及到一些编码操作，而且系统界面也比较专业，大部分都由IT部门的专业人员进行运营运维。从技术手段上来说最为高效，但是由于IT技术人员缺乏业务知识，所以业务部门也要进行相应的帮扶答疑。
当然，任何组织架构都应该是在调整实践中进行确认的，互联网公司取得成功的诀窍之一就是，频繁地调整组织结构，尝试各种安排，在各种调整中很可能实现破局，或者产生"鲶鱼效应"。