The complexity of enterprise systems, especially platform agnostic system, makes change management of those systems a little more frustrating than less complex client – server type applications. The Oracle EPM suite of applications is no exception to this rule.
Don’t Inflict Change
I could not write about change management without out taking a moment to jump on a soap box. I believe in proper change management. I receive calls every year for support because someone did not management a change they just made in a production system. I understand that there is often urgency to implementing a change but the potential impact of changes should always be evaluated. Here are some changes I have seen inflicted on systems that resulted in problems:
- Using Lifecycle Manager, an administrator imported Deployment Metadata previously exported from another environment. This resulted in corruption of the Shared Services Registry and required reconfiguration of Shared Services. Total recovery: two days. Had the administrator been diligent, and managed the change, he would have read in the LCM Administrator guide and understood why importing the Deployment Metadata is not a good idea.
- While rushing to change a hierarchy in the Dimension Library, one administrator accidently dragged a large chunk of her Entity dimension into the wrong hierarchy and deployed the application. The error was not discovered until reports were placed on the CFO’s desk. Total recovery: one hour for the hierarchy change. Probably longer from the embarrassment. Following proper change procedures, this administrator would have made the change in another environment, validated the results, then migrated that change using a proper tool instead of making direct changes.
- One brave manager deleted an account he thought was no longer in use. He was wrong. Total recovery: one day. Recovery required restore of databases from tape that was stored off site.
Change Management Principles
Generically speaking, there are three principles for managing change.
Principle 1: Plan for exceptions. I wanted to start with this rule because we often forget about it when documenting systems change procedures. There will come a day when the framework will fail because a change must be implemented in an emergency. The emergency, when dealing with performance management applications, is often a deadline. “A last minute change to the entity or account structure must be made because we will miss the reporting deadline!” Both Ben Franklin and Winston Churchill said that failing to plan is planning to fail. Make time to document a procedure for making emergency changes to reduce the risk of inflicting a change and ALWAYS require discussion and appropriate approvals.
Principle 2: Obtain proper approvals. Failing to obtain appropriate approvals for making changes often leaves an important person out of the communications loop: the subject matter expert. I know how to design and build dimensions in the Hyperion product suite well, however; that does not make me an expert on WHY I should make changes as well as the IMPACT of making those changes. By using a proper approval workflow, you will most likely involve someone with at least as much experience as you in the process, thus gaining at least one more sanity check on your proposed modification. The first question I always ask when performing an after action review of a systems failure due to system changes is, “Who approved the change?”
Principle 3: Never change your production system (except in an approved emergency). I see more grief experienced from making changes directly t production without evaluating the impact in a subordinate environment first. Changes to metadata can directly impact calculation and consolidation times as well as report accuracy. The failure to adjust a single property of a dimension member in the Dimension Library can spell disaster (or at least discomfort) for the next consolidation in HFM.
Workflow
Change management is a workflow process beginning with a request and ending with a validated change. There are a lot of ways to manage this workflow. I will briefly describe one way. I do my best to keep this simple and short as I’m sure most administrators and developers do as well. To oversimplify, the steps are:
1. Request
- Include as much detail as possible such as the steps required to implement the change as well as the steps required to test and validate the change.
2. Approve
- The approver should be someone in authority that is knowledgeable of the application.
- The best approval steps I have seen is where the process requires the approval of the requestor’s supervisor and an application owner where the application owner is someone in authority that is responsible for the output of the application such as a senior accounting manager, controller, or FP&A manager.
3. Execute
- The administrator commits the change in accordance with the details provided in the request.
4. Validate
- This is testing – plain and simple. The system should be tested to determine if anything unintended was impacted by the change.
The scale of complexity of this process should be increased for more impactful and risky changes. For example, many organizations require that proposed changes be analyzed by a board of managers and technical personnel to determine necessity and impact.
