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.
| 
