It is a fact of life that organizations need to upgrade NMS, CIS, MDM and other large systems to keep pace with vendor changes. This paper will discuss why implementing Oracle Utility Analytics (OUA) simultaneously with a source system upgrade is not only possible, but represents best practices for both source system and analytics implementations.   

Using Oracle Utilities NMS as an example, here’s why your next upgrade project should include simultaneous implementation of prepackaged analytics along with the source system:  

• Adding an analytic workstream to an existing project generates far less overhead than a completely separate project.  For example, you are already thoroughly testing your system, so simply adding the analytics test cases has a small impact on the overall time and cost.
• Critical analysis requirements are tackled earlier and the source system is aligned to meet the business data consumption needs. In the case of NMS, OUA can take up all the critical reporting and provide a customized view of reliability and outage. It can combine data from other sources to provide a holistic view of the outage and its impact. Out-of-the-box reports and dashboards alleviate the need to recreate a lot of transactional level reports in the source system.  
• With analytics in place, tuning and maintenance of the NMS system are simplified. NMS is now primarily being asked to process transactions, not to report on them, too.  Doing both from one system makes it challenging to do either well.  
• Oracle’s GoldenGate and ODI technology mean near real time reporting is moved off of the source system. Up-to-the-minute data can be obtained from the replication layer without impacting NMS performance. 
• Delaying the analytics implementation leaves people without the data they need to monitor operations and manage their business. This means months, if not quarters or years, until the organization can function optimally and realize major benefits.   

Combining the Projects  

Organizations upgrade NMS systems to take advantage of new functionality and to stay current with changes in technology.  The cost of such projects can be significant and take over a year to finish. Planning involves both functional and technical resources whose time needs to be coordinated.  New requirements must be collected.  Funds must be procured. Upcoming business and legal requirements need to be predicted and collected.   

But even with all of this – and partly because of it – we have seen that an NMS upgrade project is the ideal time to implement or upgrade OUA.  At first, this notion may sound counterintuitive; adding more scope to a large project seems like it adds to the likelihood of failure and clearly adds to the amount of money the organization must spend.  

So let’s look at this issue from these viewpoints: 

• There are synergies that drive down the cost of the combined project if an organization simultaneously upgrades NMS and implements OUA, as opposed to doing them separately.
• There are project management techniques organizations can bring to bear to manage multiple job streams and mitigate the risk of a project with a larger scope.
• There is clearly value to the organization in delivering the analytics sooner.  If there weren’t, why implement them at all?

Synergies

Delivering both the NMS upgrade along with the accompanying OUA for NMS together can be done in almost no extra time compared to an NMS upgrade on its own.   

In planning and executing an NMS upgrade together with an OUA implementation, the organization will do a single fit gap analysis and focus reporting requirements on the reporting system, not spend time crafting a temporary stop gap solution or attempting to retrofit the old reporting solution onto the newly upgraded NMS system.  Either of these could result in suboptimal results and duplicated effort.

Organizations do a lot of reporting against their NMS systems.  Especially during storms, real time data is critical, and a correctly implemented OUA installation excels at providing near-real-time information without putting additional strain and degrading performance of the NMS system.  And the fact is that much reporting can be done without up-to-the-minute data with no loss in value.  The BI tools in OUA are far easier to use for data exploration and to build reports than running queries against the NMS source system, and there will be no impact on performance.  Several reports can be combined into one or replaced entirely with a dashboard, cutting development time and cost, and lowering ongoing maintenance costs.   

Risks

While there are risks associated with simultaneous implementation of NMS and OUA, there are also potential opportunities.  

One of the opportunities to be had is from the increased synergies in design. Because OUA and reporting needs were considered in conjunction with NMS requirements, there is a much higher probability of system acceptance and adoption by users, truly having the system as the single source of truth, rather than depending on offline spreadsheets and other ad hoc data gathering and reporting practices that are so common. Moving to a single data repository as the single source of truth can lead to much faster and more effective decision making, and it can reduce or completely eliminate conflicting information that is common under the pressure of a storm situation. Table structures can also be designed and indexed with consideration given to the needs of OUA. This design can help streamline ETL processes, making the incremental data load time shorter.  

One of the risks that can occur in a joint project is the larger number of stakeholders that need to be involved, or the added burden imposed on those already part of the effort.  More tasks and a larger team increase communication and coordination efforts; if not managed effectively, these have the potential to lead to delays and/or rework, resulting in loss of time and money. More people and more use cases will also tend to make testing cycles longer, partly due to calendar coordination difficulties. When embarking on such a combined effort, it is prudent to secure early commitment from all the stakeholders.  

Value

Various studies from Nucleus Research and other analysts have shown that analytics projects typically return 10-13 times the investment.  We often find that investments in analytics, when projects are properly run and accompanied by good business integration and change management, have payback periods of less than 18 months.  By implementing analytics simultaneously with a source application upgrade, organizations can recoup much of the value of the investment by simply implementing it a year earlier than with a sequential project.  If you have done a business case for analytics, estimate how much more you can make or save by implementing it several quarters earlier.   

Why Oracle BI Applications are a good way to implement enterprise analytics   

Many of the core functions in NMS are best monitored by well-understood processes.  As such, Oracle has built many of these processes into the Oracle BI Applications.  We use these as a base for implementing analytics against NMS systems for several reasons: 

• Replicating NMS data in real-time using change data capture (CDC). This provides real-time reporting when necessary without putting an extra burden on source system  
• Data Warehouse and BI semantic layer are designed to combine other sources systems like CC&B, Financials, etc., to provide a single view the entire organization 
• Pre-built reports and dashboards require little customization to fit organizational needs 
• The BI platform allows for a true analytics system rather than simple operational reporting system. It is interactive in nature and its ease of use promotes self-enablement of business users 
• It has industry standard definitions for derived metrics; IT departments need not learn the specific subject matter while delivering well understood metrics.   
• It can handle semi-additive and non-additive metrics without users having to configure these 
• It has built in slowly changing dimensions. 
• The data model is set up to enable the kind of cross functional analysis we discussed before. 
• Oracle provides documentation on how to modify these to deal with configurations and customizations without compromising the ability to upgrade it.  

Oracle builds and maintains connectors to Oracle branded Utility Systems and has committed to keep these up-to-date as it evolves the underlying source application.  Partners also have built their own adapters to systems Oracle does not support, like SAP, Salesforce, etc.   

Conclusion 

When you decide to upgrade a large system which has an associated analytics application, consider implementing them together.  Doing so will help accelerate the returns you reap from each system, and it will reduce the time, cost, and risk of separate implementations.   

Finally, as your organization implements analytics, you should lay the foundation for enterprise-wide analytics, which crosses functional, organizational, and geographic boundaries.  This will enable you to address the more complex questions and problems that cross organizational boundaries and which often bedevil senior executives.  Being able to answer these questions will allow the organization to thrive in challenging times.