Installing a data warehouse in an ERP environment is a conceptually economical proposition, as Business Information (BI) warehousing and Enterprise Resource Planning (ERP) have much in common from an infrastructure standpoint:

  • Both are used for storing vast amounts of data in distributed structures that have a high potential for integration.
  • Both offer a high degree of accessibility to a broad range of users.
  • Both cater to high-level distributed and extended applications (though this is less immediately apparent in the case of BI).
  • Both are based on the premise that the immediacy and granularity of data are major factors in the quality of information used for forecasting.

It’s also significant that the development of ERP technology and the emergence of BI have been on a more-or-less parallel course for the past decade, converging where technology made it sensible and diverging in function and features to cater to different facets of business intelligence and performance tracking.

Similarities aside, BI and ERP are by no means the same thing or even two sides of the same coin. They are complementary systems, their greatest commonality being that they move a company in the direction of greater efficiency, responsiveness, and integration. The need, then, for BI in an ERP company is clear. What must you do to make it happen for your clients?

Modifying user expectations
When you launched ERP, you established a new paradigm for transaction processing for your client’s company (and, probably, its partner companies). The transaction processing systems that were moved under the ERP umbrella were integrated into each other, and systems that had been department-specific were extended across departmental boundaries, increasing awareness of the value chain companywide, and tightening processes from the inside out by loosening processing bottlenecks and improving response times.

This heightened the awareness and functional precision of your client’s user community in key areas. First and foremost, with reporting greatly improved, the integration of your client’s company’s data undoubtedly led to reports that could be assembled more quickly, based on data that was timely and more accurate due to improved validation. Second, transactions were made more real-time, less cycle-driven. And, finally, problems or errors in processing were immediately apparent throughout the processing path, leading to more rapid and accurate troubleshooting.

With BI, you have islands of decentralized, highly granular data, deeply integrated with history and stored in accessible, efficient structures that will permit your client’s users to rapidly analyze system performance from many different perspectives. Unlike transactional data, the information in the warehouse—and in the local aggregations called data marts—is unchanging, once it enters the warehouse. This is analytical data, rather than straight transactional data, so users can do far more than simply summarize. They can track established metrics against previous performance at any level they please. The data warehouse is structured to permit rapid, flexible reconfiguration of information. This, combined with unprecedented ease-of-access (users don’t need applications to get to the data; they can go straight to it, like pulling books off shelves), effectively puts the data directly into the user’s hands. They are no longer dependent upon transactional applications to get to the data they need. It is essential that you get this concept across to everyone from the start!

Data as business objects
Your next transactional step is to re-conceptualize information and the way it is used. The old hierarchy of fields, records, and files is dead, and chances are that even the highly-integrated ERP database environment you’ve cultivated hasn’t broken users of this mindset, since the applications they’re using migrated to ERP from pre-ERP origins.

You’re in a brave new world now, the world of business objects. The power of a business object is that it is independent of time and hierarchy. The business object is equally applicable to current transactions and history and may be instantiated at the most basic transactional level, the departmental level, the company level, and the industry level. That’s a lot of power in one little package!

Then again, maybe it’s not so little. The business object is indeed a “package” of information, one whose power is in how it is conceptualized and arranged. You can think of a business object as almost a virtual employee, one with a specific job and expertise that can be applied in numerous applications.

To understand the business object, you must first be familiar with the idea of metadata. Metadata is information that describes actual data; it is used to shuttle data between applications and analytical processes. Metadata is the principle building block you will use in constructing your data warehouse. You will use it to construct most of your BI data models.

A business object is more than a template for information. It defines the business tasks that are enabled by that particular information and collectively defines the role of the executor of those tasks (and it is in this sense that such a business object is a ‘virtual employee’). The incredible portability of the data models defined in this way can’t be overemphasized; such an object is available to all users of the data warehouse and puts analytical power at the fingertips of user’s at all managerial levels, across all departmental boundaries. Consider that a low-level warehouse bookkeeper can use the same Cost Accounting object that the CIO uses (and they both can use it on-the-fly) to do a local inventory carrying costs analysis with the same timeliness and accuracy that the CIO employs (using the same object and task set) that the CIO uses to determine whether or not to drop products from the company’s catalog.

And, yet, your focus here is not on implementing this treasure chest. Instead, your emphasis is on teaching your clients user community to think this way and to enlist them in doing the information modeling that will enable your client’s BI metadata and business objects. Emphasize where business objects can take them: They now have the power to roll their own, and the business object can facilitate analytics, datamarts, custom queries (as simple as spreadsheets, but with far more data accessibility), and even Web page use.

How does it work?
The beauty of BI is that the platform for this paradigm is, most likely, the highly-integrated ERP database environment that’s hiding underneath it all. To simplify (and this is, admittedly, an oversimplification), your ERP database environment is the primary BI source. It is assumed that this environment is a well-integrated table-driven system. There is a staging area interfacing the ERP database environment with the ERP system where metadata is transferred. Extractors will be written to cull the appropriate information from your transactional system into the business-oriented warehouse structures (API operates at this level, too).

All of this precedes the BI’s engine, which is comprised of a source management system (tracking what information is coming, and from where, as well as defining all the transfers) and a transform-and-load mechanism that performs necessary operations on any data that must be massaged in order to be useful in the BI context.

Metadata now kicks in, defining information in functional terms. From here, high-level functions take over: Information now in the warehouse is made available for modeling, for analytics, and for user-defined presentation. Remember that data warehouse information is primarily for analysis; it is not updated or changed by BI user applications.

Your client’s users never need to know any of this. What’s important for you to realize as you home in on the vendor-specific details of the architecture described above is that you are creating a decentralized, build-as-you-go environment that can be grown from the inside out. You can start out as small as you like and never be fearful of having to tear down what you’ve created. BI wants you to add on, not rebuild.

Extending BI for decision support
How about a final word just to whet your appetite for future development? BI lives on top of ERP’s core architecture, but you can put a layer on top of BI, once it’s in place. You can create a “virtual” enterprise on top of the warehouse that’s on top of the actual enterprise system. What does this mean?

Put simply, you can network your client’s data warehouse resources together into a business intelligence network that functions much as ERP does from the top-down view—as one big distributed application environment. This will increase the performance management potential of BI in your client’s company, allowing you to generate and submit extremely precise performance metrics at the departmental level to create a real-time, companywide picture of collective performance and value chain monitoring.

The take-home point: BI lives alongside ERP in perfect harmony and offers many benefits that ERP doesn’t. The technology is there for the taking; all you must do is seek dedication from management and users in learning to think in new ways.