Oracle BI Apps - Recommandations for Effective Implementation

1. Oracle BI Apps - Recommandations for Effective Implementation John Hooker Senior Consultant Asparona NZOUG March 2013

2. My Background Senior Consultant at Asparona with focus on delivery of Business Intelligence Applications Previously held senior management roles globally in a high tech manufacturing and distribution environment. Over 20 years systems experience, including 15 years implementation and delivery of Oracle E-Business suite and further specialization and expertise in Business Intelligence and B2B applications.  Contact: john.hooker@asparona.com

3. Objectives • What it is & what it does • Likely challenges • Critical factors for successful implementation • Lessons learned • Functional perspective • Applicable to other BI solutions

4. Oracle BI Applications – What is it?What Does it Do?

5. Oracle BI Applications • Pre-Built Application Containing: • Interactive dashboards • Full ad-hoc queries and analysis • Pro-active intelligence delivery and alerts • High-volume production reporting • Predictive intelligence • Integration with Microsoft Office • Integration with iPad and iPhone

6. 1 3 Pre-built warehouse with multiple star-schemas designed for analysis and reporting on all aspects of the business. Pre-mapped metadata, including embedded calculations, and hundreds of pre-built metrics 2 4 Pre-built ETL with thousands of operation tables to extract data from a large number of operational tables and load it into the Data Warehouse, sourced from EBS and elsewhere. An extensive library containing hundreds of pre-built intelligence dashboards, reports and alerts targeted across all levels of business user and business function. What’s in the Box – Pre-Built Components

7. Pre-Built Analytics Components – Some Numbers Source: Release 7.9.6.3

8. DASHBOARDS & REPORTS • Extensive prebuilt library • “One size does NOT fit all” • SUBJECT AREAS • Many metrics and dimensional attributes not surfaced by prebuilt dashboards and reports • Incremental work to build more content from this foundation So NOT Only Dashboards and Reports Much more lies under the surface

9. Benefits of BI Apps

10. Key Benefits of Oracle BI Applications • Comprehensive integrated BI suite – no need to reinvent the wheel • Single, consistent view of enterprise information across functions & data sources • Reduced time and cost compared to serial deployment • Access to Oracle and non-Oracle data sources and applications • Flexible and Extensible - Built on a 100% open platform • Reduced load on the ERP system

11. Initial Implementation Challenges

12. Close to the Truth?

13. Where Are You Today? Organizations considering moving to a new BI tool will typically have a combination of the following: • Siloed data • Inconsistent data definitions • Variable data quality • Report centric – focus on operational reporting • Excel spreadsheet focused • Multiple BI tools • Multiple data sources • User resistance - we like what we have • Reports bottlenecks – IT managed and controlled • BI implementation as part of a wider ERP implementation

14. Cross-Organizational Collaboration • Business Sponsors – retain their commitment through bad times and good • Dedicated Business Representation – choose the right people and hold on to them – retain their motivation • Available IT Resources - choose people with the right skill set and hold on to them – retain their motivation • BI Application Methodology - BI methodologies and deliverables differ from OLTP projects • Careful Planning – although it’s an iterative process the initial project plan must be created with as much detail as possible Getting Started – Critical Success Factors

15. If implementing Oracle BI Apps as part of an ERP upgrade or implementation, don’t be left behind !! • Often BI is almost an afterthought • Common problem – requirements hard to come by in the early phases as business processes are being defined. • Be part of the initial business process and business requirements gathering for the ERP system • Starting too late may lead to a rushed and incomplete implementation Critical Success Factor - Don’t Play Catch-Up

16. Starting to Build

17. Despite the extensive pre-built nature of Oracle BI Apps, traditional requirements gathering sessions are still necessary • Suggested 3-Stage Process: • Workshop • Document • Review Approach to Mapping Reporting Requirements against BI Apps Content

18. Analyse the business process flows • Determine the key process touch points that requires BI • Determine what information is required to support the process • What specific metrics are required • Do the metrics drive further analytical reporting requirements? Workshop

19. Mapping and Gap analysis • Does the requirement exist currently in BI Apps? • If not, what in addition is required? • Identify the effort required • Document the proposed solution – may be more than one solution for a requirement Document

20. Review the proposed solution • Review the Gaps, open issues • Business sign-off • Prioritisation – phased roll out • Identify and focus on the quick wins • Note: Document and Review steps can loop where appropriate Review

21. Don’t fall into the trap of just replicating what you have today • Too much focus on operational reporting • Not prioritising effectively – identify “must-have’s” from the “nice to have’s” • No user exposure to BI Apps environment to review pre-built content for suitability • Over elaboration and building the “Perfect Solution” Requirements Gathering Pitfalls

22. Data Considerations

23. It’s ALL About The Data • Evaluate Your Data Sources • – The more sources the more complex it is likely to be • – Understand where it comes from, what it really means • – Understand how best to use it • Know your data and Identify: • – Incomplete data • – Inconsistent data • – Duplicate • – Poorly organized data • Understand your data • – Establish the single source of truth • – Establish consistency and standards, common definitions • – Effective data management and data integrity processes • “What starts right, stays right”

24. Customising BI Apps

25. Customising Oracle BI Apps • Why Customise? • If it’s all “prebuilt” why do I need to customise? • Simple reality is that customisation is unavoidable and will have an impact – never just – never just “plug and play” • Out of the box solution likely to address 70-80% of your immediate BI needs and requirements • As with other Oracle application products, try to keep it to a minimum and use the out-of-the-box functionality where possible

26. Pre-built solution will NOT contain all that you need – at all levels there will be content gaps • Does not include all the data you’ll want • - Key and Descriptive flexfields • - New facts, dimensions, hierarchies • No standard ETL mappings for some ERP data • Not all pre-built content may be relevant • Unsupported Source System(s) • Accommodating ERP Source System Specific Configurations • BI Application Specific Configurations Aspects of Customisation

27. Additional dashboards and reports, guided and conditional navigations, iBots, etc. Dashboards & Reports Easy Additional derived metrics, custom drill paths, exposing extensions in physical, logical and presentation layer, etc. OBIEEMetadata Moderate Extension of DW Schema for extension columns, additional tables, external sources, aggregates, indices, etc. DW Schema Intermediate Extension of ETL for extension columns, descriptive flexfields, additional tables, external sources, etc. ETL Involved Level of Effort Degree of Customization Typical Effort and Customisation Balance

28. Why a Pilot Can Make Sense • Beginning with a Pilot phase is an excellent strategy to build an initial but powerful foundation • Two of the biggest failings in BI projects are lack of user adoption and over-implementation • A Pilot allows you to meet and overcome your challenges in a structured and cost-effective manner • It affords the opportunity for exploration and familiarisation - no need to take a great leap into the unknown • It allows you to assess functionality and identify additional requirements for future deployment • Can be implemented in a matter of weeks

29. Why a Pilot Can Make Sense – Example • Initial roll-out was a small portion of Supply Chain covering: • A few standard OM and Inventory out of the box reports • - On-time Shipping • A few out of the box reports customised • - Sales Cycle • Re-created existing Discoverer reports in BI Apps • - Billings, Bookings, Backlog • Created new report requiring customisation at the Data Model, ETL and metadata level • - Order Source Analysis • Phase 2 was to extend the Supply Chain offering and beyond that a similar roll-out for other modules

30. Adopt good design standards – leverage from the foundation provided by BI Apps • - Naming conventions and standards • - ETL routines • Use the documentation available – there is a lot out there: • - Oracle standard reference manuals • - Oracle Support/Forums • - Oracle BI blogs • Data/Report validation is a critical element - make sure your test scenarios and scripts are robust enough • After go-live keep close centralised control of report management – there should not be a reporting free-for-all Implementation Lessons Learnt

31. Have a demo version available quickly for socialisation and familiarity and to help with GAP analysis • Drill-down functionality is useful – but too much may impact system performance and user experience • Consider instead to use filters in the report Implementation Lessons Learnt

32. Data security within BI Apps is comprehensive but be careful if customising and adding your own security • - Integrate BI Apps and ERP data security to minimize • user maintenance • Load data by need to optimise performance - if I update the data will I use it? • - Inventory transactions/balances – hourly • - SO/PO transactions – once or twice per day • - GL Balances – weekly • Performance management generally should not be underestimated and should form a large part of your implementation and post go-live focus Implementation Lessons Learnt

33. Implement Dashboard standards to ensure consistent look and feel across the application • Don’t have too much clutter – less is more • When designing dashboards display a combination of data in an easy to follow and logical flow • Design dashboards for specific roles and their needs • Include reports that include export capability to other formats like Excel or CSV • Only show reports that actually help the business – don’t have reports just for the sake of it Dashboard Customisation – Lessons Learnt

34. Summary and Conclusions • Oracle has packaged most of what you need – the hard part has been mostly done for you • Pre-built elements give you a head start - use what’s beneath the surface • The level and degree of customization around data management and exception is where most time is spent • Understand your bottlenecks and what makes your business flows and processes unique AND how to treat them – understand the GAPS • It’s as much about instigating cultural change

35. Summary and Conclusions • Don’t just replicate what you have already today - design and build for the future. “Show me something that I don’t know or that I need to know” • A measured, phase-by-phase implementation approach is recommended • Have the right resources at your disposal • A good implementation partner is important - but take ownership of the processes and tasks where ever possible • Option always exists to go it alone and build from scratch – BUT that comes with its own unique risks, challenges, costs and timelines.

36. - Q & A

37. THANK YOU !!