过去20多年来，在实现Oracle Hyperion Enterprise Performance Management（EPM）的过程中，我们得到了许多经验和教训。没有任何两个部署是完全相同的，这正是我们热爱这个挑战的原因所在。然而，有一些最佳实践方法可以指导我们在业务过程中实现Hyperion EPM技术，无论是在部署过程中还是部署之后，它都是成功的。

最重要的是要确定我们要实现什么目标。首先是要定义一个性能管理远景计划。这其中包括策略建模与规划、预算与预报及报表与分析;例如，它不应该只是计划如何将Microsoft Excel电子表格替换为Oracle Hyperion Financial Management（HFM）封闭整合过程。虽然HFM的自动化可以减少Excel数据操作的时间，但是我们肯定也不愿意在业务突然变更或者财务策划和分析（FP&R）决定必须淘汰Excel时才被迫重建技术环境。制定计划，然后考虑在绩效管理整体计划下重新设计这个封闭整合过程。

其次，我们必须让每个人都参与进来。这意味着不仅要让企业内部人员参与进来，也要让业务用户、会计、FP&A、业务单元和所有重要干系人参与进来。不要让项目变成一个“监牢式”咨询项目，即将需求告诉对方，然后等几个月时间之后咨询团队上交一本手册，并告诉您说：“如果有什么问题请与我们联系”。同样地，不要让项目变成只是IT项目。虽然他们可以安装并打开软件，但是我们可能要花费数年的时间将它调整到真正满足我们的需求。一开始业务用户就必须参与Hyperion EPM实施，这里面包括帮助建立愿景和路标，定义需求，设计和建立技术，以及最后的测试和部署。而接下来，我们又回到路标上了。

现在，我们可以利用Hyperion EPM实施的第三个最佳实践：定义需求。最佳的着手点是从使用 Value Stream Mapping （VSM）记录现有的过程开始调查需求。传统且详细的Visio程序过程往往在创建时就被丢弃了。使用VSM的关键是通过查找损耗和变异记录关键过程。一旦我们了解了当前的过程，我们就可以再次使用VSM来开始考虑以后的状态过程了。利用自己的公司来标记业务单位以及查找在以后的状态过程中包含的最佳实践。此外，考虑下同行业中规模和复杂性相似的其他公司以及Hyperion用户群。两者都是探索其他可能适用于我们业务过程事物的重要渠道。

除了VSM，为Hyperion EPM环境开发一个功能需求文档，在其中加入系统技术设计、实施成本、培训成本和部署策略。设计架构必须执行新系统的功能和技术设计及生成设计文档，其中包括详细的系统模式，例如应用和基础架构组件、元数据描述、维度、数据流和每个软件组件的细节。功能需求文档对于描述新系统的需求是至关重要的。文档必须有关于项目的整体功能范围的额外细节，而且还必须确定项目的目标、重要干系人、项目假定条件和项目内/外界线。其他需要定义的重要项目主要是与功能和数据组件相关的主要软件功能。非功能性需求的重点是可用性需求、性能和操作需求以及用户文档。最后，文档必须说明安全需求和将来的最佳维护实践。

完成了需求之后，团队必须创建一个描述关键日期、依赖关系和任务的项目计划。一旦指导委员会签字确认了功能需求、设计文档和项目计划，就可以启动技术实现过程了。最后，我们在实际开始开发软件之前所花费的精力和时间将决定Hyperion EPM项目是否能够取得成功，同时还将为我们的利益相关者提供一个很棒的例子，它可以说明正在进行的计划和预期效果。

在国际海底钻探承造商的最近一次Oracle Hyperion EPM Suite实现过程中，他们使用了这里的每一个最佳实践。公司建立了一个包含以下指导原则的愿景计划：

由一个可控数据源提供财务数据

为实际数据和规划数据提供统一数据模型

由公司和独立干系人共同协作完成项目

减少数据操作，增加分析时间

优化报告细节

用这些指导原则解决具体的需求，最终为Hyperion Financial Management、Financial Data Quality Management、Planning, Essbase Analytics Link 和 Financial Reporting提供全球化并行实现计划。其结果是从一个孤立的手动过程转变为使用自动化的集成技术。在技术应用实施之前应用这些最佳实践，最终帮助他们解决了集成性能管理，成功完成了整个项目计划，同时也让这个组织能够在全球海底钻探行业中继续保持自己的动态性。

遵循这些最佳实践方法 ，我们还需要经过长时间的努力，才能最终在有限的时间和预算范围内实现一个成功的Hyperion EPM，而且最终产品才能够被股东接受，并且能够支持和适应公司的持续发展。