Oracle Business Intelligence

Graphical interfaces and ability to sit above multi-faceted cubes can produce strong reporting and dissection opportunities to mine and exploit data.
Much of the Oracle BI is from third party acquisition (e.g. Hyperion), and while this has it's own issues, it does provide opportunities where it can interface across the Oracle family of products and be interfaced with Oracle, PeopleSoft and JD Edwards ERP. Such capability supports large enterprises that may have a mix of Oracle Financials and PeopleSoft HR (utilising specific strengths of each product set) where underlying cubes of data can mix, match, and slice data to inform and forecast effect and impacts.
Certainly strides have been made in the graphical interfaces of the Oracle BI stack, from display on desktops, to reporting, and more recently mobile devices. Display of information is relative to the form factor, relatively responsive (dependent on comm. links) and can be paired with scheduling tools for automated notifications and reporting.
This has advantages of not only ad-hoc reporting for users, but can also simplify regular reporting cycles such as month and quarterly end reporting.

Overheads of management of underlying cubes can be troublesome due to the nature of products in the Oracle suite. Due to the acquisition of rival or complimentary products from other vendors and partial assimilation into the Oracle stack, and a reliance on old code as the base level of many Oracle products (including PeopleSoft); a strong knowledge of tables and inter-relationships is imperative. unfortunately in my experience a number of clients will also customise tables and fields which can further complicate maintenance and understanding.
Creating an Entity Relationship Diagram (ERD) for your BI, whether Oracle or other products, to inform your Configuration Management Data Base (CMDB) can be most beneficial over the life cycle of products and BI overlays.
Due to the nature/origin of the Oracle technology stack, the major drawback is often the need to employ (directly or via third party) specialists to configure, manage and maintain the BI stack. This is not just for knowledge or changes needed to BI to ensure effective operation, but also where institutional knowledge is required in the configuration and scripting required to ensure that source tables are appropriate and populated to support the BI outcomes desired.