西班牙语

前几天我在Linkedn上看到一个帖子，有人讽刺地说这个平台上的一切都很棒。事实上，这是一个人在阅读自己的时间线几分钟后所得到的印象（如果你去看任何关于IT产品的商业演示也是如此）。

然而，我们都知道，世界并不是那么美好，项目也并非总是如我们所愿。我从事商业智能已经有几年了，那篇文章让我想到了那些出错的项目，尽管我们有一些很好的工具来做它们（是的，最后一篇也是讽刺的）。这篇文章是关于"经验教训"的，我希望它能帮助你避免商业智能项目中的错误（其中一些是错误的）特定于SAP，但大多数适用于任何BI技术）。

这一点无疑是BI的主要敌人之一。不信任通常来自以下两个原因之一：

有时BI中的报告与源系统不匹配。数据不允许追溯，因此无法确定它们是否正确。

如果出现第一点，用户将离开BI系统并使用源系统提供的报告（尽管它们不是很现代）。如果第二种情况发生，那么，很可能会花一整天的时间来谈论它，并扩大"一切都是IT员工的错"的神话

关于源系统的对账数据

显然，你必须做一个保证它的开发，但是你必须做一些开发来证明它是这样的。您可以找到或多或少的自动系统来交叉，例如，源系统中的汇总列表与BI（现在对于S4/HANA，我们有许多可能性），问题是在BI中，我们通常会有更多的分析维度（因此可能必须与不同的报告交叉），而且通常还涉及客户不愿意承担的维护成本。

数据的可追溯性

如果我们的项目有复杂的计算或集成了许多来源，考虑到在项目开始时，我们必须证明计算工作良好。

如果我们已经实施了它，但我们没有考虑到它，那么重新设计通常是必要的，客户可能不想承担它。

这是强调在SAP环境和它的快乐模块。举个例子，几周前，我在一个客户身上差不多连续开了三次会，一次是金融用户，一次是采购部门，最后是房地产模块的用户，当然每个用户都是他们领域的专家。在每次会议上，我们谈论完全不同的事情和问题。

在这些情况下，我们面临的风险很重要，因为：

我们可能会误解一个要求（或者更糟的是，不能直接理解它）我们无法发现他们问我们的问题是无稽之谈，或者会有更好的选择。

为了避免这种风险，我们有几种解决方案：

首先，让我们把自己放在上下文中（例如，与相应模块的顾问交谈），并试着事先采取一些主动行动。让我们有相应模块的专家顾问陪同。在大型项目中：一定比例的源系统顾问的参与是必不可少的。

确定源系统中哪些交易或报告是可用的，我们可以在其中进行对比（甚至部分对比）也是非常有帮助的，我们在BI方面的开发是有意义的，是正确的

通常BI项目遵循传统的规划：项目定义->BBP->技术设计->提取器->建模->报告->用户测试

…事实证明，当我们开始报告的开发阶段时，在项目开始两个月后，我们意识到某些功能…不起作用。当我们有一个架构不常见的项目或者我们有一些非典型的需求时，这种情况很容易发生，概念证明或使用敏捷方法（尽管在BI中，这样做并不总是容易的）。

BI项目中的SAP方法告诉我们，具有相同维度集的关键数字应该是同一个infoprovider的一部分，或者是相同的，我们必须避免在同一个infoprovider中，我们拥有的关键数字只对我们有意义一部分的尺寸。

我记得一个项目，相对有限，与专家最终用户。这个项目的动态使我们破例反对这一规则。一开始这不是一个问题，正如我所说的，用户是专家，大数据指的是什么，他们帮助定义需求，他们理解，根据他们在报告中设置的ikey数字和维度，它们将显示空值（著名的"未赋值"）。几年后，项目发展了，用户也发生了变化。报告的行为没有被用户理解，最终放弃了BI。

现在也许我要说一些令人惊讶的事情：在项目预售中，我们总是非常强调我们将要使用的架构/报告工具。

老实说，我认为，每当你选择的工具表明，在市场上是有偿付能力的，这一点并不重要。也就是说，我相信一个项目的成功与其说取决于使用了什么工具，不如说取决于项目的范围和定义（显然是执行），有一个例外：例如，大数据数据处理，我们不能建立一个仪表盘工具来执行实际上是秘密操作报告的工作。

我记得有一个项目，客户必须使用特定的仪表盘工具。报告包括一个带有关键数字值的初始地理地图，但后来需要许多向下钻取的导航屏幕才能获得详细信息。在预售阶段，我们就不鼓励使用这个工具，并提供了一个替代方案（客户拒绝了）。我们让制造商参与项目，并将风险转嫁给客户（在时间和成本上）。我们对项目进行了正确的尺寸标注，始终考虑到工具所代表的风险。也就是说，在我看来，我们做了所有可以做的事情，但是结果远远不能让客户满意