|BI then ERP Strategy [message #309069]
||Wed, 26 March 2008 06:29
Registered: March 2008
Location: Stamford, CT
We have a BI strategy proposal on the table that we have been asked to validate to confirm that it is not something so off the wall that the risks of implementing outweigh the benefits as we prepare for implementing a new ERP.
We currently have several ERP systems (one regional implementation of JD Edwards and 3 large implementations of a legacy system called JBA) and are just kicking off a multi-year project to implement a single global instance of JD Edwards. As part of the ERP implementation, a centralized Global BI solution will also be implemented.
After some research we found a “out of the box” JDE-BI solution that will handle the majority of our needs for the BI middle tier (Data Warehouse). This solution comes in two parts: 1)a central data repository that matches the JDE structures but already has the basic transformations done to make it easier to use and 2) Several functional data marts (A/P, GL, Sales, etc) built off of the central repository that are ready for any number of front end BI tools to be attached. We will be attaching a BI reporting tool and building out the presentation layers ourselves.
Our proposal is broken down into several phases.
Phase 1 is to implement the solution against our current JDE solution.
Even though there is no immediate business requirement for advanced analytics out of this environment today, since it is such a vanilla JDE implementation, it gives us the experience of using the new tools that come with the out of the box solution. It also puts the model into some context. This context will allow us start figuring out what is missing.
Phase 2 is to build out the extensions to the purchased model that we think will be necessary to support our business going forward. There are 4 types of extensions under consideration, but until we actually see the model we will not be absolutely sure.
1)Create reported and booked dimensions that handle history conversion.
2)Create monthly capture of dimensions which is our version of (SCD).
3)Build out complete model for non-JDE sources (e.g. retail data, forecast etc.)
4)Set up daily closing balances for time series analytics. (e.g. closing inventories, open orders, etc)
I want to expand on what I mean by booked and reported in the 1st extension since this is what is considered the most “revolutionary” by our CIO. Every table in the model will have has as part of its primary key the source system. This allows multiple source systems to be loaded into the model independently. We plan to add a level to the bottom of every dimension that allows us to manipulate what the users see as “reported”. This allows us to manage history conversion as a hierarchy vs. the traditional method.
This is outlined better in a published paper on page 14: http://www.oracle.com/solutions/business_intelligence/docs/data-warehouse-elizabeth-arden-wp.pdf.
Phases 3 will convert history from our legacy JBA systems and allow legacy reporting using the new “out of the box” JDE model . Development of history conversion routines that incrementally convert history enables the development of reporting structures against the legacy JBA data. This will allow BI users to run queries and reports against the legacy information still sourced from the JBA legacy system but “converted” into the new JDE data model. It will allow us to introduce the new BI tools to the business well before we go Live with JDE. This spreads out the change management burden by pulling forward BI roll out and training tasks.
Phase 4 is to develop replacement repository for non-JDE systems. This will enable users of non–JDE data to perform reporting and analysis in the new BI front-end thru the new data model. When practical, begin eliminating “direct access” reporting from non-JDE data sources that could challenge the “single version of the truth” mantra.
Phase 5 coincides with phases of the JDE implementation and as needed starts converting hierarchies to present both historical facts and new JDE facts against JDE managed master data.
I would appreciate input from anyone that can help vet out this strategy.