Migrating from OBI to Incorta

I am sharing my experience of migrating from OBI to Incorta.

Process

1. Start with Incorta EBS Blueprint
2. Configure and customize for the deploying company
3. Optionally, Demo the Fusion Connector
4. Preview and demo to business users using their own data
5. Provide the existing OBI dashboard usage analysis – Help prioritize the replacement project
6. Provide the lineage and SQLs from OBI. Get the access to nqquery log and SDE logic to the development team
7. Analyze the SQL and OBI report one by one against the blueprint business schemas
8. Interactive processes about enhancing Incorta physical schema and creating dashboards in Incorta
9. Create materialized View when necessary
10. Demo and get feedback from business users during the development
11. Leverage the existing OBI team in verifying and comparison, help the team gain knowledge about Incorta for future support
12. Prepare the pilot and overlap period before shutting down OBI. Define the Exit criteria
13. Prepare the training to the future analyzers/superuser, who can create and manage their own contents. This may be necessary as a recursive event for several months. Providing an office hour will be helpful.
14. Provide a demo to Excel Add-in if necessary
15. Provide the SQL interface if necessary. Control the usage by understanding their usage. This may be helpful for Tableau users, but need to be careful as it impacts the system resource usage
16. Schedule the dashboard delivery and the download. Configure the integration with network drive storage. FTP, dropbox, OneDrive, GDrive, etc.
17. Along with the development of the new content, start discussion about job schedule options. For example, dependencies from Incorta to source app batch process. Also, understand the source data update pattern and frequency. For example, when the Transfer to GL was executed, when the depreciation process is executed. How frequent these processes are run. For example, any difference in period closing weeks?

Very few resistance from existing OBI developers since most of them see this as an opportunity.

Learning new skills such as using Spark SQL and PySpark in creating materialized views. Explore ML library in Incorta.

Their Data Model knowledge is typically the asset to the new platform.

OTBI vs. OBIA

Several people are curious about what are OTBI and OBIA, and what are the differences between OTBI and OBIA.  I will discuss these in this article.

OTBI stands for Oracle Transactional Buisness Intelligence. 

OBIA stands for Oracle Business Intelligence Applications.

Let’s start with OBIA.  OBIA is the pre-packaged BI Apps that Oracle has provided for several years.  It is the data warehouse based solution.  It is based on the universal data warehouse design with different prebuilt adapters that can connect to various source application to bring the data into the data warehouse.  It allows you to conslidate the data from various sources and bring them together.  It provides a library of metrics that help you measure your business. It also provides a set of predefined reports and dashboards.  OBIA works for multiple sources, including E-Business Suite, PeopleSoft, JDE, SAP, and Fusion Applications.

OTBI is different.  First of all, it is a real time BI.  There is no data warehouse or ETL process for OTBI.  Second, it is for Fusion Apps only.   OTBI is leveraging the advanced technologies from both BI platform and ADF to enable the online BI queries agains the Fusion Applications database directly.  In addition, in some area, such as Financial, you can also connect to the Essbase cubes.  Unlike OBIA, OTBI does not have a lot of prebuilt dashboards and reports.  The reason is that for some advanced analysis, the data need to be prepared.  You cannot get eveything you can get from the OBIA data warehouse in OTBI. 

Both OTBI and OBIA are available from the same metadata repository.  Some of the repository objects are shared between OTBI and OBIA.  It was designed to allow you have the following configurations:

• OTBI Only
• OBIA only
• OTBI and OBIA coexist

If you implement Fusion Apps, you can enable OTBI.  You can use the BI EE Answer to access the prebuild metadata and metrics those are built against the Fusion Apps.  You may not get the full powerful prebuild dashboard and repost and prebuilt navigation workflow.  However, you can start experiencing what the BI EE based reports look like.  You can start bring the data out from your OLTP system.  You can provide training to the users to get familar with the subject areas, some of which are shared with OBIA. 

If you enjoy OTBI and want to further get OBIA with a data warehouse based solution.  You can implement OBIA later.  Some of the OTBI reports maybe switched to run against OBIA.  Some of OTBI reports can continue connecting to Fusion Apps directly.  They can coexist in a single BI server and a single BI answer client.

Both OTBI and OBIA are accessing Fusion Apps via the ADF.   This is a more advanced topic. 

 

 

 

BI Applications and Embedded BI, Part 2

This is a topic I wrote in six month ago. In the Part I of this series of articles, I mentioned that a warehouse like architecture is required in a heterogeneous environment. I want to elaborate more about this. In the future posts, I will also describe the integration technology I learned for supporting the embedded BI.

Aggregation for Data Warehouse, Part 4

I have briefly mentioned the various approaches of providing aggregation for data warehouse. This post describes the third approach of using the Materialized View (Oracle) or Automated Summary Table (AST, DB2) from the database system.  I will describe the Pro’s and Con’s of using this approach.

A materialized view, like a table or a view, is a database object. A materialized view can contain the results of a query. It enables you to have a very efficient data access to the pre-aggregated data. It also helps you to maintain such aggregated data by simply defining the query, like creating a database view.

What is a BI analytical application ?

A BI analytical application provides the following four key components:

1. Pre-built ETL to extract data from the operational tables in the transaction system  and load to the data warehouse
2. Denormalized Star schema which is optimized for BI queries
3. Best practice metric and calculation libraries that are created based on the data warehouse and operational sources.
4. Pre-built graphics, reports, dashboards, and alerts that designed for specific roles and business processes

It is actually a very lengthly process to build an BI analytical application.  That is why people now buy the pre-built BI analytical applications.

Bookings Analysis

Bookings Analysis is to help managers to manage the demand. Although the data may come from Order Management, Contract Administration, or Project Accounting systems, the primary interest in the booking analysis is from sales and marketing perspectives.

The analytics application should provide the bookings analysis to help demand managers understand the pattern of booked orders or work and the future revenue trends for the business, enabling the evaulation of current status against the expecation and the actions to increase sales, the deal size, volume of future pipeline.

Booking can be measured by quantities or dollars.

The 4-4-5 Calendar

Some organizations use the 4-4-5 calendar for managing their accounting periods. it is a common calendar structure for some industries, such as retail.

The 4-4-5 calendar divides a year into 4 quarters. Each quarter has 13 weeks which are grouped into two 4-weeks “months” and and one 5-week “month”. The grouping of 13 weeks may be set up as 5-4-4 weeks or 4-5-4 weeks, but the 4-4-5 seems to be the most common arrangement.

When a 4-4-5 calendar is in use, reports with period by period comparison or trend over periods do not make much sense. You can still do the comparison of a period over the same period in the prior year. You can also have the week by week data comparison.

See also: The 13 period calendar

Oracle DBI vs. SAP BW from Edison Group, Inc.

I found a good white paper on a comparison of Oracle DBI and SAP BW:

http://zones1.computerworld.com/oracle/downloads/Edison_Group_Report.pdf

Building Oracle Daily Business Intelligence with Oracle BI Enterprise Edition

This is a white paper about how to build dashboard on top of Oracle Daily Business Intelligence summary tables using Oracle BI Enterprise Edition.

http://www.oracle.com/solutions/business_intelligence/docs/obiee-dbi-whitepaper.pdf

This is very helpful for all current Oracle E-Business Suite DBI users who want to add custom contents to their reports or dashboard. The most important content from this white paper is the list of all DBI physical tables.