As businesses grow, so does the amount of information they store and the need for business intelligence. 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?
· Sourcing the Data - Where is your information?
· Creating the Design - What will the portal look like?
· Selecting the Right Tool - Which tool is the right one?
· Developing and Testing The Design - How do you evaluate?
· Deploying and Operating - How will it be used?
Defining the Concept - What will the portal do for you?
Before you can actually sit down in front of a computer and create a report, query, Web page, etc. you must first have some idea or concept of what you want the final output to look like. The information starts with the user-you will need to interview the users of your prospective solution to determine what information they need and what form they would like it in. When working with business intelligence tools, there are a number of different structures that can be used to deliver information to users, including:
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?
With a prototype in hand, the next step is to determine where the data for your solution actually resides. Is it stored in a database, a log file, or a mainframe file? After you have determined the general location, you need to find the database or system administrator responsible for that particular database or system.
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?
After creating a prototype, determining your data source and selecting the right toolset, the next step is to design the objects that will be a part of your CI solution. At this point, you are probably asking yourself if this is where you get to use the design tools? The answer is no. The best report, query or cube design is one that is completed first on paper and is then recreated using your tool of choice.
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?
There are a number of competitive intelligence tools on the market that can help you create a Web-based CI solution. Each of the vendors in this space has their own custom Web solution, whether it be their own portal or Web application, they have all recognized the need for Web-based delivery.
When looking at CI tools, you should consider the following questions:
· Can it deliver the information we require?
· Is the tool Web-integrated?
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?
With the design completed on paper, it is time to open the design tools and get down to business. After you have laid the groundwork, the actual object and portal design process should be quick and simple.
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?
As a final step in the process, you need to consider how your solution is going to be deployed and used. Given the wealth of information provided and its usefulness, ask yourself these questions:
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.
Conclusion
Many organizations think that creating a competitive intelligence solution stops when you hand the information to a user. To the contrary, the design process should be ongoing throughout the life cycle of the solution and you should continually analyze ways to enhance the information presented and to add additional value to the data.
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.
About the Author: 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.
0 comments:
Posting Komentar