Examining the ongoing challenges of delivering high-quality, value-added ERP services in Higher Education.
Sunday, September 8, 2013
When I was first learning how to implement business systems, the conventional wisdom was to focus on reporting / data warehousing in the latter half of the initiative. There were a lot of reasons for this approach:
As my career progressed, I learned this perspective was not idiosyncratic to the companies who employed me or the clients we served -- in the waterfall boilerplate applied to most every ERP project, reporting became the focus later in the game.
- You have to make all the transactional system design decisions first
- We can go live without reporting; we can't go-live without the main processes
- Users don't know what they want until they get their hands on the system
- If you start too early, you'll just have to re-do everything later
The problem is that projects run out of time and money, at which point those things relegated to the backstretch are often slashed. So you slap together a quickie data mart and a few canned reports and voilà, you've met your obligations to deliver reporting with the implementation. Ten years later, the same lousy reporting suite is still running and users have created all kinds of off-line shadow solutions to work around the limitations. But that is not even the worst outcome of this approach.
Last year, I developed the below visual to describe the ingredients to a successful business intelligence program, in part to illustrate that technology and tools are only one piece of the puzzle -- and quite honestly, they're the "easy" part.
Most of the time, the real challenge sits within the other three areas. A lack of common data definitions, for example, is seldom technology's fault and can seldom be truly "fixed" through code (although too often it may be masked or worked around that way). The problem is that business practices need to be modified or that people need to be convinced to accept a new way of looking at things... You cannot throw a data visualization tool on top of garbage and expect miracles.
The real problem in waiting until the end of an ERP project to think about reporting and business intelligence is that you miss an opportunity to implement BI tools and structures in parallel with the good work around process re-design and policy revision that is required by the implementation effort. In fact, seeing the analytic output, however preliminary it may be, in lockstep with the configuration of the transactional system may help you to avoid missteps that could be incredibly costly to unwind later on; in this sense, BI can serve as an early warning system. By waiting until too late, you greatly increase the cost and complexity of your BI undertaking.
At the same time, I don't think enough implementations think about the role that BI / reporting can play as part of the implementation effort -- on one of the recent projects in my institution, we missed a golden opportunity to use OBIEE during the pre-migration data cleansing effort. By making the BI infrastructure one of the first deliverables in your project plan, you can start taking advantage of that powerful capability (and costly license!) to mitigate risks and potentially generate positive buzz.
There are many challenges with implementing a new business intelligence program, and starting earlier does not eliminate them. However, all effects I see are positive... This is the tactic we are employing in my very large implementation of the student information system at my institution.
As it stands, here are some of the activities we are undertaking:
People in the industry to whom I've talked have described this parallel-tracking as a "breath of fresh air" and I certainly hope they're right... I look forward to delivering ongoing updates on this approach -- hopefully most of them on the positive side of the ledger!
- OBIA data warehouse connected to the PeopleSoft prototype environment so functional teams can test configuration impact on analytics in real time.
- Raw historic data staged in data mart, exposed via OBIEE to explore anomalies to inform the data mapping process.
- Pilot deployment of OBIEE reporting against legacy data marts to deliver immediate business value (official benefit) and get early start on user acceptance of new BI tools (private benefit).