blog想象一下，您正处于为组织内部用户开发BI解决方案的漫长过程的最后阶段。你可能会有这样的感觉，一旦你向消费者发布你的解决方案，你的工作就会变得更容易，要求也会降低。可能不是这样。开发阶段通常要求非常高，电梯物联网，在发布解决方案的第一个版本之前可能会消耗大量的时间和精力。然而，只有在发布之后，用户才真正开始使用解决方案，并在日常工作中体验他们的理论需求，作为实际的分析工具，这时会出现许多新的复杂情况。随着时间的推移，很少会出现以下情况：最坏的情况是：您的用户由于某种原因（实施不好、与用户的核心需求不一致、采用困难等）而不采用您的解决方案。在这种情况下，大数据与应用，您需要应用许多更改，甚至重新开始。最好的例子：你的用户发现你的解决方案非常有用，它对你的公司非常有益，是高级管理层讨论的焦点。很自然，云服务器特价，它会打开你的用户和利益相关者的胃口，新的特性请求和变更请求将开始朝你的方向流动。介于两者之间的任何地方。不管怎样，您都需要准备好对解决方案进行持续的更改和升级。你的客户和你您可以将其视为管理产品/服务，例如您的公司为客户提供的产品/服务。当你在做的时候，你可以把你的最终用户和利益相关者看作你的（内部）客户，他们必须对你"销售"的产品感到满意。只要你按照这种方法生活，并牢记你的产品是活的，有呼吸的，并且必须对它进行管理，以使它对你的组织有益——你作为一个BI产品所有者的生活会更轻松。在本指南中，我将描述BI解决方案在其生命周期的各个阶段交付的一些方面：变更管理、成功推出、数据可靠性等等。我将主要关注中大型组织的内部BI解决方案，尽管大多数部分也可能与其他场景相关。我们将把重点放在这个过程的业务方面，而不是技术方面。成功的3个关键1计划和管理为了准备下一个requirement\release\fix，您需要做好准备。在开始使用之前，在处理更改时，您应该考虑以下几个方面：确保数据可靠性，赢得客户信心我们需要记住，拥有BI解决方案的主要目的是让组织根据仪表板（KPI和图表）中显示的信息做出明智的决策。如果数据不准确，你就失败了。将您的数据集中在数据集市或数据仓库中，作为您的单一真实源（SSOT），并整合来自所有相关源（如Sisense Elasticube）的数据无疑会有所帮助。但是，在某些情况下，这不足以确保数据始终可靠和一致：如果在前端进行计算，则可能有多个模型具有相同的KPI术语，具有不同的度量。E、 例如，一个仪表盘的收入是根据月初的汇率计算的，另一个仪表盘的收入是根据月末的汇率计算的。在大型企业中，可以有多个具有不同计算方法和定义的数据仓库。在某些情况下，数据源本身可能存在不精确性（垃圾输入-垃圾输出）。为了使仪表盘为组织的使命服务，必须清楚数字背后的含义。当一项措施过于复杂，需要一次又一次的阐述时，它就没有达到这个目标。为了解决一致性和可靠性问题，考虑在一个地方收集所有KPI定义和逻辑，并且所有最终用户、涉众和偶尔的观众都可以访问。您可以考虑从仪表板本身引用这些解释（使用工具提示或联机文档链接）。了解用户和利益相关者的角色和责任在每一个时间点，尤其是在第一次发布之前，您必须非常熟悉您的听众。了解谁是从您的产品中受益最大的决策者，谁是您的主要用户，谁最熟悉业务流程和需求，谁是最合作的人（反之，谁是阻碍您前进的因素）。要了解BI解决方案的每个用户将拥有哪些类型的权限、角色和职责，请在交付解决方案之前创建一个包含所有相关信息的组织结构图。一旦你确定了所有相关的利益相关者，并考虑到他们的角色和责任，就可以更容易地确定他们每个人在BI解决方案中的角色——谁设置优先级，谁可以提供有意义的反馈等等。它应该是这样的：操作方法定义：根据企业文化和BI计划的目标，定义BI产品的交付方法、工作流程和标准以及数据控制流程。您需要为您的组织文化选择正确的交付方法–有两种基本方法：集中化—根据业务需求提供包含所有后端和分析组件的完整解决方案，最终用户没有调整空间。这种方法更适合于知道自己想要看到什么的业务用户，并且正在分析的业务流程非常稳定并且不会频繁更改。在这件事上，大数据和云计算，你需要更多的培训。去中心化——意味着你提供了一个初始的"普通"解决方案，可以进行调整。这种方法更适合于业务部门而不是BI团队一部分的仪表板设计师，以及需要创建特别报告并根据日常分析的案例使用不同分析工具的高级分析员。在这种情况下，您应该更加强调短的发布周期，尽可能多地包含高级用户的反馈。您还可以考虑对这些用户进行认证，以便更好地控制产品的配置。在大多数情况下，在这两个极端之间采取某种中庸之道是最合适的。问题是你的组织倾向于哪一方面，在多大程度上。了解交付方法将帮助您选择如何集中精力—是设计和实施面向最终用户的端到端解决方案，还是更专注于后端，并创建一个强大的治理和培训计划，以满足仪表板设计师和分析师的需要。您还需要设置工作流程和标准，以便在需要时支持开发人员和设计人员之间的协作。最后，您应该为数据源创建一个控制过程，以确保它们随时间推移的可靠性：在某些情况下，大数据是干什么的，BI产品所有者将是一个负责任的因素，在与其数据源相关的资产发生任何更改之前，需要他或她的签名。每周/每月与DBA或数据源所有者同步。变更管理——采用版本发布策略：就像你公司的产品根据客户的需求和偏好而变化一样，你的商业智能产品也是如此。在它的生命周期中，您需要参考变更请求、新特性请求、bug或计算问题。以下是有效实施过程中需要解决的几个问题：积压工作的优先级划分——有些请求比其他请求更紧急，有些请求更重要。发布策略的一部分是根据您的组织文化对它们进行优先级排序。对于每个功能或用户情景，您可以考虑它对公司的总体影响，如果它能减少开支、节省时间或创造新的增长机会。您还可以询问新请求是否与您的团队、部门或组织的愿景和战略相一致，并根据您的工作量估计来衡量其ROI。您还可以考虑它对解决方案健壮性的贡献（开发团队添加新特性或提高性能的内部请求通常就是这种情况）。积压工作的优先级划分应该是透明的，并与所有相关的利益相关者合作，他们应该理解你的决定背后的理由。版本控制–您应用的所有更改都应该对您的用户可用。为了更好地控制这些更改，通常需要实现某种形式的版本控制系统，以便新版本的每个版本都包含一个更改桶。发布周期、更改请求和修补程序：较短的发布周期可能意味着更精简和更少的实质性更新。这是一个快速进入市场的方法与更大和更有意义的发布之间的权衡。您可以使用短发布周期和长发布周期的任何组合来最好地服务于您的客户，但它必须保持一致，以符合对新功能的期望（每个月、每季度、每三周发布一次……）您可以根据许多软件管理方法和待办事项优先级处理方法中的一种来决定下一个版本将包括哪些特性（例如敏捷、看板）。较大的变化可能比您的典型周期周期要长。假设您决定每两周发布一次版本，并且您有一个需要6周开发的变更请求。在这种情况下，实际上对于任何特性，您可能希望将其划分为更小的故事（如果可能的话），以便在将来的版本中更容易地进行拆分。如果这不是一个选择，那就在进行中的版本中并行处理，一旦准备好，就添加到下一个版本中。为了一个非常紧急和重要的