宋星的数字观
数据（技术）部门在和业务部门配合的时候，经常有种价值无法发挥的感觉，做了很多事，但总觉得差点意思，甚至工作成果有点可有可无的感觉，存在感极弱。
你是否有碰到过以下类似的情况？
01 数据部门经常会遇到哪些与业务部门的“矛盾”？
3.业务部门的需求常常会随着市场和业务环境的变化而变化，而数据部门需要时间和资源来满足这些变化的需求，当业务部门的需求变化快于数据部门的响应能力时，就容易产生分歧。
4.数据部门提供泛泛而谈的洞察，当业务部门需要特定的洞察或数据支持时，数据部门可能只能提供一些浅层次的洞察，而无法提供具体、针对性的分析结果。
……
你还遇到过哪些“矛盾”？请到评论区讨论。
02 如何解决“矛盾”
上面的这些问题，有些是数据部门的职责，例如标准建立，有一些并不是数据部门的职责或者至少不全部是数据部门的职责，例如标签体系的建立。
数据如何获取，从本质上讲，也不是数据部门的职责。但数据被获取到之后的技术支持与管理工具，确实是要数据部门提供的。
另一方面，业务部门会认为，数据部门只想做容易出成绩的工作，甚至会认为，数据部门是不是准备“越俎代庖”，抢我饭碗？
数据部门更愿意接块状项目，而不是点状需求，比如取一些数、做个报表，但业务部门又需要这样的数据支持工作。
能理解数据同事更愿意接项目的想法，做项目是大家更容易出成果的工作，结束了也更有利于各自的工作汇报。而且数据部门也会觉得当你提出的是项目的时候，说明你已经有较多的考虑，后续推进工作的可控性也会强一些。
但即便如此，数据同事依然需要加强业务知识来进一步理解项目，确保可控性，甚至能站在更专业的角度给予业务部门建议或解决方案。
另一个比较突出的问题是，数据部门为了更好地做好项目，往往不可避免地要深入到业务部门的工作范畴里，但此时业务部门会比较紧张，无论是担心对方越界，还是具体业务的沟通上，都存在内心的障碍。
所以，数据部门与业务部门的分工，一定要明确。
在“宋星大课堂”《数据驱动的以消费者为核心的营销数字化转型：方法与案例》中，有详细介绍数据业务的三层体系，以及各体系对应的分工与职责。这部分内容，对于数据部门如何定义自己，以及对业务部门如何理解数据部门与数据工作，都有重大的价值。
这并不能说明数据部门同事不配合工作，也不是说业务部门同事不愿意沟通，而是业务同事每次要解释清楚业务逻辑要从很基础的地方讲起时，沟通成本直线上升，久而久之大家都进入疲惫状态。
解决这一问题的关键是数据部门需要往前走一步，先把业务的基础商业逻辑学习和掌握，甚至比业务更专业，前段时间和一个做技术的朋友聊，他们的老大就是要求他们要比业务更懂业务，虽然有点难度，但是这个思路是对的，只有这样才有机会快速进入业务同事的沟通语境。
比如业务上来就和你说“诱饵触点规则模型”，要基于什么规则来设置触点和诱饵，你可能会觉得为啥不能说人话啊？因为说人话效率低啊，说人话要讲背景、讲上下文，但是如果双方都了解这个模型的话，就可以不用交代那么多上下文了，一说到这个模型就知道是要给一些用户做一个运营策略了。
这个需求在技术侧本来就没有办法，需要业务的同事配合通过运营手段获取比如手机号这样的ID，或者像利用会员通这样的功能，但前提也是需要业务同事的运营配合才有可能实现。那么这个配合点如果数据部门无法提出，可能这个事情就卡在这里了。
还有一点是，部门上下对同一需求所掌握的专业知识也不尽相同，很多时候双方老板都理解需求，但由于下面的同事在专业知识上并没有很全面的掌握，以至于在实际执行的时候并不能很好地反应当时的需求。
所以，《数据驱动的以消费者为核心的营销数字化转型：方法与案例》的全部内容，既是讲数据在数字营销和消费者运营上的商业逻辑，也是系统性介绍与数据相关的业务领域的专业知识的。仍然强烈推荐给数据部门的同事。
我们见过几个这块做的好的企业，数据部门只做赋能的工作，把业务部门需要的数据能力工具化、功能化，并且主动探索数据和技术在业务上的应用场景，然后推进和业务的小规模测试应用，再将成功的应用进行更大范围的推广，但数据部门只到此为止，将能力转化成工具、功能或流程化，然后进行新的业务应用的探索。
数据和技术的发展一直在持续推进，因此，担心自己数据相关的工作被机器或者技术取代实在是多虑了。业务部门实际上更可能有类似的担忧，但本质上，大家面临的境况并无太大差异。
持续的学习精进变得尤为重要，因为技术、工具和系统的发展，需要更好地被人驾驭，而不是取代人。人需要有更好的技能，需要持续学习。这是数据部门不被边缘化的立身之本。
都看到这了，那就转发给你身边那个emo的同事。
