Hex：不必迁移300个仪表盘，应重估迁移策略

我最近与一位数据负责人交谈，他说他们必须将300个仪表板从旧版BI平台迁移到Hex。我真想穿过Zoom屏幕，握住他们的手，轻声说“不，你不需要。”但他们很坚持。你花数周、数月、数年的时间在一个工具中构建东西，而让所有人重新适应某个新界面的想法，很可能是你个人的睡眠恶魔。

那个恶魔低语说，你必须把它们全部带来。因为总有一天，会有人来要你三年前构建的那个仪表板，而且他们中午之前就需要。

真正的价值在于你的仪表板中编码的信息：指标定义和所有人都在使用的组织真相。你的下钻路径和筛选器是入口；用户真正想要的是提出他们的问题并获得可信的答案。

我认为是时候重新评估的，不仅是如何选购AI分析平台，还包括我们实际应该迁移什么，才能让自助服务最终奏效。

一个重新思考的机会

当我听到有人说他们必须迁移300个仪表板时，我实际上听到的是他们还没有完全接受AI的承诺。我理解！‘自助服务’这个卖点我们已经听了好多年。但智能体在分析任务方面表现得异常出色，它们能够遍历庞大、笨重的数据集，阅读大量上下文，从而产生原本需要某人花费数周才能获得的洞察。当然，这不会神奇地发生。它需要付出努力去组织你的上下文，如果你的数据真的一团糟，也许还需要整理数据。但当你投入时，回报是真实的。

所以，当你站在这项变革性技术的悬崖边时，为什么我们还要紧抓着那些我们已经做过、并且看到最多只能带来平庸采用率的东西呢？

仪表板提供安全感；它们是半永久性的，可以被审计和治理。这非常有吸引力。虽然我不认同“仪表板已死”的论调，但我确实认为它们需要被降级，正如Charles Schaefer所写的那样。降级为对特定用例有用，但并非适用于一切的东西。

请求那个仪表板的用户需要一个答案，而他们没有其他方式可以获得答案。更好的版本是让他们用可信数据提出问题，进行分析，并做出决策。那个答案可能最终呈现为仪表板、聊天或幻灯片。交付洞察的机会不应局限于仪表板形态的输出。

我们不应该把BI工具的所有UI/UX包袱都带到AI中。但其中受治理的逻辑应该一并带来。

所以我不需要迁移任何东西？

好吧，所以你是在告诉我烧掉所有仪表板，让每个人都在提示栏里提问？不完全是。有些仪表板值得迁移。以下是如何评估你当前的仪表板库，以决定迁移什么、留下什么。

• 查看你的使用数据，了解哪些是用户真正经常查看的。如果某个东西在过去60到90天内没有被查看过，你应该认真质疑是否要迁移它。
• 它是否包含多人或多个团队每天都会查看的指标？如果是，它就值得保留；迁移它。
• 它是否是一个一次性请求？那些会变成累赘，再也不会被查看；扔掉它。

我在职业生涯中做过几个迁移项目，当你做这些项目时，你会意识到80/20法则依然有效。突然之间，那300个的清单感觉 manageable 多了——也值得付出迁移努力。

AI可以帮助你迁移你认为值得的仪表板。我开发了一个BI迁移技能，它可以将你的BI仪表板转换为Hex数据应用，并保持相同的布局和逻辑。一旦你就什么值得迁移达成一致，时间线就是几天，而不是几个月。

你的AI分析智能体应该支持其余部分，让用户无需打开工单就能提出一次性问题。

迁移逻辑，而不是所有仪表板

AI可以在编写SQL或Python时掌舵，但它需要被引导到可信数据和正确的计算。如果我们退一步看，这正是我们在BI仪表板中所做的事情。我们也应该迁移其中的知识和真相。

在Hex，我们正在构建AI分析，它运行在组织的知识之上，其中应该包括你的仪表板逻辑。每个数据连接都可以映射到语义模型或markdown指南，而每个关键仪表板都会成为智能体推理的上下文，让你的用户从同一基础出发快速提问。

治理不仅通过限制谁可以看到哪个仪表板来管理，还通过访问你的数据团队维护的基础上下文来管理。可见性，即了解用户在问什么以及他们正在使用什么上下文，成为你的数据团队衡量和改进智能体质量的方式。

使用AI提取逻辑并将其转换到你的上下文中。大多数BI工具将数据连接和仪表板指标暴露为YAML或XML文件，你选择的编码智能体可以轻松解析。然后你要求它将这些指标和连接转换为可扩展的上下文。

这种能力已经内置在我上面提到的BI migration skill中。还有数十个其他技能可用，因为翻译成本现在微不足道。更难的部分是就你的上下文策略达成一致，并打破把所有东西都做成仪表板的习惯。

300个仪表板不是自助服务

当我们继续把自己绑在旧方式上时，我们就在限制AI时代中可能实现的东西。如果你原有的东西如此引人注目，你就不会离开。你离开是因为你已经知道你的用户需要什么，而它从来都不是300个仪表板。它是每个仪表板下面的答案。把那个带来。