1. Essence of BI – Operational BI vs. Analytical BI
Operational & Analytical BI
Retailers/Wholesalers, at least some of the ones I have visited so far, often tend to make confusions between the “operational and analytical worlds” and Business Intelligence (BI) applied to the operational side and BI applied to the analytical side. I know that some readers and DW/BI followers/practitioners consider BI as unique, not distinguishing both. But for me, and this is my opinion, there is a clear limit between one and another.
The purpose of a BI solution is to provide “value” to any business entity, being this entity any operational, daily intervenient, such as a buyer, or any other agent more related with higher strategic arenas, for instance anyone from a Finance department. So, if this “value” can be obtained from operational sources directly, providing immediate means and reasoning to trigger some action (let’s imagine I want to apply some emergency promotions, knowing that my downtown stores are not selling a specific product today), then yes this is an action that I take upon realizing the sales volume for that product in that store in my processing day => this is, for me, Operational BI. If value is obtained from long term kept data, including or not today’s transactional data, with for e.g. nightly batch based Data Warehousing solutions, then yes we have Analytical BI. But, if today’s ERP’s allow some historical data to be kept, for some specific areas, where are the limits between both? This question can be somehow answered with another question:
Is the analysis impacting the working performance of operational users?
Operational BI against the ERP should be used for non exhaustive analysis, such as proving minor historical answers or obtaining the results of daily operations/processes. Deeper and/or complex analysis should never be done in the Operational side, mainly because these systems follow a 3FN normalized model, where performance is decreased with multiple consecutive query joinings. This is already known in theory and, as a consultant, I always try to explain the impacts of having complex Operational BI applied to the ERP directly.
An ERP is meant to be transactional not analytical and that is why Data Warehousing solutions evolved in the last few years. This scenario happens in the Oracle Retail (OR) domain with, for instance, the Oracle Retail Merchandising System (ORMS). ORMS keeps historical data in some cases, but this system itself should never be used to do complex analysis. Can you imagine the impacts of having this core system slow/down when one of your buyers wants to approve a buying order to guarantee that stock and customer service levels are not affected? ORMS or any other OR transactional module is meant for operations, not for analysis.
2. From the ERP to the DW with Oracle - a few more considerations
ORDW, ORDM, OR Analytics
Usually we have a large set of distinct intervenients and areas involved in any BI pre implementation discussion such as Commerce, Finance, Supply chain and others. We expect to have questions, varying from the most simple ones to the most complex, operational or/and analytical, technical and business related.
So, having Oracle a large set of newer/older solutions, what shall we suggest? What has Oracle to offer? Shall we go for a be spoke solution or a packaged solution? What are the Pros and Cons? What are the challenges and risks of implementing one or another solution? These are some of my considerations:
a) A Be-spoke solution with OR
Any retail be-spoke solution, with OR as the back end, is a great solution when there aren’t considerable money and time constraints. Well, everyone has time and money constraints! But, without these two variables, an in-house well designed solution is always a good approach because the DW/BI solution is built from scratch according to business users requirements. Having a typical hub and spoke approach, following Inmon or even Kimball with pure star/snowflake modeling, a be spoke solution can provide Operational and Analytical BI if the BI component is designed to cover both layers. A packaged stable solution is more suitable when the retailer requires a faster deliverable, it takes less time to implement, but it is never perfect. Worst case scenario, the model may differ a lot from the current business analysis, which implies lots of customizations and understanding of the current or new needs (this can be the case of ORDM): So for a be-spoke solution clients should have in mind the following thoughts:
- Do I have enough knowledge, OR operational processes knowledge and current analysis, to design my DW from scratch accordingly?
- Do I need cross functional analysis, OR/EBS/JDA … ? Do I need near real time analysis, Operational and Analytical BI?
- Do I have in-house technical experience to accomplish this? To I need to off-shore?
- How long will I take to have this delivered?
- Looking to the current solutions that Oracle provides, what are the gaps between those and our current business requirements?
b) The Oracle Retail Data Warehouse (ORDW)
The ORDW is OR oriented. It is sourced with consecutive ORETL nightly batches, proving data from several Merchandise Operations Management (MOM) modules. It has granular and aggregated data until yesterday, but it doesn’t have today’s data. This DW uniquely covers the results (inside the facts) of applying several Merchandising processes, but unfortunately not all of them. It is a pure Analytical system (star/snowflake based), providing Analytical BI. Users must be aware that analysis with OBIEE doesn’t contemplate today’s processing data. For that purpose, ERP’s are directly consulted with BI Publisher (with static reports).
It follows type II Kimball’s approach only – as was approach. Sometimes users realize that this is a great benefit, but others don’t. It has a few reports/dashboards, forcing/allowing users to do/schedule their own ad-hoc analysis.
The ORETL framework is Java based and ORDW is packaged with a large set of interfaces from a few OR modules. The framework itself should be well tuned when data volumes are high, but some years ago I did a performance test with some other methods (ProC API, Spool, UTL_FILE) and, for the volumes I was testing, this framework was comparable to the ProC API. In a business perspective, ORDW can be limited if cross functionality comes into table.
Finance, Supply Chain, International Trading areas for instance, are not covered with ORDW.
c) The Oracle Retail Data Model (ORDM)
ORDM is a model, like described in the previous post. Being a model it can evolve and adapt to any Retail business. It doesn’t include yet interfaces for Oracle Retail or any other source. It is ARTS based, but OR itself is not, which makes the process of mapping more complicated. ORDM provides Operational and Analytical BI, plus the As Is and As Was perspective. I have ORDM here installed and I expect to see a good product soon.
It includes good reporting samples, sampled OBIEE metadata, the OLAP (workspaces “cubes”) and data mining models. This product is technically different from ORDW but, in general, it covers the same merchandising domains. At this moment, ORDM requires more stability and integrity, ODI interfaces and the BI Layer out of the box to beat the “ready to go” ORDW.
d) The BI APPS with an OR like template (aka Retail Analytics)
BI Apps are templates for cross functional areas having a dimensional DW model in the back end. Consider the following link: http://www.oracle.com/appserver/business-intelligence/docs/business-intelligence-applications-overview-whitepaper.pdf
For instance, talking about Finance, ORDW/ORDM are not Finance oriented – instead Merchandising oriented. For e.g. even knowing that Stock Ledger is kept in the ORMS, keeping financial values of daily transactions affecting stock, and interfaced to ORDW this is not enough for a Finance individual that requires deeper & consolidated accounting related analysis. Of course both ORDW and ORDM with OBIEE can be customized to cover these non Merchandising areas, but this is not the real purpose of these models!
Looking at BI Apps, the current version comes with Informatica/DAC interfaces to a central Business Analytics Warehouse (BAW). As I have seen, a specific older version even introduced Oracle Data Integrator (ODI), but current versions ODI was left out. BAW is star based only and dimensions are conformed to provide cross functionality. So, having already multiple functional areas inside BI Apps, with pre packaged interfaces and all the BI Layer, several questions come to my mind.
- Will we have Operational and Analytical BI in BI Apps? Both.
- Will BAW “Merchandising” layer be based in ORDW or ORDM? I guess BAW can only be based in ORDM model, proving b).
- Will BAW be customized with a “Merchandising” layer created from scratch? I guess that BAW will contemplate a new model, based in the ORDM. Dimensions, for sure, will be conformed to guarantee cross functionality.
- What ETL tool (Informatica/ODI/ORETL) be used to populate this layer? Well, Informatica is currently everywhere in BI APPS, but I guess ODI will be adopted.
e) The Oracle Retail Workspace (ORW)
Since I have been testing ORW lately, for some POC, I will try to put some considerations about it in the next post.
ORW seams to be a good portal based product allowing both Operational & Analytical analysis from a unique point. With Single Sign On (SSO) available for some of the OR modules, it is a great (not yet largely implemented) solution to provide a cross functional prespective of the business and take the best decisions with greater transparency for end users.
3. Summary
ORDW, ORDM or BI APPS with Merchandising included in BAW (not released) are/will all be valid solutions. I believe none of them will die so soon and they all have place in the market.
A working effort, gap analysis and requirements should be evaluated for each client. If you are about to implement a Retail Analytical Enterprise Solution with or without OR consider the following opinions:
- If Oracle Retail is implemented => ORDW is currently the best alternative for Analytical BI. It is a ready to implement solution in version 13.1, working directly with MOM systems using the ORETL framework. If data volumes are really high ORETL needs a well tuned configuration, but interfaces for the most common analysis are out of the box and operate relatively well.
- If Oracle Retail is implemented but other ERP will still be used in parallel like EBS/PeopleSoft/JDA, cross functionality is required and both Analytical and Operational BI is required => consider a Be Spoke DW, ORDM or, in the near future, BI Apps with BAW + Merchandising layer.
