The BI Foundation
First, you must ensure you have established the right BI Foundation consisting of:
The BI Foundation
First, you must ensure you have established the right BI Foundation consisting of:
- Business Intelligence Team (the right People)
- Business Intelligence Standards (the right Policies and Procedures)
- Business Intelligence Infrastructure (the right Technology and Data)
Start at the top (people) and work your way down (tools). Too many companies start first with the BI technology and expect to be successful. They buy a box of software and just hand it to the college intern.
Imagine that you have a home improvement project, so you purchase a hammer, nails, and wood. The outcome of a project using those tools will be very different depending to whom you give that material: a twelve-year old child or a twelve-year carpentry expert. Even if you select an expert carpenter to do the work, if you provide no guidance as to what to build your end result will just be a surprise.
When I list those three critical layers, I am making a big assumption. I am guessing that your organization understands the value of Business Intelligence software, has a strategic reason for implementing it, and has the organizational maturity to pull it off successfully. Some organizations are excited about the idea but do not have the capability to create or support a BI infrastructure.
Your Organizational Readiness
To evaluate your readiness, consider the following checklist:
- Strategic understanding
- Executive sponsorship
- Budget approved
- Technology implemented
- Key metrics formally identified and calculations codified
- Common business language codified (e.g., “profit” means the same to everybody)
- Data available
- Resources available (people, environment, etc.)
The BI Dashboard Layers
At a very high level, a BI Dashboard consists of three main layers:
- Operational Systems
- Reporting Repository
- User Presentation
The critical data is being maintained in your secure operational systems. These are the transactional details that drive your organization. You rarely use BI tools directly against this raw data. Instead, you need to extract the information, transform it for reporting, and load it into the Reporting Repository. For details on why this is so important, see my earlier blog posting.
Your Reporting Repository should be designed for quality, speed, and historical trending. In addition to your reporting data, you need to consider Master Data Management.
- Executive sponsor
- Project leader
- Application and BI subject matter experts
- DBA, network administrator, WebFOCUS administrator, security expert
- WebFOCUS application developers
Do you wonder what a great WebFOCUS application developer looks like? See my earlier blog posting.
BI Initiative Expectations
- Time and cost expectations
- Functionality expectations (features, user presentation types)
- Ease of use of the BI application
- Ease of application development
- Deadlines (firm/drop-dead or flexible/nice-to-have?)
- Versioned release schedule
BI Initiative Logistics
- Workspaces
- Security (network userids, door cards, VPN/Citrix keys, etc.)
- Location (address, contact, security procedures)
- Working hours
- Policies on working remotely
- Platforms
- Complementary technologies (e.g., ETL)
- WebFOCUS release
- WebFOCUS images (Development, Test, Production QA, Production, Disaster Recovery)
- Automated backup routines
- Web tier (web server, Java app server)
- Load balancing, fail-over
- Security methods (e,g., Active Directory, SiteMinder, MRE, etc.)
- Databases
- Data access methods (metadata, tables/views, stored procedures, SQL pass-through)
- Automated information delivery (Distribution Server and ReportCaster)
WebFOCUS Licensed Software
Consider the different WebFOCUS licenses that you might need for the project, both server and client:
- On-demand access through the web browser (“pull,” WebFOCUS Report Servers)
- MRE licenses
- Automated Information Delivery (“push,” Distribution Server, ReportCaster, Report Library)
- Deferred execution
- Developer Studio copies
- Adapters (data, application, web services, etc.)
- Add-ons (Magnify, InfoAssist, Active Reports, R Stat, ESRI, etc.)
- Methodology (e.g., none, waterfall, RUP, agile, etc.)
- Versioned release schedule (phased rollout)
- Source code management (e.g., none, Subversion, etc.)
- Quality assurance (e.g., none, Mercury, Bugzilla, etc.)
- Requirements definition (e.g., use cases, mockups)
- Status meetings, conference calls, reporting
- Promotion schedules
- Naming standards (libraries, programs, etc.)
- Server backup/recovery procedures
- BI Dashboard
- Banner images
- Tab Breakouts
- Common tab for dashboard release information and alerts
- Common alert subsystem
- Filters
- Static parameter definition
- Dynamic parameter population routines and MDM data
- Cascading stylesheets
- Common JavaScript routines (cookie processing, launch WebFOCUS, edit validations, date logic, toggle logic to “hide” and “show” filters)
Of course, with a BI Dashboard you want to display dynamic reports. Consider the following common elements for which you want reusable widgets to reduce the time and cost of the project:
- Hierarchy drill-down logic
- Standard headings
- Standard footings (parameter descriptions)
- Export to PDF and Excel
- Security (user entitlement rules)
- Alerts and Messages
- Back navigation
- Standard stylesheet
- Common No-Data logic
- Common Error logic
- Common Documentation block
- Dynamic legends
- Common browser window target logic
- Establish color schemes, logos, fonts, reporting standards before developing
- Display descriptions, not codes (pass codes for WHERE selections)
- Use consistent formatting, look and feel
- Recommend visualization (peer graphics, stoplights, images)
- Use different formatting for online viewing (HTML), printing (PDF), and analysis (Excel)
- Should you use Active Reports?
- Are there plans for mobile BI or a universal front-end?
- Is there a desire for sizzle (maps, Flash/Flex, etc.) or practical functionality?
If you do not have the proper data in place, then building reports is difficult (or a waste of time and money). For the Reporting Repository, you need to consider the following:
- Reporting Repository population routines (initial load and ongoing incremental loads)
- Master Data Management creation, load, and maintenance
- Scheduled batch jobs
I hope this checklist provides you with an intelligent approach for your WebFOCUS BI Dashboard initiative and enables you to be successful.
If I can be of service, just let me know.