Shared Intelligence

Business-to-business intelligence may be the next great wave in enterprise reporting

By Kumar A. Alwar

Business-to-business (B2B) e-marketplace is in essence a service by which business partners and customers conduct business in a virtual environment. Because those parties need proof that their involvement in the e-marketplace has value, the service provider's most valuable asset -- if it's lucky -- is the business intelligence (BI) that it can collect about partner-customer transactions. Thus, having a proper architecture for capturing and distributing that information -- that is, for defining, analyzing, and implementing both technical and BI reports -- is a large factor in an e-marketplace service provider's success.

Many articles and books have been published about system architectures that can capture transaction information deriving from B2B e-commerce environments, but the reporting requirements for e-marketplaces are so unique that most standard BI architectures will fall short. For example, creating reports in a B2B environment involves much more than just formatting information; it also involves understanding the B2B business community and target customers involved, identifying proper data sources and distribution methods, and security. In this article, I'll describe an architecture that is specifically geared toward addressing most, if not all, reporting requirements for these B2B-type businesses.

Looking Over the Architecture

A BI architecture for such a service provider must address two kinds of requirements: the internal need for information and the external need for information. (See Figure 1.) The internal reporting need mainly involves financial, operational, and customer relationship management (CRM) reports that will help the provider's IT staff manage day-to-day operations. The marketing staff may also require analytic reports about customer behavior to help them recruit new business partners and customers. As for external reporting needs, two types are possible: one to provide information to business partners about the state of their business activities within the B2B e-commerce environment, and another to provide consumers with information about price differences, specifications, and complementary products.

Figure 1 clearly shows that this architecture must also support two types of users: remote and internal users. Remote users are external users who access B2B transaction information through the Internet; internal users (usually service provider employees) access that information through the company intranet.

FIGURE 1 The B2B reporting architecture.

Click HERE to see PDF of figure

The architecture also supports reporting directly from the operational systems. These reports are usually in hard-copy form and are produced by applications such as ERP software. They often contain raw system information, and most organizations consider them classified.

SEEKING APPROVAL

THE TECHNICAL APPROVAL PROCESS IS IMPORTANT TO SUCCESSFUL B2B REPORTING By definition, a B2B e-marketplace environment is highly distributed. successful customer-focused clicks-and-bricks strategy. Thus, all reports defined by the business team must go through a technical analysis and assessment process before the technical specification is produced. Many factors deserve consideration here. When the report is in the definition stage with the business analyst, the analyst must classify the report's content based on the eight categories I've described. In addition to performing content analysis, the analyst must also gather the following information: Target audience for the report Age of the data (realtime, hourly, daily, weekly, monthly, quarterly, or yearly) Frequency of report (in what frequency report requests are expected) Volume of report (number of users expected to access this report in an hour). When the business analysis is complete, the technical team is responsible for analyzing the report for its technical feasibility. During this process, the team must identify the following factors: Data source system Source system security issues Source system performance issues Data availability in the source system Data concurrency Data consistency. When you've identified and documented all these factors, technical specification can begin.

A B2B REPORTING TAXONOMY

System management/operational reports Short-term decision-support reports Long-term decision-support reports Standard business partner reports Paid business partner reports Standard customer reports Paid customer reports Registered member reports.

One of the unique opportunities for a B2B e-marketplace service provider is to become the premier authority in providing market analysis information about goods and services associated with its partners. Analytic information about market dynamics, customer behavior, and pricing trends are undeniably the most importance service a B2B e-marketplace can render to its business partners and customers. Any such provider that ignores this fact will undoubtedly lose market share to those who can furnish these types of reports.

The Internet is a fast-moving environment where information changes by the minute, so the ability to provide information to customers and business partners at "the speed of thought" is a great asset. Thus, a B2B e-marketplace should not overlook the necessity of deploying an operational data store (ODS) and data warehouse to support its customer and partner needs. These systems, some of which are available as Internet-based platforms, always keep the importance of providing accurate, timely data in focus.

Report Categories

E-marketplace reporting requirements fall into eight different categories: system management/operational reports, short-term decision-support reports, long-term decision-support reports, standard business partner reports, paid business partner reports, standard customer reports, paid customer reports, and registered member subscription reports.

* System management/operational reports. The customers of this type of report are usually operational support staff members who manage the business and computer environment on a daily basis. These reports reflect the current atomic data in the operational and online systems; they are usually very detail-oriented (at the record operation level) and can help the staff analyze and identify operational problems. These reports are generated by the systems responsible for collecting and generating the data. As I discussed earlier, they can contain very sensitive information and therefore are not available for general public consumption.

You can produce these reports through a batch process that runs in the source system on a daily basis. The normal medium for generating this type of report is hard copy distributed to appropriate staff members, who can also request some of them during emergency situations. For example, you could generate reports that offer statistics on system activities in order to formulate system strategies and identify areas of improvement.

* Short-term decision-support reports. These are usually generated to help internal business decision makers assess business performance. These reports are either departmental or cross-departmental in nature. The source for a departmental report is usually a single system or source that supports departmental functions, such as a data mart. The cross-departmental reports usually span multiple systems and are used in comparisons containing multiple functional area data.

Departmental reports do not require any special consideration because their data source usually comprises one or two systems that are consistent in data and definitions. Barring any performance issues, you can usually obtain these reports from the source systems themselves. Example include financial reports that cross-reference employees (usually sales staff) in order to formulate compensation levels. In addition, an e-marketplace might be interested in generating reports that show the volume of business in dollars by geographical region.

Cross-departmental reports are much more complicated. The data obtained directly from these various systems can be perfectly valid and consistent within their respective system environments, but anytime you merge or cross-reference data between systems, the result can include invalid and inconsistent data. For this type of report, using an ODS data source -- where the data from various systems are already cross-validated and stabilized during data definition -- is a good idea.

An ODS-type data source, where all the corporate data is merged from definition through analysis, generates BI reports that are valid and consistent across the organization. For example, you could create customer support-staff reports that cross-reference CRM data with financial data in order to develop incentives for customers. A service provider could also use this type of report to formulate discounts or other incentives for customers based on the volume of business the customer is bringing into a certain service area.

* Long-term decision-support reports. Long-term business decision-support reports are usually analytic reports that cross reference data from all systems during a period of time (usually years) to assess past business performance. These reports are usually in a summarized form and are designed for corporate officers. They can also include business discovery-type reports that result from data mining mountains of corporate information.

This category of reports is best generated by a corporate data warehouse system and online analytic processing (OLAP) tools. A well-architected data warehouse system can provide invaluable information to long-term decision makers. For a B2B e-marketplace, this category of reports can be a potentially large revenue producer. For example, BI about customer behavior in a given market that is of great interest to business partners can be very valuable. The provider could use this type of report to identify the most successful branch of its offerings and allocate resources based on need. These reports can also be used to recruit new business partners or retain old ones.

* Standard business partner reports. In these environments, a relationship usually exists between the provider and various partner businesses. These partnerships are very valuable for all parties: The partners benefit from gaining e-customers who are interested in their goods and services, and the provider benefits by collecting information about these customers that it can then analyze and sell back to the partner businesses.

Depending on the level of partnership, partner businesses usually expect the provider to furnish them with regular reports of some kind in order to monitor the profitability of the partnership. For example, a business partner may request information about outstanding, unfulfilled orders (assuming the back-office functionality is provided by the service provider). These short-term reports address current business performance based on operational system data. But due to the potential volume of requests involved, operational systems may not be the best source. Again, a well-designed ODS is the ideal source for this kind of BI.

* Paid business partner reports. Providing standard reports to business partners is perfectly viable for a provider, but that doesn't mean it should give away valuable market information free of charge. Rather, these reports, which provide insight into market behavior, should be distributed on a subscription or paid-fee basis.

For example, a B2B e-marketplace service provider is in a strategic position to provide reports that might shed light on not only who its business partners' customers are, but who its industry customers are. A report that compares profiles of business partner customers with those of industry customers would be extremely valuable for business partners who are formulating their CRM strategies.

Any time information is sold for a fee, however, some type of liability is involved. To minimize that liability, the provider must ensure that the information involved is reasonably accurate. A report generated from an operational system may not provide these guarantees. An ODS system, however, can provide a reasonable guarantee that the distributed information is accurate.

The potential volume of request for these reports also make operational systems a poor choice for a data source. Instead, an ODS or data warehouse will greatly facilitate the production of this type of report without degrading the performance of any operational systems.

* Standard customer reports. One of the main marketing ploys to lure customers to your Web site is to provide information about the products in which the customer is interested. Similarly, e-marketplace customers are usually bulk buyers who are very keen to get pricing and specification information about products they buy. These customers are usually very well-educated buyers and demand information before going through with transactions. Thus, any e-marketplace interested in attracting customers must provide some type of query or reporting facility that must at least provide basic information about products, the market, and the B2B operating environment.

For example, a B2B service provider might want to make a set of reports available that can help customer who want to buy goods and services navigate B2B offerings. A price comparison report about goods and services bought retail vs. B2B, or a price comparison between buying goods and services in bulk vs. individual packages, may greatly influence the customer decision to conduct business through the provider. Giving customers reports about the business experiences of other customers can also be attractive.

Customers may well demand these reports in such high volume that a dedicated data source will be required. Again, an ODS will also help fulfill these types of reports quickly and efficiently.

* Paid customer reports. Aside from the standard customer reports that attract them to a B2B site, a set of reports must also be provided to retain their interest. These reports are normally analytic in nature and require enormous amounts of data that most customers are in no position to obtain. But a service provider is in a position to accumulate such data, and offering access to it on a payment basis can be a huge asset for retaining customers or attracting new ones. For example, the provider could offer reports on pricing trends in goods and services sold through its service. Because of its unique position in the supply chain, that provider could also give customers product specification and substitution information reports.

This type of report normally requires OLAP systems that can crunch volumes of data in a matter of seconds. Because the customers pay for these reports, the accuracy and timeliness of the data is of legal importance. Thus, you must verify the data in the system that produces them for consistency and accuracy.

* Registered member reports. Finally, any report that falls into any of the previously defined report categories should be available for delivery on a subscription basis. Having a subscription reporting system is a great asset to a provider because it generates revenue and is also a great marketing tool. Such subscription-based reports may incur high system overhead, so having an ODS or data warehouse system will streamline the process substantially.

These reports must be classified either as base reports or as premium reports. Base reports are available to all subscribers; premium reports are available only for a fee. A service provider could also formulate a packaged subscription that combines both kinds of reports for special subscription fee.

Delivery Format

Because by definition its users are removed from the source network environment and connectionless communication is prevalent, most, if not all, reports must be available in multiple formats. Customers must be able to view the report on their computer screens in WYSIWYG format and produce hard copies at their locations.

Two of the most widely used standards for electronic distribution of reports are HTML and Adobe's Portable Document Format (PDF). Both standards are common, but PDF format reporting is the preferred mechanism because of its formatting and printing capability. The PDF viewing component is widely available as a browser component and easily installed when needed. One big drawback, however, is the size of PDF files, which can present a problem during delivery through a slow connection. But these drawbacks can easily be overcome by the right compression mechanism and wider download bandwidth.

One of the fastest emerging standards in this area, however, is extensible markup language (XML). Virtually all software packages that operate in the Internet environment now support some form of XML parsing functionality. As customers and business partners of e-marketplaces familiarize themselves with their service offerings, they may soon want to capture data from the B2B reports and use them with their own analytic tools. Thus, having a reporting system that can provide XML-based report data will have enormous impact on retaining business partners and customers.

Final Report

An e-marketplace exists because sellers and buyers of goods and services agree to conduct their B2B transactions through a service provider. If that provider can't provide any value-added services in the form of analytic reporting, then no incentive exists for a customer to purchase, or business partners to sell, goods and services there.

Rate This Article Rating: 1 (best) 2 3 4 5 (worst) Comments: Optional e-mail address: