|
Page 1 of 3
By Info-Tech Research Group
A significant number of organizations implement Business Intelligence (BI) suites to deal with reporting demands when more cost effective and less risky measures will fit the bill. Often, the request for a BI solution comes from business partners with relatively simple reporting needs who think they need BI to gain competitive advantage.
Giving in to requests without a solid business case can be risky: a large number of projects go over budget and timeline expectations only to be resisted by end users. BI can have huge benefits when applied in the right instance, but when it comes to basic reporting, most organizations should consider their alternatives first.
Key Considerations
BI projects are renowned for high costs, exploding timelines, and low success. Recent Info-Tech survey data on BI shows that one in three BI projects exceeds cost and time estimates. Few enterprises, especially those in the SMB space, can afford to absorb such costs. Add the obvious opportunity cost of investing that money elsewhere and the situation only grows worse. Even successfully implemented solutions can be quite costly, if they are not leveraged effectively. Against this backdrop, implementing BI as a means of automating reporting or making users self-sufficient can be unwise when there are much safer and cheaper options available that have a quicker time to market.
Five Reporting Options
There is more than one way to solve reporting problems, such as increasing demand for new reports. Including BI, there are five options that IT managers have at their disposal when looking to generate reports for end users. They are:
1. In-application reporting.
2. Spreadsheets.
3. Custom Web reports.
4. Commercial reporting tools.
5. BI suites.
A careful evaluation of the opportunities and risks associated with each approach is the first step away from the BI precipice and towards a viable enterprise reporting solution.
In-Application Reporting
Most non-BI enterprise applications have fairly robust reporting capabilities built into the application or have reporting modules available for additional licensing costs. These in-application reporting tools are useful when business users require access to data housed in the native database for the solution. Many enterprise apps also have canned reports. For example, most enterprise resource planning (ERP) applications are able to report on accounts receivable, accounts payable, and so on.
- These applications also have limited customizability and restrict the ability of end users to manipulate the data for analytical purposes. Any custom work requires a developer that has application specific knowledge. Adding new reports or changing existing ones will, therefore, increase development costs. IT managers must also be careful not to impact performance of the application. As reporting demands increase, performance of the application will suffer.
Spreadsheets
Spreadsheets are by far the most common reporting tool. Spreadsheet utilities, like Excel, are familiar to most business users and almost all organizations have the tool available. Spreadsheets offer a high degree of customization within a tabular format and provide for some analytical capabilities, such as pivot tables and modest statistical analysis.
The downside to spreadsheets is that each report must be built from scratch and, as a result, data is not readily accessible except by more sophisticated users. Further, spreadsheets represent a risk to the organization from a data security and data integrity perspective. Spreadsheet sharing is not easily controlled, and data is readily corrupted due to inadvertent or malicious changes. Also, the cost for developing the reports increases with demand. Scalability and data consistency can become issues as information silos appear in growing businesses. This phenomenon is known as "spreadsheet sprawl."
Custom Reports
In-house report development tools can provide a cost effective and more secure alternative. Consider Web development tools as an example. Many enterprises already have Web development capabilities in-house. Using Web services to report on data allows Web administrators to control data access. From a design perspective, Web tools enable much richer graphical representations of enterprise data and free designers from the inherent limitations of the spreadsheet format. Furthermore, Web reports are easily distributed as Web pages.
These advantages, however, do result in increased development costs. Developers need to design both the presentation layer and hand code the links to the requisite databases. As with spreadsheets, increases in the demand for new reports can also increase development costs. Like spreadsheets, this approach may not be cost-effectively scalable for organizations with growing reporting demands.
Formal Reporting Tools
Commercial reporting tools, like Crystal Reports or iDashboard are designed specifically for report creation. They enable pixel perfect reports with a variety of prebuilt rich graphical representation formats and a point and click design. Newer tools enable the creation of interactive reports so that users can sort, filter, and drill-down data. Tools have varying degrees of flexibility for the reformatting of reports. They also enable users to manipulate data parameters without re-querying the database to refresh reports, and built-in data services provide for flexible extraction of most common data sources and types (e.g. Native, XML, ODBC, Web services and OLAP). Some additional functionalities include:
- Multilingual support.
- Embeddable reports.
- Web services capabilities.
End users can also be trained to use the tools themselves, thereby decreasing development costs for IT, but there will be some expense involved for training. Point and click report design also speeds up the time to results.
Although reporting tools that produce interactive reports can reduce dependence on IT for report development, in many cases new reports must be built and the application supported and maintained. As a result, organizations need to have developers who are familiar with both the reporting tool and the databases that will be reported on. Reports require significant coding for integration with databases, which requires intimate knowledge of data field names that are not presented in user friendly formats. This process is made easier by built-in data services, but not completely.
Further, directly accessing databases can still create performance issues for source systems. The cost of supporting the solution increases with the demand for new reports due to FTE allocation for report development. These are still static reports that only offer point-in-time views of the business and can require rebuilding. Licensing fees and maintenance and support represent additional costs that are not present with the earlier approaches.
BI Suites
From a basic reporting perspective, BI solutions represent a significant advance over reporting tools, enabling users to directly manipulate data from a single GUI. In addition to possessing all the capabilities of professional report writers, BI tools have flexible APIs and SDKs enabling integration with a wide variety of applications and data sources providing a "single version of the truth." They also have data access and security restrictions to databases and keep data trail records for audit purposes.
From the end user perspective, one of the most significant advantages of BI solutions is the use of a metadata layer and business logic layer to translate database field names into usable formats (e.g. net revenue, daily sales etc.), that preserve data lineage within the GUI. As a result, users are also empowered to perform data manipulations like merge, join, filter and drill-down and create ad hoc queries and reports. As with reporting tools, self-sufficient users do reduce IT development costs.
The main costs associated with a BI solution are:
- Licensing.
- Data management.
- Implementation and configuration costs.
- Maintenance and support.
- End user training.
The complexity associated with BI implementations has led to a significant number of failed projects. The potential risk for project failure should not be underestimated. The largest barrier to a successful BI implementation, however, is still end user adoption. Any proposed gains from a self-sufficient user base can easily be lost if users aren't trained and encouraged (ideally by senior management) to adopt the solution.
|
