This article originally appeared on the BeyeNETWORK.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
In October of 2004, I wrote an in-depth research report for The Data Warehousing Institute (TDWI) on “Developing a BI Strategy for CRM/ERP Data.” Since then, this topic has come up repeatedly in working with both vendors and customers. Selecting a strategy for accessing and analyzing customer relationship management (CRM) and enterprise resource planning (ERP) data is not any easier now than it was when I wrote the TDWI report – if anything, it has become more complex.
Over the past few years, many independent third-party business intelligence (BI) vendors have announced connections between their tools and the CRM/ERP packaged applications and BI solutions offered by applications vendors. One of the main targets of these third-party offerings is SAP NetWeaver Business Intelligence (formerly know as SAP BW or the SAP Business Information Warehouse). SAP NetWeaver BI customers provide a fertile and large marketplace for BI vendors that provide connections and extensions to SAP BI. The result of these vendor announcements is that users of CRM/ERP packaged applications face a bewildering number of options when it comes to developing a BI strategy. Also, with business portals becoming the main interface for delivering information to business users, the selection process becomes even more complex because the BI strategy must also take into account the portal offerings from the application vendors.
A Business Intelligence Strategy for CRM/ERP Data
Although there are dozens of packaged application vendors, the marketplace is dominated by Oracle and SAP. Microsoft and its partners are, however, likely to become key players over the next few years.
Oracle’s packaged application and BI strategy is confusing given the recent acquisitions of PeopleSoft (which had already acquired J.D. Edwards) and Siebel. BI users, for example, have the option of using Oracle Daily Business Intelligence, PeopleSoft Enterprise Performance Management or the analytic applications from Siebel. It is clear, however, that a large component of Oracle’s future BI strategy will revolve around Oracle Fusion middleware, Siebel Analytics and the Oracle Portal. These three components are offered as a part of the Oracle Application Server.
SAP’s BI offering is a component of SAP NetWeaver, which includes an application server, business intelligence and data warehousing tools, a business portal, application integration software, and content management and collaboration tools. SAP has a similar strategy to Oracle in that it is providing a suite of analytical and collaboration products that are integrated with its application server and application integration software, which are based on a service-oriented architecture (SOA).
As organizations increase their use of packaged applications, they will be drawn toward the use of the BI offerings from their application vendor. This will be especially the case with line-of-business (LOB) groups who wish to remain autonomous and independent of central IT. At the enterprise level, organizations have the choice of avoiding, adopting or accommodating BI solutions from their applications vendor. The avoid strategy will be increasingly difficult to enforce given the current uptake of packaged solutions. Adopting an applications vendor as a single supplier will also be hard to do, because it is unlikely that the application vendor’s BI solution will satisfy enterprise-wide BI requirements.
Most companies will undoubtedly use an accommodate strategy as their enterprise-wide business intelligence approach, involving a mixture of BI products from both applications and third-party vendors. In some instances, the enterprise business intelligence solution will focus on the application vendor’s BI solution, with third-parties filling the gaps. In other cases, third-party products will be used at the enterprise level, and the application vendor’s BI solution will be used at the LOB level. Often, the decision to base the enterprise BI strategy on an application vendor’s BI solution is a political and an economic one, rather than a technical one.
One of the biggest factor’s in choosing a BI strategy is, of course, the needs of the business user. In general, LOB users who use an application vendor’s package for transaction processing will be happy to use the BI solution from the same vendor because they are familiar with that vendor’s application terminology and interface. The reverse is true for information workers who are familiar with third-party business intelligence products.
One selling point of third-party BI products is that they can be used to access and analyze both application package and legacy transaction data. In reality, however, few BI applications access both types of data because different groups usually control the data stores involved. Instead, it is more common to copy the data from the application package data warehouse (.e.g., a LOB data warehouse) to a data warehouse managed and accessed by third-party tools (e.g., an enterprise data warehouse), or vice versa.
A Portal Strategy for CRM/ERP Data
Third-party BI vendors sometimes offer an integrated portal interface to their products, but adoption of this approach is low because companies increasingly want to provide a single personalized interface that gives business users access to all of the business content and collaboration tools they need to do their jobs. For consumers of information, this interface will be a Web-based business portal; for producers of information, this interface may involve both a Web-based portal and desktop-based workgroup tools such as Microsoft Office.
For an enterprise portal, companies can choose between a portal offered by their application vendor (Oracle or SAP, for example) and a portal provided by their infrastructure vendor (BEA, IBM or Sun, for example). Oracle and SAP are, of course, both application and infrastructure vendors. This choice should take into account the increasing dominance of Microsoft Office and the Microsoft SharePoint portal at the workgroup level.
At the enterprise level, companies have the option of using an avoid, accommodate or adopt strategy with respect to the application vendor’s portal. The accommodate approach is likely to become the main option used. Here, the infrastructure vendor’s portal is used as an enterprise-wide portal, whereas the application vendor’s portal is employed for specific LOB transactional and BI applications. The enterprise portal will need to interoperate with workgroup environments involving Microsoft Office and Microsoft SharePoint. As the functionality and scalability of SharePoint improves, and as Microsoft and its partners increase their penetration of the applications market, it is likely that Microsoft SharePoint will also be used at the enterprise level. This, of course, depends on Microsoft’s ability to improve its sales and support model to handle enterprise-level customers.
Most Common Scenarios
In summary, at present the most common BI scenario for handling CRM/ERP data is likely to consist of an enterprise data warehouse built and accessed using third-party products and LOB data warehouses built using application vendor tools. For enterprise decision making, LOB data can be copied from the LOB data warehouse to the enterprise data warehouse. LOB data warehouses can be accessed using the BI tools from the applications vendor, and gaps in BI functionality filled by the third-party BI tools used to access the enterprise data warehouse.
The most common portal strategy for information consumers is to use an infrastructure vendor’s portal at the enterprise level and the application vendor’s portal at the LOB level. For information producers, the enterprise and LOB portals will be supplemented by workgroup tools such as Microsoft Office and Microsoft SharePoint.
Editor’s Note: Be sure to visit (and participate in) Colin’s blog on the Business Intelligence Network.