As businesses grow, so does the amount of information they store. Customer demographics, accounting data, product information, human resources data, all contribute to the mass of information that companies collect. The tools and technologies used to interrogate that data and turn it into useful information are generally classed as "Business Intelligence" tools. Traditionally, the resulting output from these business intelligence tools was in the form of paper-based reports.
Most companies want to deliver the same information electronically in a dynamic form that can be further manipulated according to each individual's needs - the corporate intranet provides the perfect delivery mechanism for this type of business intelligence solution. First and foremost, it provides a low-cost alternative to purchasing and installing client software on each PC in your organization. Secondly, it also provides a distribution method for reports that you may want to share with your vendors, customers and other relevant business partners outside your organization, through an extranet or Internet site.
This article will guide you through the necessary steps needed to establish a system to deliver data to be used for competitive intelligence purposes to your team by means of a portal. It will discuss the following six basic phases behind the development of a portal for your competitive intelligence needs:
· Defining the Concept - What will the portal do for you?
Defining the Concept - What will the portal do for you?
Reports - Traditionally paper-based reports can be delivered online, with features like parameters, drill-down, record selection, etc. Usually does not provide a high degree of flexibility in terms of design or structure;
Queries - Either pre-defined or ad-hoc queries can provide users with method of interrogating their database and viewing the results. Queries are a good choice for users who quickly want to see this information but are not particularly worried about how the output looks;
OLAP Cubes - Online Analytic Processing (OLAP) cubes are data structures that are multi-dimensional and provide a structured, summarized view of the information held within a database. Traditionally used by managers (as it shows a higher-level view than reports or queries), OLAP cubes are usually presented in a dynamic user interface, sometimes called a "worksheet," that allows users to change dimensions, add filters, drill down/up, etc.
Scorecards - Scorecards are a collection of "nuggets" of information that measure a company's Key Performance Indicators (or KPI's). These nuggets can come in the form of queries, reports, dials, graphs, etc. and are generally designed to give an "at-a-glance" status of a particular KPI.
Once you have assessed a user's needs and determined what type of analysis they require, you can select one of the delivery methods above and get down to designing the object.
The easiest way to develop and communicate this concept is to create a prototype, or mock-up, of the report, query, output, etc. you wish to create and the Web pages or application that will deliver this information. You can use a word processor, a spreadsheet, or the low-tech option of pen and paper, but you should try to make the prototype of these objects and pages as complete as possible. This will help you later when you are trying to determine if the object that you want to create is feasible.
Sourcing the Data - Where is your information?
Armed with the database or file schema, the database or system administrator should be able to tell you exactly where the data is located. A common scenario is that the data you wish to include in your report or query may not exist yet. Your accounting system, for example, may not have the capability to track budgets. Therefore, trying to produce a report contrasting actual sales versus budget may be a problem.
You should also keep an eye out for any fields that need to be calculated and determine whether those calculations should occur on the database level or within your object. Most CI tools include their own formula language and function set, but you may want to consider pushing heavy processing back to the database where it belongs.
Creating the Design - What will the portal look like?
During the design phase, you want to revisit your prototypes and, given what you now know about the database, indicate which of the fields on your reports or queries are going to come from the database, which are going to be calculated, and what formulas are to be used in those calculations.
It is also at this time you will want to start creating the design of the Website or application itself, given what you know about the tool set. It is important to note that this part of the process does not involve any actual development tools - you are only creating the design of the site at this point. This phase will frequently involve the creation of story-boards and diagrams to indicate the look and feel of the site and the flow of information delivery.
Armed with the user's requirements and the design you have created, your development team should have no problem creating the portal you require.
Select the Right CI Tool - Which tool is the right one?
When looking at CI tools, you should consider the following questions:
· Can it deliver the information we require?
To answer these questions and discuss concerns, speak with other companies or developers who have created a solution using these tools and benefit from their experience and expertise. Go outside of the reference sites the vendor provides and try to find a developer willing to give you the low-down on what features worked, what didn't, etc.
Developing and Testing the Design - How do you evaluate?
Once the developers have created a beta of your solution, you will need to test the site and the objects within against your original design for acceptance and scalability. Note any performance issues and revisit your object, page or application design to see if you can make any performance enhancements. If you have created objects that prompt the user for a start and end date, try entering bad dates, the same date, or even some text in those prompts. You need to be prepared to handle any situation that a user may encounter.
Deploying and Operating the Report - How will it be used?
Will users want to export the information contained for further manipulation?
How does the information design translate when you export to Microsoft Excel or Word? Try to export the information yourself-you may need to revisit your report design based on the results of your exporting attempts.
Will users be able to modify the objects you have created? Are your formulas, naming, and coding conventions easy to follow? Again, you may need to modify your design based on these answers.
Someone once said that "a project is not over until the user is happy, and they are never happy." While a bit pessimistic, there is some truth to that saying. While you may think you have covered all of the user's needs, there may be aspects you have not anticipated. Use this deployment time as an opportunity to listen to your user's comments and plan for additional features or functionality that they require. Finally, with your solution in production, you will need to monitor the site or application to ensure that it performs as expected and that the information represented is still relevant.
By following the steps outlined in this article and staying focused on delivering the information users require, you can create a portal that can add real value by helping your users make more well-informed decisions every day.
David G. McAmis is a freelance writer living and working in Sydney, Australia. His work has appeared in numerous computer magazines and trade journals. He has traveled the world educating developers and end users on the benefits of business intelligence and information management. David can be reached at firstname.lastname@example.org .
This article was originally featured at www.competia.com in June 2001, and is reprinted with permission. Competia Online is a production of Competia Inc.