自助式分析是数据组织的一种状态

    究竟什么是自助式分析？
    为什么真正的自助式分析难以实现?

没有任何数据工具可以帮助您在公司中实现数据素养。但肯定可以确保不会妨碍我们。作为BI工具制造商，很容易反省太多，如何解决所有客户问题的方法，等等。但事实是，BI商业智能问题是社会技术问题，你通常必须同时修复企业数据文化、流程以及BI工具的组合才能解决。

究竟什么是自助式分析？

对于任何人来说，数据分析领域的自助服务这个概念很难定义。设置有人认为“自助服务是一种感觉”，我基本上同意这一点，什么是自助式分析取决于组织对来自其工具的自助服务数据的看法。人们信任自助分析的结果吗？人们是否愿意在不给分析师发送电子邮件的情况下获得他们需要的东西？

自助式分析取决于企业的背景（他们是否信任数据系统中的数字？）和数据成熟度（他们对BI工具感到满意吗？）以及业务用户的需求（CEO是否为指标消费定下了基调？）。

所以，是的，当您谈论自助服务分析时，企业环境很重要。在一家公司中工作的自助服务设置可能与在另一家公司中工作的自助服务不同。

但我认为比“自助服务是一种感觉”更具体的说法是：自助服务可以被认为是一种业务成果，它成功地避免了常见的组织失败状态。更具体地说，自助式分析是一种业务充分由数据驱动的状态，但数据组织看起来不像是一支由需求到SQL翻译人员组成的大军。

具体说明如下：假设您有一家小公司，你意识到你需要一个数据分析团队，所以你聘请了你的第一位分析师，并使用Google Data Studio或Tableau或其他一些分析平台。您的分析师为管理层制作报告，几个月内一切都很好。但最终你的分析师无法跟上她从最终用户那里收到的所有需求，所以你雇佣了第二个分析师，还有第三个、第四个…。然后你的公司成长起来，创建了向不同领导者报告的部门，每个部门都雇佣了自己的分析师，现在你在公司的各个部门都有一群分析师，都在编写查询或调整Excel电子表格，只是试图跟上你的公司向他们提出的业务要求。

这些分析师大多是需求到 SQL 的翻译人员或 Excel 制作师。他们都相对年轻。当然，有些是资深的。但总的来说，他们的职业发展并不多。他们中的许多人对自己的工作不满意，其中有相当一部分人每六个月左右就会流失。您不断招聘新的分析师以满足业务需求，并咬紧牙关应对不断流失员工的管理挑战。

失败的数据驱动状态

请注意，在此方案中，您的公司是数据驱动的。但这是自助式分析应该解决的失败状态。这是一个失败的状态，因为维持一支需求到SQL翻译人员的队伍是相当痛苦的。理想情况下，您需要一小群可以为更多数据使用者提供服务的数据人员。达到这种规模的唯一方法是拥有某种形式的“自助服务”——也就是说，业务用户可以以某种方式获得他们需要的数据，而无需通过分析师。

换句话说，自助式分析作为目标很有价值，因为它增加了数据团队的运营杠杆。你可以用更少的分析师为更多的人服务。这是一个理想的业务成果。

现在：请注意，我尚未定义自助服务分析平台在此上下文中应具有哪些功能。请注意，我没有谈论工具，流程，甚至组织结构。所有这些都取决于公司的性质。

相反，我通过告诉你它不是什么来描述自助式分析——这是公司数据驱动的失败状态，而是他们只是为解决问题，有 100 名数据分析师分布在六个部门编写 100 行 SQL 查询。从我的角度来看，没有自助服务你离那个失败的状态有多远。

当然还另一种说法，“在一个对数据有高需求的数据驱动型公司中，糟糕的数据组织往往看起来是一样的，但工作良好的数据组织看起来彼此非常不同”。事实上，具有良好自助服务能力的数据驱动型公司看起来都非常不同。例如，在我认识的一家消费者软件公司中，该公司报告结构中的许多人都精通SQL，因此他们能够通过面向SQL的BI工具，精心策划的数据仓库和一两个可视化工具的组合来解决自助服务问题。但这放在化妆品公司中是行不通的，因为大多数员工都不精通SQL，并且更喜欢为他们构建仪表板。这两家公司的自助服务看起来如此不同，而且与第一家公司相比，整体在第二家公司实现自助式分析目标方面效果更好。

为了理解为什么真正的自助式分析很难实现，让我们谈谈数据采用的路径曲线。大多数公司都经历了非常相似的数据采用路径曲线弧线。他们这样做是因为数据使用是由组织文化决定的，组织在获得数据访问权限时也会经历类似的文化变化。了解该过程是什么样子的，将有助于您理解什么是“真正的自助服务”的能力。

一：即席查询

业务用户不可避免地会有临时数据请求。这只是生活中的事实。

如何提供这些查询在很大程度上取决于您可用的工具。如果您有权访问集中式数据仓库，则可能会编写一些即席 SQL 查询来生成所需的数字。

如果您在更“分散”的数据环境中操作，则必须找到正确的数据源，获取所需的数据子集，然后在计算机上的任何工具中对其进行分析。这个过程一般需要半小时至半天，循环往复。

二：静态报表和仪表板

最终，随着越来越多的业务人员意识到获取数据来支持他们的论点（并且随着公司复杂性的扩展），数据团队将开始对他们收到的大量请求感到不知所措。然后，数据主管开始了明显的下一步：一个商业智能解决方案，以摆脱他的团队的一些请求。

这位数据主管开始寻找一种 BI 工具来为这些可预测的指标创建仪表板，以便让他的团队腾出时间来处理他们从公司其他部门收到的更多临时请求。一旦他创建了这些报告，他的数据团队立即开始感到不那么不知所措。

“我们非常高兴，”他告诉我们，“产品团队和营销团队都有自己的仪表板，一旦我们设置了所有内容，我们从这两个团队收到的请求数量就会下降。我们现在尝试在他们每次要求时给他们一份新报告，而不是一直为他们运行临时查询。

许多公司很快意识到拥有良好报告功能的重要性。如果他们不采用仪表板解决方案，他们会找到其他方式向决策者提供可预测的数据。例如，我们认识的一家小公司使用电子邮件通知和 Slack 通知向其业务用户提供及时的指标。关键是数字是在可重复的、自动的基础上到达它们的。

最终，新员工和现有操作员都学会了依靠他们的“仪表板”。这将我们带入下一阶段。

三：自助服务

更多的仪表板使用导致更多的数据驱动思维......这反过来又会导致更多的临时请求！随着时间的流逝，依靠仪表板的业务运营商开始采用更复杂的思维形式。他们学会了减少对直觉的依赖，以“让我们瞄准胡志明市的日本商人高尔夫球手！”或“让我们投资鱼而不是狗！这导致临时探索性数据请求的增加。

数据团队发现自己再次不堪重负。一些公司已经尝试为其业务人员进行SQL培训。其他人则购买了第二波BI工具出售的自助服务叙述。这包括PowerBI的使用范例和Tableau Desktop的拖放界面。“给他们这样的工具，”他们认为，“他们将能够帮助自己获得所需的答案，而不会给数据团队带来瓶颈。

这两种方法都有问题，但最大的问题是它们经常导致指标混乱：不同的业务用户可能会意外地在他们的分析中引入微妙不同的指标定义。

这些不一致往往导致沟通不畅，或者更糟糕的是，导致行政层面的判断失误。

路径：过去和现在

我们在这里要说的是，这个路径是普遍的，出现路径是因为数据驱动思维是一种习得的组织行为。它在整个公司文化中缓慢传播。

大多数人并不是天生受数据驱动的。他们必须学习它，就像他们学习阅读或写作一样。然而，在一个足够大的公司里，你会发现某些人的思维自然是数据驱动的;其他从一开始就似乎是数据驱动的组织可能来自数据成熟的组织，因此寻求继续他们习惯的做法。

从这个角度来看，您在团队中构建的数据功能将对数据驱动思维在组织中的传播产生影响。您拥有的数据能力越多，就越有可能使用数据来推进他们的论点。您建立的数据能力越多，您就越能为公司文化中数据驱动型人员提供传播思维方式的杠杆作用。

因此，您的数据团队必须完成的工作量随着数据驱动思维在公司中的传播而线性增加！该循环如下所示：

结果是，如果一切顺利，您的数据团队将发现自己被一波临时请求所淹没。您将寻求此问题的解决方案。您会发现仪表板和自动报告会为您争取一些时间。

但最终，随着您的组织从报告转向见解再到预测，您将不得不正面解决这个问题。

这条路径不应该让我们感到惊讶。即使花少量时间查看行业会议、数据思想领导力文章或供应商的营销材料，您也会发现这些专业人士中的许多人都痴迷于将自助式分析作为最终目标。这是一个可以理解的愿望，因为数据驱动的决策经常成为数据团队的瓶颈。同样需要明确的是：大多数公司在这方面都没有成功。真正的自助式分析是一项艰巨的挑战。

立即解决自助式分析问题

今天的情况有何不同？是否有可能比前几代BI工具做得更好？您可能会猜到我们对此的看法：与“第二波”BI 工具不同，我们认为：

    中央数据仓库的数据建模是解决方案空间的一部分：在建模层中定义一次业务定义，然后将这些模型打包用于自助服务。通过这种方式，您可以获得自助式分析的所有好处，而不会遇到定义不明确、不一致的指标定义问题。
    解决方案空间的另一部分是分析即代码。我们认为，您应该将软件工程最佳实践应用于商业智能：将分析和报告逻辑定义为代码，将它们通过基于 Git 的审查过程，确保自动测试通过，然后部署到生产环境。这样，您就可以确切地知道何时、何地以及谁对仪表板进行了更改。您的分析输出受到严格控制，业务用户可以非常自信地使用数据。

据我们所知，采用这种方法的唯一自助服务bi工具是新版的Metabase、Looker和Holistics。然而，我们期待更多的工具能够相应地进行调整，特别是如果这些想法在实践中证明了它们的价值。

这种方法最终会胜出吗？我们愿意这么认为。我们认为，这种做法有许多优点。但是，我们无法知道这种新范式会出现哪些问题。我们将不得不等待几年才能看到。
​