The Value of Oracle BI Apps for PeopleSoft (Part II)

October 12, 2009
Larry Zagata
Blog

Now that I have provided my opinion and thumbs up approval of the Oracle BI apps, let’s discuss the nuances of implementing them.

With all of Oracle BI’s pre-built ETL, data structures and reports, one would probably think it should be very straightforward. Well, if your shop is totally vanilla and you accept the metrics as Oracle defines them, then yes, the implementation would be pretty uncomplicated. Oracle’s BI apps are built on the excellent OBIEE platform, which is proven, scalable and stable. The metrics are based upon industry standards.

But that doesn’t mean its out-of-box metrics are your metrics. I’ll get to that in a second.

Regardless of whether or not you’re a vanilla install, you still have the technical aspects of installation and configuration of the OBIEE foundation, as well as the installation and configuration of the BI apps. Depending on your security needs, your platform and overall size of your infrastructure will determine the relative ease or complexity of this installation and configuration. And remember, with any installation we aren’t simply installing to get the product available for use – we want to install in the appropriate manner for stability, scalability, failover and maintenance. These are big deals.

Aside from the technical install and configuration, the core time and effort it takes to implement will depend on two primary considerations:

First: As hinted at before, how vanilla or customized is your PeopleSoft solution? As you may have discovered, when you customize any ERP application it makes patches, maintenance and upgrades more challenging because you have changed source code, tables, fields etc. Likewise, if you have customizations it also affects the Oracle BI apps. You have to understand the changes, because they will impact the ETL scripts, data structures, reports and dashboards. For any change you make, you have to understand if the Oracle BI apps are impacted by that change and make the appropriate changes to the BI app.

Second: How does your business process map to the metrics? If you agree with the out-of-box metrics and how they are measured, then there is little to change here other than testing to ensure results. However, if your preferred metric is different than how the BI app’s metric is defined, then you either have to change your measurement preference or make the changes to the BI app.

Here is an example. Let’s say the BI app measures invoice payment terms as starting at the point the invoice is generated. This means that the due date and all of the reports use the invoice print date as the date the clock starts ticking. If your organization uses the anticipated receipt date the customer receives the invoice as the date the clock starts ticking, you have to change your measurement or change the metric in the BI app. A simple example, but hopefully you get the point. Bottom line is that there has to be some deliberate thought given to these seemingly pedestrian details.

One of the key activities of implementing BI apps is indulging this requirements gathering fit/gap process to define and evaluate the two factors mentioned above. This activity as absolutely crucial and often ignored by many organizations, who later complain that their BI systems aren’t effective. So, the best approach is not to try for the golden plug-and-play, but instead to perform the necessary planning and design first. I can’t stress this enough.

Next post, we will explore some ROI on Oracle’s BI apps. Stick around!

###

Previously by Larry Zagata: