BI Tool

This is a sources sought notice issued for market research purposes only. THIS IS NOT A REQUEST FOR A PROPOSAL. This Sources Sought Notice is for information and planning purposes only and shall not be construed as a solicitation or as an obligation on the part of the Mine Safety and Health Administration (MSHA). The purpose of this notice is to identify vendors that are interested in and capable of performing the work and providing the products described herein. MSHA will not pay for the preparation of any information submitted. As a result of this Sources Sought, MSHA may issue a solicitation for the services or products contained in this notice. Any such solicitation will be issued only to those vendors responding to this notice. There is no solicitation available at this time. However, should such a requirement arise, no basis for claims against MSHA shall arise as a result of a response to this Sources Sought or the MSHA's use of such information as either part of our evaluation process or in developing specifications for any subsequent requirement The Mine Safety and Health Administration (MSHA) is seeking sources for a Business Intelligence (BI) tool that is easy to use and powerful enough to run complex queries. MSHA is responsible for collecting mining data on our nation's mines and miners. To do so MSHA uses an Oracle Data Warehouse to store the data collected and a graphical user interface to pull information as needed. MSHA currently has approximately 25 gigabytes of data structured and stored in the Oracle Data Warehouse. The data has been tailored by MSHA Database Administrators in to several customized models and is assessable using the user interface. The user interface is a very powerful complex tool that requires extensive knowledge to complete difficult Ad Hoc request for data. Therefore, only a select few individuals are capable of using the user interface correctly and to its full potential. Following are the mandatory and desirable features of the BI tool that MSHA is seeking. Requirements Mandatory: 1. Reporting a. Output Formats i. Charts & Graphs ii. Crosstab/Pivot Table iii. "Dashboard" Capability iv. Excel Integration v. PowerPoint Integration vi. PDF vii. Plain Text (TAB, CSV, TXT) b. Copy and Paste Formats i. Excel ii. Access iii. Delimited Files c. Report Distribution i. Scheduled report generation ii. Broadcast Email (Bursting) iii. Email d. Report Definition i. Conditional Parameters 1. The ability to define one set of parameter contingent on the values of a second set of parameters. ii. Scheduling Dynamic Date Ranges 1. Reports should be able to be clearly defined as "Current Month" or "Last Closed Month" or "Prior Month" without entering a date value as a function. iii. Dynamic sorting based on Column Headings 1. Simply click on a column heading to sort the data by that column. iv. Component Re-Use 1. Streamlines the development and makes the interface more consistent if components can be re-used across multiple reports. v. WYSIWYG Definition 1. Facilitates report development vi. Parameter based reporting 1. Allows for a single report to accommodate multiple purposes if parameters can be used to control the data selection and reporting process. vii. Automatic Drill down within a hierarchy 1. Facilitates report development if the report "understands" the data relationships, and facilitates the user's acceptance if the report is "active". viii. Robust support of analytical functions ix. Ability to define / create custom functions x. Ease of ad hoc query development by end users xi. Ease of turning "ad hoc" reports into "canned" reports xii. Traditional programming support (APIs) Does the solution have development APIs for "java", "C", etc for very complex reporting? e. Security i. Active Directory Integration ii. Auditing of Access iii. Ability to restrict access data elements (tables, rows and/or columns) to a given user group. iv. Ability to restrict access to "canned" reports to a given user group. 2. Collaboration a. Ability to share user defined reports 3. Ease of Administration a. Single interface b. Security i. Single Security model 1. All components of the tool works off a single security model. ii. Integration with Active Directory for authentication 1. Active Directory integration allows all security processing to be centralized. iii. Direct Integration with custom-developed database role-based security for data-level query and report permissions (see 1.d.iii above.) 1. This allows administration of user permissions to be centralized. c. Single meta-data management i. Common meta-data for all components ii. Easily accessible access to meta-data components (search/sort/etc) iii. Tight database integration 4. Ease of Integration a. Platform Support i. Windows b. Database Support i. Oracle ii. ODBC iii. SQL Server c. Browser Support i. Internet Explorer ii. Firefox d. Monitoring i. Report Utilization 1. How frequently is a report used? ii. Report Efficiency 1. How long does a given report take? iii. User Utilization 1. What users are running which reports? e. SDLC Process Compliance i. Allow for a full life cycle development cycle with strong delineation of development, test and production systems, with easy (but controlled) promotions between the systems. Must fully support an external repository. 5. Performance a. N-Tiered client support i. Zero client foot print for reporting 1. All reporting occurs on server. b. Ability to scale the application server engine across multiple servers. Desirable: 1. Reporting a. Output Formats i. Mapping (Spatial) b. Report Distribution i. Dynamic lists based on data value ii. Self service list enrollment iii. Web Personalization iv. Offline Reporting and Analysis c. Dynamic Linking i. Excel ii. Access iii. Delimited Files d. Report Definition i. API access for Job Control features ii. Multi-lingual support iii. OLAP support 1. Highly efficient reporting based on "cubes" 2. Ease of Administration a. Security i. Integration with non-AD Enterprise Directory for authentication 1. Enterprise Directory integration allows all security processing to be centralized. 3. Ease of Integration a. Browser Support i. Opera, et al. 4. Performance a. Zero client foot print for development i. All development occurs on server b. Zero client foot print for administration i. All administration occurs on the server With this notice, MSHA is conducting market research to determine the types of commercial technical solutions that can accommodate meet these requirements. MSHA is not currently interested in solutions that require significant or ground-up software development effort, although it is understood that some customization of any commercial product may be required. All interested parties are requested to respond to this notice by 5:00PM EDT. Tuesday, April 7, 2009. Responses to this sources sought notice should include a description of the proposed product and its capability in the areas specified; the types of hardware platforms that are supported; and examples of implementations using the product. Responses to this sources sought notice will make up the solicitation mailing list for any subsequent solicitation resulting from this notice. Vendors who do not respond to this notice will not receive any subsequent solicitation. This is a sources sought notice for informational purposes only and is not a request for proposals. NO SOLICITATION FOR THESE SERVICES EXISTS. Send completed documentation to Robert Beaty at MSHA, 1100 Wilson Blvd, Arlington VA, 22209. Send one copies of marketing brochures describing your organization and your product offerings in the areas of BI Tools Electronic responses are preferred and may be submitted to the Contracting Officer at beaty.robert@dol.gov. Questions regarding this notice should be forwarded, electronically, to the Contracting Officer at the above email address.