CSTARS Replacement RFI

D -- This Request for Information (RFI) is issued to survey the commercial market for potential alternate Commercial-Off-the-Shelf (COTS) solutions to replace the current Commerce STandard Acquisition and Reporting System (CSTARS). General Information Document Type: Sources Sought Notice Solicitation Number: DOC-CSTARS-RFI Posted Date: August 11, 2008 Original Response Date: August 25, 2008 Current Response Date: August 25, 2008 Archive Date: Aug 15, 2009 Classification Code: D -- Information technology services, including telecommunications services NAICS Code: 511210 – Software Publishers Contracting Office Address: U.S. Department of Commerce (DOC) Office of Acquisition Management (OAM) Commerce Acquisition Systems Division (CASD) 14th Street and Constitution Avenue NW, Suite 6060 Washington, DC 20230 This is not a solicitation for proposals Request for Information for a Web-based Acquisition System THIS IS A REQUEST FOR INFORMATION (RFI) ONLY – Solicitations are not available at this time. Requests for a solicitation will not receive a response. This notice does not constitute a commitment by the United States Government. All response and response contents to this RFI will be considered information only and will not be binding on the parties. Contractors responding to this request will not be obligated to provide the services described herein and it is understood by the United States Government that the costs provided as a result of this request are “best” estimates only. All information submitted in response to this announcement is voluntary; the United States Government will not pay for information requested nor will it compensate any respondent for any cost incurred in developing information provided to the United States government. VENDOR CONFERENCE: DOC will host a vendor conference on Thursday August 14, 2008 from 1:30 p.m. to 3:00 p.m. for the purpose of answering questions regarding this RFI. The conference will be held in Room 1414 of the DOC Headquarters located at the intersection of 14th Street NW and Constitution Avenue in Washington, D.C. To attend, please contact Brian Wolfe, 202-482-1876 not later than noon on Thursday August 14th. The Federal Triangle Metro Station is only one block away if you walk through the Reagan Building. ATTACHMENTS: Please note there are two attachments with this notice. One, RFI.doc, is a Microsoft Word 2003 copy of this notice that includes a drawing of the CSTARS ORSI architecture. The other, DOC Pricing RFI.xls, is a Microsoft Excel 2003 spreadsheet for entering pricing information. REQUEST FOR INFORMATION: The U.S. Department of Commerce is seeking sources, product capability information and pricing information to support a business case and budget for a new enterprise-wide web-based procurement system that is integrated with the Commerce Core Financial System (CFS). The focus is to take advantage of advancements in technology while benefiting from competitive industry trends. In its current state, the Commerce Acquisition System Environment consists of the following: • Commerce Standard Acquisition Reporting System (CSTARS) i.e., CACI Federal, Inc. Comprizon.Buy (C.Buy) contract writing and contract information system • CACI Federal Inc., Comprizon.Request (C.Request) requisitioning system for placing procurement requests • Obligation and Requisition Standard Interface (ORSI), the interface to the DOC Core Financial System (CFS) • Enterprise Acquisition Reporting System (EARS), the DOC procurement data warehouse DOC has approximately 500 users employing the C.Buy procurement software, 4000 users employing the C.Request requisitioning software and 50 users employing the EARS procurement data warehouse. Commerce currently employs the Comprizon.Buy product from CACI Federal, Inc. as the contract writing, contract management and contract information system portion of CSTARS. This product is based on client-server technology and has ended its COTS product life. The contract information system portion of this product does not provide robust data collection and reporting which necessitates the EARS application described in paragraphs below. Currently there are four production instances of Comprizon.Buy deployed at Commerce. The fours instances of the application, one each for the Office of the Secretary (OS), National Oceanic and Atmospheric Administration (NOAA), National Institute of Standards and Technology (NIST) and the Census Bureau. The Office of Computer Services (OCS) in Springfield, VA hosts acquisition data for Census, OS, and NOAA. OCS provides each bureau with their own environment that includes a separate instance of the CSTARS application and Oracle database. Although also using CSTARS, NIST operates and maintains a separate instance at their Gaithersburg, MD offices. Collectively, this means that CTARS is currently located physically at two locations, Springfield and Gaithersburg. The objective is to migrate to one production instance servicing all four bureaus. However, the single instance must interface with three instances of the Core Financial System (CFS) located at Census, in Suitland, MD; NOAA, in Germantown, MD; and NIST, in Gaithersburg, MD. The NIST instance also services OS. The Patent and Trademark Office (PTO) employs the Momentum finance and procurement system and is not in scope of this new enterprise-wide effort. Commerce also employs the CACI Comprizon.Request requisitioning system which is still supported by the vendor as a COTS product. If this system can be retained in the new system, there may be advantages to the Department and this information would be useful to include in a response to this RFI. While each bureau's data is currently stored in disparate databases, DoC is utilizing a data warehouse solution – Enterprise Acquisition Reporting System (EARS) -- that provides for enterprise-wide reporting capabilities. EARS employs the SAS Enterprise Business Intelligence (EBI) Suite to create canned and ad hoc procurement reports. The data for these reports are loaded from an Oracle data warehouse using SAS Extract, Transform & Load (ETL) software. This provides a more robust query tool than is available from the current Comprizon.Buy system. While CSTARS is currently implemented in a client/server environment, it utilizes Citrix Metaframe as an application server. Citrix provides increases system efficiency by shifting most of the processing from the local client to the application server. All application logic executes on the server and only screen updates (i.e. “screen images”), mouse movements and keystrokes are transmitted via Citrix. This reduces the amount of data transferred between the client and server, thus, alleviating potential network bandwidth issues. Like all other government agencies, DoC is required to integrate certain components of their acquisition systems with components of the federal Integrated Acquisition Environment (IAE). Information regarding the IAE is available at http://egov.gsa.gov. At a minimum, the new DOC acquisition system must be interfaced to FedBizOpps, Central Contractor Registry (CCR) and Federal Procurement Data System – Next Generation (FPDS-NG). The current CACI Comprizon.Buy system currently provides this functionality which must be retained. Financial Interface In 2006, the DoC Acquisition community implemented an interface to the DoC financial system, called the Core Financial System (CFS). This interface is called the Obligation & Requisition Standard Interface (ORSI). ORSI is designed, developed, deployed as a standard interface between CSTARS and the Department’s Core Financial System (CFS). ORSI includes an interface for requisitions, obligations, and non-Central Contractor Registration (CCR) vendors. This interface has a major impact on existing procurement and finance business processes at the Bureaus. Implementation of ORSI included new processing methods, the elimination of some manual entry, and increased system conformity. The CSTARS ORSI deployment consisted of separate deployment activities at each of the four Bureaus (Census, NIST, NOAA, and OS) and OCS. Each of these locations link via existing connections using TIBCO (the Department-wide EAI tool) and Java Messaging Service (JMS) queues. OBJECTIVES: 1. One production instance of an enterprise-wide procurement system 2. Integrated with three instances of the CFS finance system: continues to provide accurate vendor and account code data, real time financial commitments and obligations along with improved payment processing (including reconciliation, receipts, invoicing and payment data) 3. Modern one-stop-shop web-based technology: will provide a web-based central point for all users, vendors and contractors to communicate with the Department 4. Intuitive interface: user-friendly in that it decreases the need for training 5. Secure: meets all Federal and agency-wide security policies specifically the DoC Office of IT Policy and Planning guidelines 6. One acquisition system to handle all end-to-end lifecycle activities: streamlines and standardizes business processes and all acquisition activities by utilizing a modernized, integrated system 7. Based on Commercial, Off-the-Shelf (COTS) products: mature, best of breed products provide a solution that is based on best practices 8. Consolidated acquisition data: continues to provide improved reporting capabilities by centralizing data repositories 9. Compliant with all federal legislation and mandates: meets all legislative requirements while leveraging existing e-Gov resources 10. Improve performance and increase efficiencies: improvements in the quality or timeliness of acquisition processing 11. Migrate existing DOC procurement data to the new system to the maximum extent practicable Functional Requirements 1 General 1.1 The solution shall provide a web-based user interface, support single entry and re-use of data and provide a flexible means of accessing the system and managing data. 1.2 The solution shall enable certain items to be configurable by authorized users without requiring changes to the software (e.g., password length, username convention, PIID number, etc.). 1.3 The solution shall provide automated functionality to establish and maintain tables, business rules, and other agency-defined features. 1.4 The solution shall associate related acquisition documents and allows users to bring forward and re-use data entered in a previous process in any subsequent process without requiring re-entry. 2 Document Numbering 2.1 The solution shall provide flexible, user-definable document numbering capabilities for all procurement document types consistent with the requirements of the Integrated Acquisition Environment (IAE) component use. 2.2 The solution shall capture a unique system-generated or agency-assigned document number on all acquisition documents. 2.3 The solution shall support assignment of a unique procurement instrument identifier (PIID) in accordance with the FAR and as required for sharing documents with the Integrated Acquisition Environment (IAE). 2.4 The solution shall capture the current system processing status on all documents, and shall provide query history of document actions and changes in status by document number parameter. 3 Requisitioning 3.1 The solution shall provide flexible, user-definable capabilities and support for the requisitioning process. 3.2 The solution shall provide for the capture of information provided by and about the requestor and system-generated data such as the document number. 3.3 The solution shall include various documents as attachments, such as statement of work, market research standards and specifications, and sole source justification. 3.4 The solution shall provide the ability to set-up roles for approval and routing of documents. 3.5 The solution shall support the capture of Line Item information as described in Requirement #4. 4 Line Items 4.1 The solution shall provide flexible, user-definable line item numbering capabilities and support the entry and re-use of line item data from requisition throughout all subsequent acquisition processes. 4.2 The solution shall support automatic generation of line item numbers, sub-line items and optional line items. 4.3 The solution shall support the capture of the following information at the document line, sub-line, or optional line level: Line number Line amount All Accounting classification elements (Bureau Code, Fiscal Year, Project, Task, Fund, Program, Organization, Object Class) Quantity Unit of measure Unit price Extended price Description Need dates Fob shipping points Mark for Ship to locations (destination) Socioeconomic data Federal Supply Code 4.4 The solution shall support the use of zero dollar or un-priced line items. 5 Electronic Workflow/ Routing/ Approval 5.1 The solution shall provide a flexible user-defined electronic workflow process capability to route documents, including attachments, for review/approval, provide automatic notification to users of significant events and assignments and provide re-routing for pending work. 5.2 The solution shall define several internal and external levels of approval/coordination for use, and prevent unauthorized use. 5.3 The solution shall provide electronic workflow processes and milestone tracking for various types of procurement actions. 5.4 The solution shall allow the creation of standard workflow plans as well as ad-hoc workflow plans by individual users. 5.5 The solution shall store planned and actual milestone dates, and provide means of automatic notification of upcoming or missed milestones. 5.6 The solution shall capture user comments on system-maintained acquisition documents and attachments. 5.7 The solution shall notify the assigned user when an acquisition document status changes via email and internally using the procurement application’s in-box. 5.8 The solution shall prevent documents from being checked out in write or edit mode by multiple users at the same time. 5.9 The version shall provide version control and document changes made, particularly those made after approvals. 5.10 The solution shall provide workflow management reports for supervisors and managers to track progress and missed milestones. 6 Procurement Action Processing 6.1 The solution shall support procurement business processes by providing the capability to capture and assess requirements and manage them through the full procurement cycle. 6.2 The solution will provide automated means to screen requirements to locate mandatory or preferred sources in accordance with FAR and Agency guidance. 6.3 The solution shall provide electronic processing capability for the various acquisition types including those described in the IAE standard transactions at http://www.acquisition.gov/std_transactions.cfm . 6.4 The solution shall support the creation, editing, issuance/execution and administration of all procurement action types defined in the FAR and Agency acquisition guidance, including amendments or modifications to those procurement actions. 6.5 The solution shall provide the capability to create, edit, store, associate and electronically route procurement documents, including attachments and supporting documentation created in other applications/formats (Word, WordPerfect, Excel, PDF, etc.) 6.6 The solution shall minimize the required data or text input by users. The solution will accept text copied from electronic documents created in Microsoft Word or Excel or Corel WordPerfect and pasted into appropriate text fields of documents created in the solution. 7 Document Generation and Regulatory Research 7.1 The solution shall automate the generation of procurement-related documents and forms in addition to providing electronic research capabilities of applicable federal and agency acquisition guidance. 7.2 The solution shall produce procurement forms listed in Federal Acquisition Regulations Part 53 and agency-defined forms and letters and shall provide a form version control. 7.3 The solution shall generate form outputs that can be viewed online, printed, or saved electronically. 7.4 The solution shall provide the capability to create, store, identify, retrieve, display, and print standard and custom procurement documents. 7.5 The solution shall store, update and retrieve federal and Agency-specific provisions and clauses for use in acquisition documents without programming changes. 7.6 The solution shall maintain all prior versions of federal and Agency-specific provisions and clauses and their related effective dates. 7.7 The solution shall define provision/clause use as required, required-when-applicable, or optional based on the principal types and/or purposes of contracts as specified in federal and Agency-specific acquisition guidance. 8 Vendor and Product Data 8.1 The solution shall provide the capability to capture and maintain vendor and product data. 8.2 The solution shall provide automated functionality to capture vendor information through import of data from Central Contractor Registration (CCR) and other components or systems of the IAE such as ORCA. 8.3 The solution shall provide the ability to query vendors for associated product/service codes, document numbers, and other user-defined criteria. 8.4 The solution shall provide the ability to exchange vendor data with the agencies core financial system. 9 Data warehouse 9.1 The solution shall provide for a “mirror-image” of all agency data stored in FPDS-NG. 9.2 The solution shall provide for near real-time, ad-hoc reporting on all data elements available within the database. 10 FPDS-NG Reporting 10.1 The solution shall support Federal Procurement Data System-Next Generation (FPDS-NG) reporting and the submission of procurement data to the FPDS-NG. 10.2 The solution shall capture and consolidate all data in the format required by FPDS-NG for reporting. 10.3 The solution shall provide edit-checking/validation in accordance with the FPDS-NG Reporting Manual. 10.4 The solution shall provide electronic transmission of FPDS-NG data and permit transmission/storage of data in Agency database. 11 System Interface 11.1 The solution shall be integrated with the IAE components or systems as well as internal agency-run applications. Internal applications include the following: Core Financial System Enterprise Acquisition Reporting System Purchase Card System Other bureau specific systems (e.g. Property, Budget, Shipping & Receiving, etc.) 12 Financial Data 12.1 The solution shall collect procurement-related financial data, provide features to support use of that data during the acquisition process and provide the ability to control funds including certifications, commitment, obligation, invoice and payment. 12.2 The solution shall be compliant with the Joint Financial Management Improvement Program (JFMIP) within the Office of Federal Financial Management. 12.3 The solution shall provide the capability to allocate funds for obligations and de-obligations to multiple lines of accounting line item level or higher (order or contract level). 12.4 The solution shall provide the capability to track funds at line item level or higher order or contract level). 12.5 The solution shall be integrated with the DoC financial management system, a Government owned and maintained Oracle-based database system to include Vendor Operations, Commitments, Obligations, Modifications, and Closeout. 13 Reporting 13.1 The solution shall interface with and provide for transmission of procurement data to external Agency reporting software (e.g. Business Objects). 13.2 The solution shall provide data dictionary to map data in the system database. 13.3 The solution shall include edit checks necessary to ensure data validity while minimizing data entry. 13.4 The solution shall provide standard and customized reports (including performance metrics reports) 13.5 The solution shall provide the ability to generate reports for management decision-making. 14 Regulatory Requirements 14.1 The solution shall be and remain compliant with current Federal regulatory and legislative requirements as well as government-wide initiatives (e.g., Section 508 of the Rehabilitation Act, OMB Circular A-123, Integrated Acquisition Environment, Federal Acquisition Regulations, Commerce Acquisition Regulation, Federal Information Processing Standards Publication 200, etc.) 15 Security Requirements 15.1 The solution shall be and remain compliant with security requirement as outline in Federal Information Processing Standards Publication 200 and Department of Commerce Information Technology Security standards. 15.2 The solution shall meet Certification and Accreditation in compliance with NIST Publication 800-37 and NIST Publication 800-53A. 16 Acquisition Planning 16.1 The solution shall be able to provide for Advanced Acquisition Planning (AAP). By this, it is meant a forecasting tool that contracting office managers can employ to view the entire imminent and future office portfolio workload for the purpose of planning adequate resources to meet the forecast demand. 16.2 The solution shall be able to identify DoC’s acquisition needs in advance by allowing users to quickly and easily enter intended acquisitions. 16.3 The solution shall be able to create and update individual acquisition plans. 16.4 The solution shall be able to collaborate with all parties involved in the acquisition process and increase visibility. REQUESTED INFORMATION You are asked to provide four documents as follows: 1. Narrative response to “Product Information Requested” section below. Please include the numbers of the questions you are responding to for each response. 2. A completed “DOC Pricing RFI.xls” spreadsheet which is attached to this RFI. More detailed explanations of the elements to respond to in this spreadsheet are included below. 3. A narrative explaining any qualifying remarks to the “DOC Pricing RFI.xls” spreadsheet. This is open-ended as far as any qualifying information. For some items that are typically difficult to estimate without additional information (e.g., finance system integration or data migration), you may wish to present a range of costs and provide an explanation as to the cost drivers involved. 4. Your GSA schedule, if applicable. Product Information Requested: Please provide responses to the following 1. What functionality does your product offer that is not captured in the functional requirements in this document? 2. What do you believe are the features or other factors that make your product the most competitive? 3. Please delineate, by number and description, any functional requirements listed above that your product is unable to meet. 4. Please provide the complete list of federal clients that are currently using your solution in production. 5. Provide at least three recent examples of implementing a web-based, enterprise-wide acquisition system that meets our functional requirements to include integration with an agency finance system. Describe any performance issues with current web-based enterprise acquisition systems and the solutions to resolve these issues. Please provide contact information for these clients. 6. How many of your total implementations have included integrating with the federal agency’s finance system? What was the approximate integration cost at each of these agencies (please list by agency)? 7. What has been the scope of your implementation experience (number of systems, number of users, etc)? 8. What type of share-in-savings contracts have you provided to the Government? 9. What creative solutions has your organization provided to your perspective clients who are experiencing funding challenges? 10. What type of methodology is used to deploy your system(s)? 11. Do you offer COTS solutions? Is your COTS product customizable, and if so, how so? 12. What type of training do you provide? a. What type of manuals do you provide? How often are they updated? b. Do you provide Quick Reference Guides for the various modules in the product? c. What type of training comes with the product? 13. What is your pricing model, for example, seat license, subscription or enterprise-wide license for a specified purpose? Do you offer an acquisition system as a service instead of, or as well as, a product? 14. If you have a GSA schedule, please provide it as well. . Pricing Information Request: INSTRUCTIONS: Please provide pricing information (in thousands of dollars) for each activity by fiscal year. Pricing data should be provided over the 10 year lifecycle and the out-years should reflect inflation factors as determined by your pricing model. Budget planning is for the system replacement to begin in FY 2010 and be complete by mid FY 2011. While costs in FY 2010 and FY 2011 may include both non-recurring and recurring costs, it is anticipated that FY 2012 and beyond will be only steady state recurring operation and maintenance costs. If you reflect non-recurring costs (ilel, planning or acquisition costs) beyond FY 2011, please discuss the rationale in your accompanying narrative. For budget planning we distinguish between non-recurring costs to deploy the system (Planning Activities and Acquisition Activities) and recurring year-to year costs which represent Operations and Maintenance (O&M) Activities. You will see some elements such as training in both acquisition and in operations and maintenance. In this case, training in the acquisition phase is to train the entire workforce on new software, while in the operations and maintenance phase, the concentration is training of new hires. It is important to keep the concept of segregating recurring from non-recurring costs. Some O&M activities are not performed annually, such as certification and accreditation (a tri-annual federal requirement) or hardware refresh on a three to five year cycle (depending on your own estimate). While these are not annual activities, they are considered recurring costs to be reflected in the O&M section because they are not associated directly with deploying the system as opposed to maintaining the system. Specific pricing information for activities such as “Modify Financial Interface” or “Data Migration” will be considered a rough order of magnitude and should be based on experience with other similar Federal agencies and similar understanding. It would be most helpful to include pricing ranges for those efforts mentioned above along with quality remarks that you would deem to be beneficial in understanding your estimates. Please also include information regarding which costs would be subcontracted. These should be provided in a narrative separate from the spreadsheet in a separate MS Word or Adobe Acrobat document. NOTE: We recognize that though quality pricing information is being provided on an ESTIMATE ONLY basis, it will not be used for legally binding purposes. Following are the descriptions for the price elements to be completed in the spreadsheet. Where reference are made to additional requested comments, please do not put these in the spreadsheet, but include them in a separate narrative in a Microsoft Word 2003 (or earlier version) or Adobe Acrobat document. Planning Activities: The first of three phases of the system lifecycle, planning, means preparing, developing or acquiring the information you will use to design and implement the system. Planning must progress to the point where you are ready to commit to achieving specific goals before preceding to the acquisition phase. Planning activities may include process flow diagrams, data dictionaries, engineering and design studies, and prototypes. Process Changes and Data Standardization - This is the cost associated with assistance in identifying necessary process changes and data standardization efforts going from four bureau systems to a single, enterprise-wide acquisition system. Data Migration Planning - This is the cost associated with the planning of data migration from the existing four C.Request & C.Buy systems to a single, enterprise-wide acquisition system. C.Buy has data dating back to 1999. C.Request has data dating back to 2006. Given the limit information that is being provided, it is anticipated that you are able to use your experience with other similar Federal agencies to provide a range that will be substantiated by comments (e.g. name of agency, total number of records migrated, tasks accomplished, environment, etc.) included with your estimate. Misc. Planning Support Requirements - This is the cost associated with known ancillary requirements not associated with any other planning activity categories. Please specify those requirements with their associated costs. Acquisition Activities: This is the second of three phases of the system lifecycle. This phase begins when funding from Congress has been realized and lasts until the system is delivered and fully operational. Install and Test New Acquisition Software - This is the cost associated with installing and testing the new acquisition system software that will replace the C.Buy & C.Request. Significant testing is expected for both the financial interface between the new system and the DoC Core Financial System and the various interfaces of the Federal Integrated Acquisition Environment with emphasis on FPDS-NG, CCR and FedBizOpps. Modify Financial Interface (ORSI) - This is the cost associated with modifying the new acquisition software to interface with the DoC Core Financial System. The current interface, Obligation and Requisition Standard Interface-ORSI, uses an Enterprise Application Interface (EAI) software solution or “middle-ware” (i.e. TIBCO) to pass data between systems in near real-time. Transactions that are passed include all data associated with: commitments, obligations, modifications, vendor and contract close-out. Given the limited information that is being provided, it is anticipated that you are able to use your experience with other similar Federal agencies to provide a range that will be substantiated by comments (e.g. name of agency, total number of records interfaced, tasks accomplished, environment, etc.) included with your estimate. Develop & Deliver Portal-like Functionality -This is the cost associated with providing the desired web interface for the new web-based system and all acquisition system interfaces. It includes the cost to provide a single sign-on to the system and an integrated "dashboard" capability for procurement customers. The intent is to provide “portal-like” functionality using content management software. Data Migration - This is the cost associated with migrating existing C.Request and C.Buy data into the new acquisition system. Given the limit information that is being provided, it is anticipated that you are able to use your experience with other similar Federal agencies to provide a range that will be substantiated by comments (e.g. name of agency, total number of records migrated, tasks accomplished, environment, etc.) included with your estimate. Initial Requisition Training (4,000 Requisitioners) - This is the cost associated with training the current workforce of approximately 4,000 requisitioner to use the new acquisition system. It is assumed that training materials are included with your estimate unless noted. If training materials are not included, please provide costing information. Please include the number of training hours with your estimate. It is our intent to convert all estimates to a “unit cost per person.” Please provide the information necessary to complete this conversion. Initial Contract Specialist Training (500 Buyers) - This is the cost associated with training the current workforce of approximately 500 buyer to use the new acquisition system. It is assumed that training materials are included with your estimate unless noted. If training materials are not included, please provide costing information. Please include the number of training hours with your estimate. It is our intent to convert all estimates to a “unit cost per person.” Please provide the information necessary to complete this conversion. Initial System Administrator Training (12 Administrators) - This is the cost associated with training the current workforce of approximately 12 system FTEs administrator to use the new acquisition system. It is assumed that training materials are included with your estimate unless noted. If training materials are not included, please provide costing information. Please include the number of training hours with your estimate. It is our intent to convert all estimates to a “unit cost per person.” Please provide the information necessary to complete this conversion. Initial Developer/Tester Training (12 Testers) - This is the cost associated with training the current workforce of approximately 12 DOC testers/quality assurance to use the new acquisition system. These developer/testers will provide functional and full-regression testing of new software. It is assumed that training materials are included with your estimate unless noted. If training materials are not included, please provide costing information. Please include the number of training hours with your estimate. It is our intent to convert all estimates to a “unit cost per person.” Please provide the information necessary to complete this conversion. Hardware - This is the cost associated with new hardware such as servers and networking equipment needed to utilize the new acquisition software. Database Software (e.g. Oracle, DB2, MySQL, etc.) - This is the cost associated with the underlying software that would support the new acquisition system (e.g. Oracle). New COTS Requisition Software - This is the cost associated with either the license or base fee for a subscription-based pricing structure for a requisitioning system. DoC currently uses CACI Federal, Inc. Comprizon.Request. New COTS Procurement Software - This is the cost associated with either the license or base fee for a subscription-based pricing structure for a contract writing and contract management system. DoC currently uses CACI Federal, Inc. C.Buy. This cost also includes the cost of updating agency clause logic. Misc. Acquisition Support Requirements - This is the cost associated with known ancillary requirements not associated with any other acquisition activity categories. Please specify. Operation & Maintenance Activities: This is the third of three phases in the system lifecycle. Once the system is deployed, these ongoing, routine, O&M costs are the steady state activities that are generally consistent throughout the remainder of the lifecycle. These costs are anticipated to be stable with some spikes (e.g. hardware refresh, C&A activities) and most of the growth is from inflation. O&M includes operating and maintaining the system at the deployed and accepted capability and performance level. Testing Support of new Releases - This is the cost associated with testing support in response to changes to the acquisition system and it's configuration Configuration and Change Control Support - This is the cost associated with collecting system change requests, determining and costing the necessary system changes, vetting the resolution, and documenting the change over the system life. This includes maintaining a requirement repository, maintaining documentation of drivers for initial requirements, walk-through Change Control process, facilitating the Change Control process and Change Control Program Management. Triennial Security C&A - This is the cost associated with accomplishing the required security certification and assessment activities to be accomplished every three years. Recurring Requisitioner Training - This is the cost associated with training new-hires and retraining to account for system changes and turn-over. The figure should assume 800 trainees per year (e.g. new DoC employees) with updates to training classes and documentation. It is assumed that training materials are included with your estimate unless noted. If training materials are not included, please provide costing information. Please include the number of training hours with your estimate. It is our intent to convert all estimates to a “unit cost per person.” Please provide the information necessary to complete this conversion. Recurring Contract Specialist Training - This is the cost associated with training new-hires and retraining to account for system changes and turn-over. The figure should assume 100 trainees per year (e.g. new DoC employees) with updates to training classes and documentation. It is assumed that training materials are included with your estimate unless noted. If training materials are not included, please provide costing information. Please include the number of training hours with your estimate. It is our intent to convert all estimates to a “unit cost per person.” Please provide the information necessary to complete this conversion. Recurring System Administrator Training - This is the cost associated with training new-hires and retraining to account for system changes and turn-over. The figure should assume 4 trainees per year (e.g. new DoC employees) with updates to training classes and documentation. It is assumed that training materials are included with your estimate unless noted. If training materials are not included, please provide costing information. Please include the number of training hours with your estimate. It is our intent to convert all estimates to a “unit cost per person.” Please provide the information necessary to complete this conversion. Recurring Developer/Tester Training - This is the cost associated with training new-hires and retraining to account for system changes and turn-over. The figure should assume 4 trainees per year (e.g. new DoC employees) with updates to training classes and documentation. It is assumed that training materials are included with your estimate unless noted. If training materials are not included, please provide costing information. Please include the number of training hours with your estimate. It is our intent to convert all estimates to a “unit cost per person.” Please provide the information necessary to complete this conversion. Hardware Refresh - This is the cost associated with system hardware "refreshed" on a regular basis (usually three to five years, but based upon your estimate) to ensure the hardware environment remains technologically current throughout the lifecycle. New Requisition Software Maintenance - This is the cost associated with the new requisition system to include software improvements, maintenance, and documentation updates. New Procurement Software Maintenance - This is the cost associated with the new contract writing and contract management to include software improvements, maintenance, documentation updates and maintaining agency clause logic. Misc. O&M Support Requirements - This is the cost associated with known ancillary requirements not associated with any other O&M activity categories. Please specify. Procedures for Responding Responses to this RFI are due via email to [email protected] NOT LATER THAN Wednesday, August 27, 2008 at 5:00 p.m. Provide all responses in MSWord 2003 (or earlier version, we do not have Office 2007) or Adobe (.pdf extension). If you have correspondence that cannot be e-mailed, please mail to the attention of Brian Wolfe at the contracting office address specified in this announcement. Respondents may submit multiple solutions and approaches, however, they must be submitted in a manner that reflects a distinct separation from each other. All questions and inquires must be in writing via e-mail and telephonic request for information will not be accepted. -End-