Request for Solutions (RFS)
Naval Sea Systems Command (NAVSEA) Readiness and Logistics Navy Model-Based Product Support (MBPS)
20 March 2019
Amendment 0001: Submission Date Extended to 3 May 2019
This Request for Solutions (RFS) is issued to identify an integrated solution for the Navy’s Model-Based Product Support (MBPS) environment. The Government will evaluate the solutions with the intent to competitively award one or multiple Other Transaction (OT) Agreements for prototype projects through the Training and Readiness Accelerator (TReX) Consortium.
2.0 Summary and Background
2.1 The United States Navy requires a prototype Model-Based Product Support (MBPS) system(s) with enterprise and field level capability to effectively and efficiently acquire, field and sustain weapon systems’ digital twin and enable appropriate predictive analysis and modeling tools that can improve material availability and reliability, increase operational availability, and reduce Operation and Sustainment (O&S) cost.
2.2 The delivered prototype solution(s) will be part of the MBPS family of integrated systems and must support both ashore and afloat that are Cyber Secure and auditable. The MBPS services portfolio is composed of Navy Product Data Management (NPDM), Navy Common Readiness Model (NCRM), and Navy Data Acquisition Requirement Tool (NDART).
2.3 NPDM. NPDM is a single, authoritative system baseline, technical data management, logistics product data, change and configuration management service environment to acquire, manage, and sustain technical data packages to include (but not limited to):
• Configuration Management
• 3D Models
• 2D Drawings
• Test and Evaluation
• Technical Publications, Training, Navy Engineering and Combat Operational Sequencing Systems
• Bill of Material Management (Engineering/Manufacturing/Service Support)
• Document Management, Workflows, Collaboration
2.4 NCRM. NCRM is an integrated modeling and simulation-based approach to supportability analysis within the systems engineering process, which enables acquisition programs to design and sustain equipment and logistics service solutions to meet fleet readiness and cost objectives. NCRM also enables programs to embed readiness at cost models as critical components of the system’s digital twin, which provides the foundation for continuous performance monitoring and enhances decision support services when integrated with enterprise data analytics capabilities. NCRM integrates the following traditional supportability analysis processes / capabilities to develop affordable readiness models:
• Failure Analysis (Failure Mode, Effects and Criticality Analysis (FMECA) and Fault Tree Analysis (FTA))
• Reliability Block Diagram (RBD)
• Multi-echelon Readiness Based Sparing (RBS)
• Level of Repair Analysis (LORA)
• Readiness at Cost Modeling and Simulation
• Reliability and Maintainability (R&M) Engineering Management
• Maintenance Task Analysis
• Failure Reporting and Corrective Action Systems (FRACAS)
2.5 NDART. The NDART will enable Navy program offices to enforce common data standards, requirements and acquisition approaches across all Navy weapon systems acquisition contracts. The high level NDART capabilities will enable the Navy program offices to develop web-based Statement of Work (SOWs), Contract Data Requirements Lists (CDRLs), and Data Item Descriptions (DIDs) for the procurement of technical and product data for a system/platform which will support product support strategies and sustainment of systems throughout the lifecycle.
3.0 General Information
3.1 Attachment 1, MBPS Technical Supplement dated 17 January 2019 and appendices outline the technical program description and requirements of the prototype(s) based on assumptions of the current state of technology. Vendors are encouraged to challenge these assumptions in their individual solutions and should articulate any major discrepancies between the attached technical documentation and the vendor’s technical solution.
3.2 Vendors interested in responding to this Request for Solutions must be members of the TReX.
3.3 The cost of preparing and submitting a response is not considered an allowable direct charge to any Government contract or agreement.
3.4 This is to advise you that non-Government advisors will assist in the evaluation. The use of non-Government advisors will be strictly controlled. Non-Government advisors will be required to sign a Non-Disclosure Agreement for the MBPS Request for Solution. Additionally, they shall also be required to submit documentation to the Agreements Officer indicating its personal stock holdings for a conflict of interest revie in consultation with the legal advisor prior to being allowed access to source selection information.
After the non-Government advisors have completed their particular area of evaluation, they will be released from the evaluation process. All non-Government advisors will only have access to the information corresponding to its area(s) of expertise. They will not have access to the Price Volume of the response. The companies identified herein have agreed not to engage in the manufacture or production of hardware/services/R&D that is related to this effort, and to refrain from disclosing proprietary information to unauthorized personnel.
The following companies will have personnel participating:
Booz Allen Hamilton
8283 Greensboro Drive
McLean, VA 22102
4.0 Solution Paper Responses:
4.1 Solution Paper responses shall contain separate general, technical and price volumes. No pricing detail shall be provided in any volume other than the Price Volume. Each volume shall include the following
4.1.1 General Volume
• Cover Page
• Nontraditional status
• Foreign Owned status
• Sub-vendor List
• Organizational Conflicts of Interest and Mitigation Plans
4.1.2 Technical Volume
• Cover Page
• Solution Paper
• Data Rights and Assertions
• Anticipated Delivery Schedule
4.1.3 Price Volume
• Cover Page
• Rough Order of Magnitude (ROM) and Pricing Breakdown
4.2 General Volume (unlimited page count)
4.2.1 The cover page shall include the vendor’s name, Commercial and Government Entity (CAGE) Code (if available), address, primary point of contact, and status of U.S. ownership.
4.2.2 Nontraditional Status. Within the cover page the vendor shall provide its nontraditional (see paragraph 5.2.3 for definition) business status or your ability to meet the eligibility requirements of 10 U.S.C. §2371b on the cover page of your response. Within your response, please check the following applicable box – with appropriate justification if needed.
□There is at least one nontraditional defense contractor or nonprofit research institution participating to a significant extent in the project.
□All significant participants in the transaction other than the Federal Government are small businesses or nontraditional defense contractors.
□At least one third of the total cost of the project is to be provided by sources other than the Federal Government.
4.2.3 Definition. Nontraditional – an entity that is not currently performing and has not performed, for at least the one-year period preceding the solicitation of sources by the Department of Defense (DoD) for the procurement or transaction, any contract or subcontract for the DoD that is subject to full coverage under the cost accounting standards prescribed pursuant to 41 U.S.C §1502 and the regulations implementing such section.
4.2.4 Foreign Owned, Controlled or Influenced. In accordance with RFS Attachment 3, Security Process for Vetting Contractors, the cover page must include certification that the vendor (and subcontractor(s)) are not Foreign Owned or under USA Foreign
Owned, Controlled or Influenced (FOCI) status (and are not in merger or purchasing discussions for a Foreign company or USA FOCI Company). Should a prospective vendor be unable to so certify, they will be ineligible for award unless the mitigating circumstances in Attachment 3 are met. In such a case, these mitigating circumstances shall be detailed in an appendix to the General Volume.
4.2.5 Sub-vendors. Provide a list of all sub-vendors involved and their role within the performance of your submission as an appendix to your technical submission. The list shall include the same information as requested for 5.2.4, excluding nontraditional
4.2.6 Organizational Conflicts of Interest and Mitigation Plans. Vendors will submit an Organizational Conflict of Interest Mitigation Plan via an Appendix to its General Volume.
126.96.36.199 If you performed work on any of the following contracts you should review the Organizational Conflicts of Interest clauses of those contract(s) for compliancy.
N65726-18-F-3000 (Engineering, Scientific and Technical Services)
N00178-04-D-4024-EH04 (Program Support Services)
N00178-04-D-4090-L60533 (Technical Manual Management Program (TMMP) Information Technology Systems)
188.8.131.52 The Mitigation Plan should reference the regulations implemented in the Federal Acquisition Regulation Subpart 9.5, which implements section 8141 of the 1989 Department of Defense Appropriation Act, Pub. L. 100-463, 102 Stat. 2270-47 (1988).
4.3 Technical Volume
4.3.1 The cover page shall include the vendor’s name, Commercial and Government Entity (CAGE) Code (if available), address, primary point of contact, and status of U.S. ownership. The cover page does not count towards page count.
4.3.2 Solution Paper. Vendors shall provide a Solution Paper for each solution it chooses to propose. Solution Papers shall not exceed the page count in accordance with Table 1 below, utilizing standard Times New Roman 12-point font. Charts or figures
directly relevant to the solution may be referenced and submitted as appendices and are not bound by the Times New Roman 12-point font requirement. Any pages submitted outside of this page length requirement, outside of standard charts and figures, will not be reviewed.
Table 1: Solution Paper Page Count Requirements
Number of Solutions Total Number of Pages
One Solution 20 pages
Two Solutions 30 pages
Three Solutions 40 pages
4.3.3 Vendors may submit a Solution Paper for one or more solutions. NPDM, NCRM, and NDART are each considered a solution. Vendor responses must include systems integration plans that demonstrate how multiple solutions can be integrated into the enterprise MBPS system(s).
4.3.4 MBPS system(s) must consider afloat and ashore Navy users. Naval operational forces consist of surface ships, submarines, carriers, air wings and detached squadrons, expeditionary forces, and cyber forces operating afloat and ashore. They require the ability to generate and sustain material readiness in all environments, to include while in limited or no communications with the Navy enterprise, where material readiness is defined as enough equipment operating with enough capability to meet standards across various pre-defined warfare mission areas.
4.3.5 The MBPS system(s) will be the principal provider of authoritative product data and highly scalable data analytics platform that will be integrated with the Navy Operational Business Logistics Enterprise (NOBLE) family of systems and Navy Maritime Maintenance Enterprise Solution (NMMES) system.
4.3.6 All prototypes will be developed around Human Centered design (HCD) approaches, which shall be integrated with system requirements.
4.3.7 The Navy seeks to focus on mission outcomes and the enabling services and data, while allowing technology to be continuously inserted and modernized without disruption to the user community. Figure 1 represents Navy logistics mission outcomes for material and shore readiness and service experience.
Figure 1: Mission Outcomes
4.3.8 The MBPS system(s) shall be cloud-based and leverage Navy cloud brokers/SecDevOps instances and provide data integration of multiple legacy platforms into a holistic level data environment, accessible via Application Program Interfaces (API) and hosted in a government certified cloud at Impact Level (IL) 4/6.
4.3.9 The cloud environment combined with a common MBPS enterprise system(s) shall provide a highly available and reliable solution. The environment shall be capable of hosting and integrating applications, data, systems and services planned to be transitioned to modern commercial technologies and accomplish this migration of government-owned applications with no degradation of services. Figure 2 represents Navy logistics Enterprise Technical Reference Framework (ETRF).
Figure 2: Navy Logistics ETRF
4.3.10 The vendor’s proposed solution(s) should clearly describe its approach to delivering enduring capabilities as described within this RFS and the corresponding Technical Supplement.
4.3.11 Created software documentation will be marked with Distribution Statement D (Distribution authorized to the Department of Defense and U.S. DoD contractors only due to Critical Technology effective 4 January 2018). Commercial software native to any COTS items used require no distribution statement or export controls.
4.3.12 Vendor solution papers should clearly describe the offered rights in technical data and computer software that will be delivered with your solutions.
4.3.12(a) The offered rights should be displayed in a manner that allows for ease of discussion in determining trade-offs and potential options for long-term sustainability of the deliverables of this effort.
4.3.12(b) If limited or restricted rights are being asserted within your response, detail the specific rationale for this assertion.
4.3.12(c) Any items previously developed with federal funding should clearly identify all components and the Government entity the items were delivered to.
4.3.12(d) If commercial software is proposed to be used within the prototype solution, all applicable software licenses must be included with the response. Note that any software license term or condition inconsistent with federal law will be negotiated out of the license.
4.3.12(e) If the vendor proposes to deliver commercial technical data, computer software, or computer software documentation with licenses providing rights more restrictive than government purpose rights as described in 4.3.13 below, the solution must describe how the design of the proposed MBPS solution provides for modularity sufficient to enable substitution of components of the system at a module or component level. This approach will allow for substitution of such modules or components, and will allow the Government to consider proposals with technical merit, but also include “black box” modules or components with less than government purpose rights.
4.3.12(f) The United States Navy has release authority on any publications related to this prototype project.
4.3.13 Government Desired Rights in Technical Data and Computer Software
184.108.40.206 The following definitions apply to this section.
220.127.116.11(a) Government purpose rights means the right to use, modify, reproduce, release, perform, display, or disclose technical data within the Government without restriction; and release or disclose technical data outside the Government and authorize persons to whom release or disclosure has been made to use, modify, reproduce, release, perform, display, or disclose technical data for United States government purposes. The five-year period, or such other period as may be negotiated, would commence upon execution of the Other Transaction Agreement that required development of the items, components, or processes or creation of the data. The Vendor will have the exclusive right, including the right to license others, to use technical data in which the Government has obtained government purpose rights under this agreement for any commercial purpose during this five-year period. Upon expiration of the five-year or other negotiated period, the Government would receive unlimited rights in the technical data and computer software.
18.104.22.168(b). Unlimited rights means rights to use, modify, reproduce, perform, display, release, or disclose technical data in whole or in part, in any manner, and for any purpose whatsoever, and to have or authorize others to do so.
22.214.171.124(c). Limited rights means the rights to use, modify, reproduce, release, perform, display, or disclose technical data, in whole or in part, within the Government. The Government may not, without the written permission of the party asserting limited rights, release or disclose the technical data outside the Government, use the technical data for manufacture, or authorize the technical data to be used by another party, except that the Government may reproduce, release, or disclose such data or authorize the use or reproduction of the data by persons outside the Government if— (i) The reproduction, release, disclosure, or use is— (A) Necessary for emergency repair and overhaul; or (B) A release or disclosure to— (1) A covered Government support contractor in performance of its covered Government support contract for use, modification, reproduction, performance, display, or release or disclosure to a person authorized to receive limited rights technical data; or (2) A foreign government, of technical data other than detailed manufacturing or process data, when use of such data by the foreign government is in the interest of the Government and is required for evaluation or informational purposes; (ii) The recipient of the technical data is subject to a prohibition on the further reproduction, release, disclosure, or use of the technical data; and (iii) The contractor or subcontractor asserting the restriction is notified of such reproduction, release, disclosure, or use.
126.96.36.199(d). Restricted rights applies only to noncommercial computer software and has the meaning included in Defense Federal Acquisition Regulation Supplement 252.227-7014(a)(15).
188.8.131.52 All rights in Technical Data and Computer Software are negotiable based on the vendor’s proposed solution. The Government seeks government purpose rights to all development and deliverables of technical data and computer software funded under the OT agreement.
4.3.14 Anticipated Delivery Schedule: Vendors shall include its anticipated delivery milestone schedule to reflect its individual solution. The Government’s desire is to complete all prototypes for the governments full set of requirements, to include legacy system rationalization, within 24 months after prototype award. The government will consider incentivizing Vendor solutions that deliver ahead of the government proposed timeline.
4.4 Price Volume
4.4.1 The cover page shall include the vendor’s name, Commercial and Government Entity (CAGE) Code (if available), address, primary point of contact, and status of U.S.ownership.
4.4.2 Vendors shall submit a fixed amount price for its solution, further divided into severable milestones. Pricing submission shall be submitted in a separate document with no pricing detail provided in the solution papers. The price volume has no page number limitation. Attachment 2, SOW, is provided to aid vendors in developing price responses and as a starting point for agreement negotiations with Vendors that are selected to prototype.
4.4.3 Vendors shall clearly identify the anticipated sustainment costs and risks for its solution. In the Technical Volume, Vendors should identify technical approaches and rationale within its proposed solution that will result in sustainment cost savings for the government. Sustainment cost savings from the technical approaches shall be quantified and provided.
4.4.4 Vendors shall provide Rough Order of Magnitude (ROM) pricing for potential follow-on production activities.
5.0 RFS Response Instructions:
5.1 The Government intends to award one Other Transaction Agreement as a result of this Request for Solution; however, more than one award may be made if determined to be in the Government’s best interest.
5.2 All questions related to this RFS should be submitted in writing to firstname.lastname@example.org, with “NAVSEA MBPS” used in the subject line. Submitted questions should also clearly identify if they are related to NPDM, NCRM, and NDART or the overarching MBPS requirement.
5.3 Questions must be submitted no later than 12:00 PM EDT 29 March 2019. Questions received after the deadline may not be answered. Questions shall not include proprietary data.
5.4 The Government reserves the right to post submitted questions and answers, as necessary (and appropriate) to facilitate vendor Solution Paper responses. Submitted questions will be posted without identifying company names.
5.5 Responses shall be submitted no later than 12:00 PM EDT on 3 May 2019. Your response shall be submitted electronically to email@example.com, with “NAVSEA MBPS” used in the subject line. Any submissions received after the deadline may be rejected as late and not considered.
6.0 Selection Process
6.1 Solution Papers will be evaluated with consideration given to the vendor’s ability to provide a clear description of the proposed solution, technical merit of the response and total project risk. The proposed project price, and sustainment costs, schedule, and intellectual property rights assertions will be considered as aspects of the entire response when weighing risk and reward. The approach should also clearly identify the sustainment strategy and address software updates. Attachment 2, SOW, is provided to guide vendors in developing its Solution Paper responses. The SOW will be used as a starting point for negotiating agreements with vendors that are selected to prototype.
6.2 The Government will evaluate the degree to which the submission provides a thorough, flexible, and sound approach in response to the ability to fulfill the requirements in Attachment 1, MBPS Technical Supplement, 17 January 2019.
6.2.1 Phase I – The Government will evaluate the vendors’ Solution Papers outlining its unique solution(s) and approach(es) to meeting the appropriate requirement set. Estimated length of Phase I is 7-10 days. The pool of vendors will be down-selected to a smaller group that will participate in Phase II of the evaluation.
6.2.2 Phase II – Remaining vendors will conduct in-person Solution Demonstrations. Prior to the solution demonstration, the government intends to provide vendors a list of questions generated from the evaluation of the Phase I solution papers. The questions will assist vendors in demonstrating its solutions.
6.2.3 If the Vendor does not have a solution to demonstrate, the vendor shall brief its strategy for executing the prototype(s).
6.2.4 Estimated dates to conduct Solution Demonstrations are [TBD]. These dates are subject to change based on the number of vendors selected to provide Solution Demonstrations. Location of the vendor in-person solution demonstrations will be provided with an Amendment following the Q&A period.
6.2.5 The Solution Paper and the Solution Demonstration will be evaluated based upon the following criteria. Criteria 2-4 will be evaluated based on the vendors’ solution (NPDM, NDART, NCRM). If Solution Paper only addresses one solution such as NCRM, criteria 3 and 4 will not be applicable.
Evaluation Criteria Number Criteria Description
1 Cloud Technical and Computing Performance
2 Navy Common Readiness Model (NCRM) Technical
3 Navy Product Data Management (NPDM) Technical
4 Navy Data Acquisition Requirements Tools (NDART) Technical
5 Integration of Technical Solution
6 Rationalization of Legacy IT Programs
7 Data Management
8 System Engineering Approach
9 Product Support Cost/Affordability
Criteria 1: Cloud Technical and Computing Performance will be assessed based upon the following:
1. Readily containerize and edge deploy application to seamlessly extend MBPS capabilities across shipyards, ships and submarines, including detached operations.
2. Leverages functional domain driven design and a micro services architecture approach to establish a shared services operating model and position the platform to create innovative cross-domain products and services.
3. Address enterprise edge-to-cloud information pipe constraints by prioritizing data interchange between Enterprise Cloud and Edge based on network bandwidth and critical nature of business capability serviced.
4. Ensure that cloud and edge solutions remain consistent and complement each other’s capabilities by communicating information and syncing data only via APIs and enabling consistent technology stacks.
5. Support serverless posture at the edge, minimizing memory and processing foot print for submarines, ships and expeditionary units
6. Support the application of Artificial Intelligence (AI) algorithms, optimized in the Cloud, on limited data sets available for deployed (edge) solutions.
7. Enable an integrated enterprise data platform that scales to accommodate thousands of data sources and millions of data point while enabling real time decision making in a highly immersive customer experience leveraging Mobility and AI.
8. Leverage native cloud capabilities to support automated distribution of product and technical data models based on triggers and meta data from MBPS capabilities, specifically configuration management
9. Support a scalable, enterprise CAD and modeling and simulation capability that minimizes latency from hours to seconds
Criteria 2: Navy Common Readiness Model (NCRM) Technical will be based upon the following:
1. Support seamless, end-to-end information flow and bi-directional connectivity across each analytical technique (Failure Analysis, Reliability and Maintainability Engineering, Reliability Centered Maintenance, Maintenance Task Analysis, Level of Repair Analysis, Readiness at Cost Modeling and Simulation, etc.) within Supportability Analysis
2. Enable the Navy to treat Readiness at Cost designs, models and simulations as configuration items that are configuration management across the weapon system lifecycle
3. Enable the Navy to rapidly conduct design tradeoffs/what ifs scenarios across the lifecycle for complex weapon and support system designs to meet the Navy’s materiel readiness and total ownership cost requirements
4. Support rapid aggregation and disaggregation of system optimization models to develop complex system, ship, strike / task group and fleet models that produce the design, resource, and cost requirements needed to support different readiness levels across various mission scenarios.
5. Integrate modeling and simulation and enterprise cloud / edge advanced data analytics capabilities to enhance the effectiveness of decision support across the Navy.
6. Enable an enterprise, edge deployable approach to designing, deploying and operating Predictive Maintenance and Prognostic and Health Management solutions to support mission readiness reporting and decision support across the Navy.
7. Include a closed-loop Data Reporting and Root Cause Analysis System (DRACAS) to continuously monitor performance against required/predicted mission and design outcomes, conduct root cause analysis, and improve performance, agility, responsiveness, and scale of supply chain, maintenance and support operations.
Criteria 3: Navy Product Data Model (NPDM) Technical will be based upon the following:
1. Enable the Navy to develop, receive, sustain, publish and distribute serialized product data models with full bi-directional traceability, associativity and effectivity
2. Anchor “all” product model data to NPDM’s change proposal/notification capability to enable the Navy to affordably manage product data model configuration across the lifecycle?
3. Provide collaborative model-based program and project management business capabilities to enhance a program's ability to meet its business, schedule, quality, risk and technical requirements; associate objects to the program’s product structure; and provide configuration management as part of the system’s baseline?
4. Provide an enterprise collaborative knowledge management capability within NPDM to provide access and visibility to required program information and traceable environment digital communications across the Navy to support commonality and high velocity learning
5. Provide the capability to develop and manage enterprise level workflows and provide business intelligence reporting to track workflow and business process status
6. Support seamless, end-to-end information flow between all NPDM and NCRM capabilities
Criteria 4: Navy Data Acquisition Requirements Tool (NDART) Technical will be based upon the following:
1. Enforce common non-proprietary data standards, requirements, and acquisition approaches across all Navy weapon system acquisition contracts
2. Provide simplified, prompted solution that enables users to develop Statements of Work (SOWs), Contract Data Requirements Lists (CDRLs), Quality Assurance Plan (QAP) and Data Item Descriptions (DIDs) to acquire product data models
3. Correlate answers from the prompted questions into the end-products (e.g., SOW, CDRL, DIDs) for the acquisition contract based on non-proprietary data standards that meet requirements following acquisition approaches
4. Employ established business rules for decision points within standards (e.g., business rule decision points) and content requirements (e.g., information sets) into the acquisition contract
5. Provide a collaborative knowledge management environment with access and visibility to for a repository of the previously developed acquisition contracts
6. Generate usage reports (e.g., Access Logs, Functionality used, CDRLs generated, DIDs used, times a specification/standard was used for the Digital Data Delivery requirements, etc)
7. Cover the acquisition of COTS Product Data
8. Provide the capability to auto-generate an acquisition workflow to include a data requirements list for tracking the anticipated data products to be received
9. Provide for the specification of the acquisition of data types needed for the NCRM and NPDM components such as (not all inclusive): installation, operation, maintenance, overhaul, failure analysis, reliability, parts management, and other logistics data, etc.
10. Enable seamless integration of product data models from Original Equipment Manufacturers PLM systems into the Navy's MBPS system
Criteria 5: Integration of Technical Solution(s) will be based upon the following:
1. Define, execute, and test integration requirements internally across MBPS capabilities (NCRM, NPDM, NDART)
2. Define, execute, and test integration requirements externally to the ETRF and other LogIT applications such as NOBLE, NMMES-TR, etc.
3. Enable use of multi-computing platforms (e.g. laptops, Smart Phone, tablets, additive manufacturing printers, mobile printers etc.) (interdependencies between NOSS, NAMS, NOME, and NOBLE at large).
4. Address Technical Integration Risks as it relates to technology maturity, implementation
Criteria 6: Rationalization of Legacy IT Programs will be based upon the following:
1. System Assessments and Technical Business Case Analysis (BCAs) to influence system rationalization strategy
2. Data Rationalization Strategies to quickly transition workforce to MBPS capabilities
3. System Rationalization and Implementation plan identifying high-level timeline and proposed shutdown of legacy applications
4. Reduction of sustainment costs through the use of Out of the Box (OOTB) COTS solutions versus customization
5. Minimize the use of proprietary solutions
Criteria 7: Data Management will be based upon the following:
1. Self Service Access: Greater use of search, natural language processing, and self-service tools for data preparation, business intelligence and reporting, and analytics
2. Rapid Insights Discovery: Investments in data discovery capabilities to identify patterns, trends and opportunities previously unknown
3. Hybrid Framework: A strategic selection of hybrid fit-for-purpose technologies accelerating data movement at the speed of the mission
4. Governed Data Lake: Governed and trusted data lake evolves to become the authoritative source of data, including the evolution of data catalogs and metadata
5. Automation, Artificial Intelligence (AI) and Machine Learning: Evolution of intelligent solutions to data management challenges for data integration, data quality, and master data management
6. Data Standards: Common language and syntax for data to provide a streamlined process from the start to finish of the data lifecycle
7. Data Characteristics: Enablement of Auditable, Visible, Trustworthy and Accessible data to support mission outcomes and enable informed decisions by Navy leadership, program offices and shipboard personnel
Criteria 8: System Engineering Approach will be based upon the following:
1. Use of an Agile Scrum Methodology to rapidly deploy capability and requirements management
2. Implement HCD principles and incorporate user feedback throughout the software development lifecycle process (SDLC).
3. Clearly define Software Baseline Management and Test and Evaluation strategies
4. Address Legacy System shutdown through system rationalization strategies and implementation of MBPS capability
5. Clearly communicate schedule to include risks and dependencies to achieve an integrated MBPS minimum viable product (MVP) to support all Navy MBPS objectives.
6. Standardize and incorporate user experience findings as a pre-requisite for further prototype improvement and development.
7. Use of system model (SySML) throughout the SDLC
Criteria 9: Product Support Cost and Affordability will be based upon the following:
1. Provide a lifecycle cost estimate
2. Identifies critical risks to affordability and recommends readily implementable mitigation strategies
3. Identify opportunities to minimize the manpower requirements to sustain MBPS services by leveraging advanced Artificial Intelligence capabilities such as Robotic Process Automation (RPA) and Blockchain
4. Address affordable strategy to conduct initial and sustainment training requirements
5. Address system training and instruction (installation guide, system help, tier 1 documentation) developed in S1000D and associated with the product baseline
6.2.6 The Government will award this OT prototype project through TReX, to the vendor whose solution is determined to be the most advantageous to the Government, cost, schedule, technical risks and other factors considered. One or more OT agreements are anticipated to be awarded to accomplish the necessary work and select the best response(s) satisfying the criteria stated in Section 7.2.5.
6.2.7 The Government reserves the right to award to a vendor that does not meet all of the requirements, but provides attributes or partial solutions of value.
7.0 Additional Information
7.1 Export controls: research findings and technology developments arising from the resulting project may constitute a significant enhancement to the national defense and to the economic vitality of the United States. As such, in the conduct of all work related to this effort, the recipient will comply strictly with the International Traffic in Arms Regulation (22 C.F.R. §§ 120-130), the National Industrial Security Program Operating Manual (DoD 5220.22-M) and the Department of Commerce Export Regulation (15 C.F.R. §§ 730-774).
7.2 Interaction and/or Disclosure with Foreign Country/Foreign National Personnel. The contractor should comply with foreign disclosure processes IAW Army Regulation 380‐10, Foreign Disclosure and Contacts with Foreign Representatives; the Department of the Navy Foreign Disclosure Manual, SECNAV M-5510.34, as of June 2017; Department of Defense Directive (DoDD) 5230.11, Disclosure of Classified Military Information to Foreign Governments and International Organizations; and DoDD 5230.20, Visits and Assignments of Foreign Nationals.
7.3 All submissions shall be unclassified. Submissions containing data that is not to be disclosed to the public for any purpose or used by the Government except for evaluation purposes shall include the following sentences on the cover page:
“This submission includes data that shall not be disclosed outside the Government, except to non-Government personnel for evaluation purposes, and shall not be duplicated, used, or disclosed -- in whole or in part -- for any purpose other than to evaluate this submission. If, however, an agreement is awarded to this Company as a result of -- or in connection with – the submission of this data, the Government shall have the right to duplicate, use, or disclose the data to the extent agreed upon by both parties in the resulting agreement. This restriction does not limit the Government's right to use information contained in this data if it is obtained from another source without restriction. The data subject to this restriction are contained in sheets [insert numbers or other identification of sheets]”
7.4 Each restricted data sheet should be marked as follows:
“Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this submission.”
8.0 Follow-On Production
Upon a vendor’s successful completion of the prototype, the Government anticipates a follow-on production contract or transaction may be awarded to the vendor without additional competition. Successful completion will be defined in the negotiated Statement of Work (SOW) for this prototype project. Specifically, the negotiated SOW will specify the Minimum Viable Product (MVP) prototype requirements (i.e. minimal core features). Successful completion will occur when the prototype has been validated to meet the MVP requirements and is accepted by the Government.
Further, the government reserves the right to determine part or all of the prototype project is successfully completed if the vendor shows a particularly favorable or unexpected result justifying the transition to production.
Attachment 1, MBPS Technical Supplement dated 17 January 2019 (Draft Appendices are for Reference Only)
Attachment 2, SOW (Appendices are for Reference Only)
Attachment 3, Security Process for Vetting Contractors
To view or download the amended or original request for solutions (RFS) or the above referenced attachments, click on the hyperlinked text below.
Membership in the Training and Readiness Accelerator (TReX) OTA is required to submit a solution(s) to this RFS. Questions regarding membership should be sent to: firstname.lastname@example.org.