前几天，我在Linkedn上看到一篇文章，讽刺地说，我在这个平台上看到的一切都是美好的。事实上，这就是人们在阅读时间线几分钟后的印象（例如，在任何关于IT产品的商业演示文稿中也是如此）"我们都知道这个世界并不那么美好，项目并不总是按照我们想要的方式进行。我已经在商业情报界工作了几年，这篇文章让我想起了那些尽管我们有优秀的顾问工具（是的，这篇文章是关于"经验教训"的，我希望它能帮助你避免商业智能项目中的错误（其中一些是SAP特有的，但大多数都适用于任何BI技术）。51这一点无疑是BI的主要敌人之一。不信任通常源于以下两个原因之一："BI报告（有时）与源系统报告不一致。数据不允许追溯，因此无法确定它们是否正确。—如果第一点发生，用户很可能会放弃BI，保留源系统提供的或多或少的八进制列表。如果第二次发生了，那么，你可能会花一整天的时间谈论它，并扩大"一切都是计算机科学家的错"的神话。"关于源系统，显然需要做一个保证它的开发，但然后你必须做一些开发来证明这一点。可以找到或多或少的自动交叉系统，例如，源系统中的总计列表与BI交叉（现在S4/HANA为我们提供了许多可能性），问题是，在BI中，我们通常有更多的分析维度（因此可能需要与不同的列表交叉），云服务器服务，此外，它通常会带来客户并不总是愿意承担的维护成本。"数据可追溯性"如果我们的项目有复杂的计算或集成了许多来源，请记住，在项目开始时，我们必须证明计算是有效的这在SAP环境及其令人愉快的模块中尤为突出。例如，几周前，我在一个客户身上举行了三次或多或少的会议，一次是与金融用户举行的，一次是与购物用户举行的，另一次是与房地产模块用户举行的，当然，每个用户都是其领域的专家。在每一次会议上，我们都会谈论完全不同的事情和问题。"在这种情况下，trustdata大数据，我们面临的风险很重要，因为我们可能误解了一个要求（或者更糟的是，行业大数据，直接不理解它）我们可能没有意识到他们要求我们做的是愚蠢的，或者会有更好的选择。"—为了避免这种风险，我们有几个解决方案：–在上下文中放在第一位（例如，与相关模块的顾问交谈），并能够提前采取一些主动行动。请相关模块的专家顾问陪同我们在大型项目中：一定比例的源系统顾问的参与是必不可少的。"确定我们在源系统中有哪些交易或列表，我们可以（即使是部分）对比我们的BI发展BI项目通常遵循传统的计划：项目定义->BBP->技术设计->提取器->建模->报告->用户测试…。结果是，当我们开始报告时，大数据现状，在项目开始两个月后，我们意识到某些功能是不起作用的。当我们有一个架构不正常或有一些非典型需求的项目时，这很容易发生。概念证明或使用敏捷方法论（尽管在BI中并不总是很容易做到）。51正如我在关于BI项目方法论的帖子中所评论的那样，具有相同维度集的指标应该是同一个InfoProvider的一部分，或者不管它是什么，试图避免在同一个InfoProvider中，我们有只对部分维度有意义的指标。项目的动态使我们对这条规则破例。最初，正如我所说，大数据网站，用户是专家，他们帮助定义了需求，他们理解，根据指标和维度在报告中的位置，零值（著名的"未分配"）会出现。该项目已经发展，用户也发生了变化。用户不理解报告的行为，最终放弃了BI。"——"现在，也许我要说一些令人惊讶的事情：在项目的预售阶段，人们通常非常重视将要使用的报告体系结构/工具。"——"老实说，我认为，只要选择了在市场上证明有偿付能力的工具，这一点就不重要了。我的意思是，我认为一个项目的成功与其说取决于使用什么工具，不如说取决于项目的范围和定义（显然是执行）。有一个例外：例如，我们不能把一个仪表盘工具放在一个实际上是一个卧底行动报告的地方。"我记得一个项目，客户要求使用特定的仪表盘工具。报告包括一张带有指标值的初始地理地图，但随后需要许多向下搜索导航屏幕才能获得详细信息。早在预售期，我们就不推荐这种工具，并提供了一种替代方案（客户拒绝了）。我们让制造商自己参与项目，并将风险（时间和成本）转嫁给客户。我们以正确的方式确定了项目的规模，同时始终考虑到工具带来的风险。我的意思是，我们做了我认为可以做的一切，但结果远远没有让客户满意。"一位客户要求我们帮助一个不起作用的SAP BW项目。主要问题（不是唯一的问题）是需要计算许多指标，而且经常出现错误。"大多数指标都有长达两页的解释，说明计算应该是什么样子（在大多数情况下非常复杂），因此需要数百行代码。"对这一问题的详细讨论使我们得出了一些结论："在许多情况下，计算和验证这一指标的成本高于拥有这一指标所带来的好处。更简单的指标几乎达到了同样的目标。许多指标无法在源系统中计算（因为他们需要在某个时候知道情况），这增加了BW的复杂性，并阻碍了数据的可追溯性。对源系统进行一些相对简单的修改可以纠正这种情况。"我特别有一个规则，即尽量不接受不能在源系统中进行的计算（逻辑上需要从其他系统集成数据的计算除外）。"正如我在关于SAP BI项目方法论的文章中所评论的，有一种自下而上的方法来生成BBP。我们通常在没有明确要求的情况下使用，当然，在SAP BW环境中执行它比在其他BI环境中更为常见（主要是由于Business Content中预先存在的提取器）。51这种技术可以用于执行操作报告，也可以为我们提供数据，这些数据随后将用于执行战术或战略。问题是，如果我们只是"把CCP中的东西带进来"，而没有进行需求分析或明确的需求分析，我们会发现我们的报告非常好，但没有附加值，因此很可能用户会直接访问数据源项目，让我们从各个角度（功能和技术）仔细对比BBP，让我们站在用户的立场上，了解他们需要什么和他们做什么，最重要的是，不要被同一块石头绊倒两次！"你遇到过其他问题吗？请找到她！