Enterprise Software

ERP: Create business objects using business intelligence infrastructure

Implementing enterprise resource planning can have a huge benefit for your organization. However, to reach the next level of interactivity in a business intelligence infrastructure you will need to adopt a system for developing business data objects.

If you've implemented enterprise resource planning (ERP), you've established a new paradigm for transaction processing for your company (and, probably, its partner companies). The transaction processing systems under the ERP umbrella were integrated with each other, and systems that had been department-specific are now extended across departmental boundaries. The benefits are increased awareness of the value chain, companywide, and tightened processes from the inside out, via the loosening of processing bottlenecks and improved response times.

This heightens the knowledge and functional precision of a user community in key areas. First and foremost, reporting greatly improves; the integration of your company's data leads to reports that can be assembled more quickly, based on data that was more timely and accurate, due to improved validation. Second, transactions are real-time and less cycle-driven. And finally, problems or errors in processing are more immediately apparent throughout the processing path, leading to more rapid and accurate troubleshooting.

The next leap
With business information warehousing, you take another huge leap forward along this path. You are creating islands of decentralized, highly granular data, deeply integrated with history and stored in accessible, efficient structures that will permit your users to rapidly analyze system performance from many different perspectives. Unlike transactional data, the information in the warehouse and in local 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 purposefully 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. Users are no longer dependent upon transactional applications to get to the data they need.

Data as business objects
Your most important transitional step is to reconceptualize the idea of 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. And 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 lies 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, and is used to shuttle data between applications and analytical processes in the business intelligence (BI) environment. 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 can be considered 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 users 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) 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 user community to think this way, and to enlist them in doing the information modeling that will enable your BI metadata and business objects. Emphasize where business objects can take them: They now have the power to roll their own, application-wise, and the business object can facilitate analytics, data marts, their own customized queries (as simple as spreadsheets, but with far more data accessibility), and even Web page use.

How does it work?
The beauty of all this is that the platform for this paradigm is, most likely, that 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 (external databases can be linked in). 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 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.)

Add on, not rebuild
Your 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, built-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.

About Scott Robinson

Scott Robinson is a 20-year IT veteran with extensive experience in business intelligence and systems integration. An enterprise architect with a background in social psychology, he frequently consults and lectures on analytics, business intelligence...

Editor's Picks