专家团｜宋星：不被边缘化！数据部门如何与业务部门共舞

数据（技术）部门在和业务部门配合的时候，经常有种价值无法发挥的感觉，做了很多事，但总觉得差点意思，甚至工作成果有点可有可无的感觉，存在感极弱。

你是否有碰到过以下类似的情况？

数据部门经常会遇到哪些与业务部门的“矛盾”？

1.业务部门觉得只要有工具和技术，就能把想要的数据都拿到，但是忽略了数据的获取需要有一套符合业务需求的数据标准，只觉得获取数据是数据部门要做的事，但是忽略了要获取符合业务需求的数据也需要业务部门参与数据标准的制定。

2.数据（技术）部门按照业务部门提的需求开发好供业务使用的工具，但最终由于工具难用、提供的数据不符合业务的需求，最终不了了之。

3.业务部门的需求常常会随着市场和业务环境的变化而变化，而数据部门需要时间和资源来满足这些变化的需求，当业务部门的需求变化快于数据部门的响应能力时，就容易产生分歧。

4.数据部门提供泛泛而谈的洞察，当业务部门需要特定的洞察或数据支持时，数据部门可能只能提供一些浅层次的洞察，而无法提供具体、针对性的分析结果。

......

你还遇到过哪些“矛盾”？请到评论区讨论。

如何解决“矛盾”

1.一定要厘清协作职责

数据部门相关的分工、职责不清晰或不合理，是导致数据部门“被边缘化”的最主要原因。

业务部门经常认为只要有数据部门在，就可以轻松拿到想要的数据，但是经常找数据部门拿数的时候，要么缺数，要么数据不符合应用要求。

从拿到数据到应用数据，每个环节都有很多细节工作需要处理，比如数据监测的标准建立，基于哪些业务目标来建立？有了数据后如何建立标签体系，谁来制定这个标准？下一次做活动的时候在这些标准上是否有需要调整的地方？要怎么调整是符合业务需求的？等等。

上面的这些问题，有些是数据部门的职责，例如标准建立，有一些并不是数据部门的职责或者至少不全部是数据部门的职责，例如标签体系的建立。

数据如何获取，从本质上讲，也不是数据部门的职责。但数据被获取到之后的技术支持与管理工具，确实是要数据部门提供的。

另一方面，业务部门会认为，数据部门只想做容易出成绩的工作，甚至会认为，数据部门是不是准备“越俎代庖”，抢我饭碗？

数据部门更愿意接块状项目，而不是点状需求，比如取一些数、做个报表，但业务部门又需要这样的数据支持工作。

能理解数据同事更愿意接项目的想法，做项目是大家更容易出成果的工作，结束了也更有利于各自的工作汇报。而且数据部门也会觉得当你提出的是项目的时候，说明你已经有较多的考虑，后续推进工作的可控性也会强一些。

但即便如此，数据同事依然需要加强业务知识来进一步理解项目，确保可控性，甚至能站在更专业的角度给予业务部门建议或解决方案。

另一个比较突出的问题是，数据部门为了更好地做好项目，往往不可避免地要深入到业务部门的工作范畴里，但此时业务部门会比较紧张，无论是担心对方越界，还是具体业务的沟通上，都存在内心的障碍。

所以，数据部门与业务部门的分工，一定要明确。

2.数据部门也要掌握商业逻辑

不理解业务运行的商业逻辑，造成沟通成本高，是数据部门容易被“challenge”的另一个原因。

两个部门的紧密合作尤为重要，然而数据部门经常面临的一个挑战是，他们在处理数据时专注于技术和统计分析，容易忽视了业务的商业逻辑。他们可能能够提供大量的数据和指标，却缺乏对这些数据如何与业务目标和市场环境相联系的理解。这导致他们在与业务部门沟通时无法有效传递信息，也无法提供具体的解决方案。

这并不能说明数据部门同事不配合工作，也不是说业务部门同事不愿意沟通，而是业务同事每次要解释清楚业务逻辑要从很基础的地方讲起时，沟通成本直线上升，久而久之大家都进入疲惫状态。

解决这一问题的关键是数据部门需要往前走一步，先把业务的基础商业逻辑学习和掌握，甚至比业务更专业，前段时间和一个做技术的朋友聊，他们的老大就是要求他们要比业务更懂业务，虽然有点难度，但是这个思路是对的，只有这样才有机会快速进入业务同事的沟通语境。

比如业务上来就和你说“诱饵触点规则模型”，要基于什么规则来设置触点和诱饵，你可能会觉得为啥不能说人话啊？因为说人话效率低啊，说人话要讲背景、讲上下文，但是如果双方都了解这个模型的话，就可以不用交代那么多上下文了，一说到这个模型就知道是要给一些用户做一个运营策略了。

3.强化业务领域的专业知识

与业务商业逻辑相匹配的专业知识不足，导致沟通不下去，这种情况也时常发生。

经常会碰到业务和你说拿回来这么多数据，把数据都打通一下啊。然后你去寻求各种技术手段去打通，发现根本打通不了，各个数据间并没有中间键，也没办法通过技术手段去获取中间键，然后事情不了了之。

这个需求在技术侧本来就没有办法，需要业务的同事配合通过运营手段获取比如手机号这样的ID，或者像利用会员通这样的功能，但前提也是需要业务同事的运营配合才有可能实现。那么这个配合点如果数据部门无法提出，可能这个事情就卡在这里了。

还有一点是，部门上下对同一需求所掌握的专业知识也不尽相同，很多时候双方老板都理解需求，但由于下面的同事在专业知识上并没有很全面的掌握，以至于在实际执行的时候并不能很好地反应当时的需求。

所以，《数据驱动的以消费者为核心的营销数字化转型：方法与案例》的全部内容，既是讲数据在数字营销和消费者运营上的商业逻辑，也是系统性介绍与数据相关的业务领域的专业知识的。仍然强烈推荐给数据部门的同事。

4.工作职能的可替代性：做了这个功能，那我是不是要下岗了

是不是很多朋友有这个顾虑？尤其是一些提升工作效率的功能，这些提效功能一上，那我干啥呢？

如果你的工作如此容易被替代，那你更要考虑需要理解业务，站在自己专业的角度给予走在业务前面的应用意见，很多时候数据部门提出来的建议不被采纳，业务部门看不上，不是因为提的建议不好，只是在当下业务部门有限的条件下无法在这个阶段应用。

我们见过几个这块做的好的企业，数据部门只做赋能的工作，把业务部门需要的数据能力工具化、功能化，并且主动探索数据和技术在业务上的应用场景，然后推进和业务的小规模测试应用，再将成功的应用进行更大范围的推广，但数据部门只到此为止，将能力转化成工具、功能或流程化，然后进行新的业务应用的探索。

数据和技术的发展一直在持续推进，因此，担心自己数据相关的工作被机器或者技术取代实在是多虑了。业务部门实际上更可能有类似的担忧，但本质上，大家面临的境况并无太大差异。

持续的学习精进变得尤为重要，因为技术、工具和系统的发展，需要更好地被人驾驭，而不是取代人。人需要有更好的技能，需要持续学习。这是数据部门不被边缘化的立身之本。