作为一个数据顾问，时常会感受到一种被动感和无力感。

因为， 数据问题往往不是数据人的问题。

数据人员经常会因为提供给领导的报表数据太迟或者有差错、不一致、不完整等，而被领导骂，但这些数据问题，往往不是数据人员处理数据的问题，而是业务部门生成数据时出现的问题，出现这些数据问题的原因，不是数据处理技术的问题，而是业务操作不规范、业务规则不完善、业务管理不到位的问题。但由于 数据统计是整个业务流程之后以及之外的一个环节，数据人员作为数据的被动接受者和基于其上的再处理者，只能报出声声无奈。

当你的关键用户是数据人员，或者问题源头是其他部门时，当你们就此问题与问题业务用户讨论时，他们往往会说我业务做下去没问题啊，不要因为一点数据方面的事情影响我业务开展，数据你们自己处理下么，总归可以处理的。。。如果你的关键用户在公司里不够强势，那么只能由他来做各种处理，而他反过来提出来的各种报表要求实际上就是一堆打补丁式需求，这个数字不能直接用，得基于xx处理下，然后这里要写死，然后这里有一个特殊逻辑，然后这里得给我一个调参数的地方，然后这里需要可以导入一些数字，然后那里我需要手工改一下数据。。。这时候你和你的关键用户是很有共情的。

如果你有能力，可以帮你的关键用户一起去跟业务部门争，跟业务部门所对应的业务顾问争，不行的话向上级领导反映。但这一切都基于一个前提，相关对象是有管理理念的，是真正认可规范带来效率，效率带来效益的。但实际上，相当多的人会取直接的短期效益，而舍间接的长期效益。往往一句话，“这会影响我业务开展”，或者“现在这么不景气，就不要再多要求了，增加困难”，风向就变了。

所以，真正的办法， 核心是让产生数据的部门和人员直接用数据，重要的是，通过用数据，对“他们自己”产生价值，让他们意识到在做业务的同时，快速准确地生成数据对他们至关重要。然后才是发挥旁边的数据人员的力量和上边的领导的力量。当然，这三维力量缺一不可，形成 可行性三角。

这个“核心”往往是最难达到的，因为你可能要说服的是一群用自己的办法做事的业务员和一个只是因为业务经验和能力而提拔上来的管理者（或者说业务老大）。他们排斥因管理目的而要求自己，更排斥因着数据的原因而要求自己。

领导是有用的，但也可能是最无用的，有用自不用说，没用是因为领导毕竟只能关注到表面或个别，很难有效地影响日常运作中的每一个细节，而真正对业务人员形成数据价值的可能正是从这些细节出来的。

数据人员是有用的，但有用的程度在于其势，如果是强势、有权势的，是最理想的，这种情况下，一般数据部门/人员同时也是代表领导层的管理团队，其有着向上和向下的影响力，又由于日常处理数据的需求，可以很好地推动数据的理念和应用。

再跳出来一层来看，实际上在项目初期的初期，我们就需要对这个公司做一快速的了解，要对整个公司的发展阶段作出初步判断， 所处发展阶段和状态非常重要，这是真正决定是否合适做数据项目以及怎么做这个数据项目的基石。是否有一定的管理成熟度？是否正处于艰难的业务开展阶段？管理成熟度要有，艰难不要有，否则无法强调规范性、无法强调管理，也就无法强调数据对业务的真正价值。当然，这一点对纯线上企业无效，因为那是原生的数据驱动的业务模式。

在迅速闻出味道来之后，在项目初期，尽早的，就要识别前面所说的可行性三角的状况，分别形成针对性策略。

如果这个公司不具备数据价值的认识能力，那就要真的从头好好想想，该交付怎样的数据分析方案了。

有时候我是有些气恼的，因为明明某个客户还没有到数据价值最大化的阶段，应该聚焦比如说基础业务系统的建设，但是销售团队为了扩大项目规模，就继续忽悠，客户也被所谓的智慧、智能、数据驱动、最佳实践转型等那些最时髦的概念所打动，就也上了数据项目。。。

倒不是说这种企业体现不了数据价值，我认为，不管什么企业，什么阶段，数据都有其价值，差异是以什么样的方向和形式来体现。是智能么？是自动化么？是深入分析、数据挖掘么？是自助灵活分析么？可能是最基本的统计，最明细的数据表导出更合适。

所以项目售前阶段很重要，如果可以的话，最好自己直接参与售前，尽快加深甲乙双方的理解，把握项目内容和方向，定义好未来主要的交付点和价值点。否则可能就是拿着一个烫手的山芋。