[an error occurred while processing this directive]
[an error occurred while processing this directive]
|
|
|
Clients must create a checklist of required/desired features surrounding analytics (and insist that many of these capabilities are demonstrated during scripted demos), including the following: Data model. The data model should be published as a series of entity relationship diagrams. If some of the underlying tables are not transparent (e.g., SAP's pooled and clustered tables), a data dictionary should be available that offers a transparent view of the underlying data. Moreover, the data dictionary must be usable both by the vendor's query/reporting tools and third-party tools. Operational data store. Many applications are execution-heavy (e.g., accounts payable) and, as such, it is advantageous to perform near-real-time data analysis away from the production instance. Therefore, the application should support an event-driven approach to deliver near-real-time data to an operational data store. As a secondary advantage, event-driven data transfer is also invaluable to support supply chain visibility/event management. Application-centered data warehouse. The application should contain aggregate tables as well as the ability to spawn OLAP-style data marts to support multidimensional analysis. Each data mart should be published, as well as a list of standard queries/reports available against each OLAP cube.
Production report writers. Most vendors still provide proprietary report writers, and embedded production report writers (e.g., PeopleSoft, Crystal Decisions) offer a competitive advantage. The vendor must demonstrate that proprietary report writers are relatively easy to use and reports can be easily modified. In addition, the vendor should provide a report catalog to house off-the-shelf and one-off developed reports. We note the nascent relationship between SAP and Crystal Decisions. However, we believe clients are likely to be using SAP's ABAP report writer in part or completely through 2004. Query and analysis. The vendor must offer a comprehensible approach for ad hoc queries. Modern requirements should include Web-based queries, with the delivery of HTML pages that have hot spots for further drill-down. Moreover, hierarchical decompositions should be straightforward and consistent with the hierarchies the vendor offers (e.g., organization charts, general ledger charts of accounts, bill of materials). Handcrafted drill-downs are tedious. As with production reporting, vendors that offer third-party tools (e.g., JD Edwards/MicroStrategy) have a competitive advantage. We believe third-party query tools will outpace ERP-centered query tools (e.g., usability, deeper analytics), and ERP vendors must be partner-friendly to enable easy access to aggregate tables (or cubes) as well as back-end transaction data. Report catalog/report serving. Although some vendors may offer a catalog of production reports, we find that this capability rarely extends to analytical applications and business queries. Clients should "encourage" their application vendors to encapsulate a report catalog to include production reports, sample queries, analytical applications, and customizations made during implementation. Moreover, the capability to burst and serve reports electronically should exist, and it should be consistent with individuals' security privileges (identified by role). Portals and analytics. The vendor should provide a role-based portal capability that provides easy access to reports/queries based on roles. A more sophisticated approach would also empower users to access the underlying data model directly, based on their security privileges. In addition, the portal must support trading partner roles (e.g., supplier, indirect sales channel). We note that data visibility (e.g., inventory, order visibility) is relatively simple to deliver and a mandatory first step in trading partner collaboration. Analytics and methodology. The implementation of major business applications requires consulting both from the vendor's professional services group as well as outside systems integrators. In general, clients do well to insist on a methodological approach consistent with the vendor's published methodology. As such, we find little to support steady-state query and reporting. In other words, the methodology should help describe an approach for how IT staff members can develop service-level agreements with their internal customer base, which encourages business-driven reports and queries while it simultaneously promotes a subclass of those analyses to production. "There's a data warehouse world out there." Most clients rely on application-centered analytics as well as their own data warehouse/data mart architecture. In general, it makes more sense to export data from a business application (to a homegrown data warehouse) than to import data into the business application. An 80/20 rule can be applied. That is, if 80 percent of the required data sits in the business application, import is encouraged; otherwise, data should be exported. Yet, few application vendors offer sophisticated extraction, transformation, and loading capabilities to third-party data stores, or embed third-party extraction, transformation, and loading tools (application vendors can sell more seats if they attach more users to their applications). Business impact: Intelligent analysis of business data supports effective internal decision making as well as collaborative commerce. Bottom line:
The suite swell of analytics: Application delivery strategies By Barry Wilderman First published by META Group on April 2, 2002
[an error occurred while processing this directive]
[an error occurred while processing this directive] |
[an error occurred while processing this directive]
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||