Attachment_B_Volume_I_Technical__Proposal_Structure.pdf

Attachment B – Volume I (Technical Proposal Submittal Structure)

Volume I – Technical Proposal Submittal Format

Proposers shall organize their Technical Proposal in accordance with the structure outlined in Exhibit 1 below. Each section should be clearly labeled and presented in the order specified. Failure to follow this structure may adversely impact the evaluation of the proposal.

Exhibit 1: Volume I - Technical Proposal Organizational Structure

SectionI

D

Section Title

Included In Evaluation

Proposal Cover Letter & Partner Acknowledgements No

Table of Contents No

1.0 Executive Summary (60-Page Count Starts Here) Yes

2.0 SaaS Proposer Qualifications and Experience Yes

3.0 SaaS Solution Overview Yes

4.0 Functional Requirements Response Yes

5.0 SaaS Non-Functional Requirements (SLR) Response Yes

6.0 Integration and Data Architecture Yes

7.0 Product Strategy, Innovation, and Roadmap Yes

8.0 Implementation Ecosystem and Customer Success Model Yes

9.0 SaaS Licensing and Contractual Terms (Page Count Ends

Here)

No

Technical Submittal s

A, B, C, D, E, F, F.1, and G Yes (as Applicable)

Proposal Cover Letter and Partner Acknowledgement(s)

The Proposer shall submit a cover letter, not to exceed two (2) pages, signed by an authorized representative of the Proposer who is empowered to bind the organization contractually. The cover letter shall serve as a formal transmittal of the proposal and acknowledgment of the Proposer’s commitment to the requirements of this RFP. At a minimum, the cover letter shall:

• Identify the legal name of the Proposer, principal business address, and primary point of contact.

• Designate up to two (2) individuals authorized to negotiate and execute contractual agreements on behalf of the Proposer.

• Acknowledge receipt, review, and understanding of the RFP documents and any addenda.

• Confirm that the proposal constitutes a firm offer valid for the period specified in this RFP.

• Affirm the Proposer’s acceptance of, or clearly reference any exceptions to, RTD’s contractual terms and conditions.

If the proposal includes partners, resellers, or third-party components, the Proposer shall include partner acknowledgement letters confirming participation and commitment to the proposed solution. The Proposer shall clearly identify the roles and responsibilities of all such parties, including any components that may require separate contractual agreements with RTD.

Table of Contents

The Proposer shall include a complete and clearly organized Table of Contents (TOC) for the entire proposal, covering all sections. The TOC shall provide accurate page references and clearly identify all major sections, subsections, tables, figures, and technical submittals. The TOC shall be structured to align with the required format and shall include hyperlinks, where feasible, to facilitate efficient electronic review.

Section 1.0 – Executive Summary

The Proposer shall provide a concise Executive Summary that presents a clear, high-level overview of the proposed ERP SaaS solution and its overall value to RTD. The summary should communicate, in business terms, what is being proposed, how the solution aligns with RTD’s objectives, and why the Proposer is uniquely positioned to deliver long-term value.

The Executive Summary should describe the proposed ERP platform, the scope of core capabilities being offered, and the overall approach to supporting RTD’s finance, procurement, inventory, and human resources needs within a modern, integrated SaaS environment. It should also highlight the Proposer’s relevant experience, the strength and maturity of the solution, and any distinguishing features, such as platform innovation, scalability, or advanced capabilities, that provide meaningful benefit to RTD.

The content should be written for a broad audience, including non-technical stakeholders, and should focus on clarity, value, and key differentiators without repeating detailed information provided in the remainder of the proposal.

Section 2.0 – SaaS Proposer Qualifications and Experience

The Proposer shall provide information demonstrating its qualifications, experience, and capability to deliver and support the proposed ERP SaaS solution over the long term. The response should clearly establish the Proposer’s credibility as a SaaS provider and its ability to meet the needs of a large, public-sector transit agency such as RTD.

• The Proposer shall describe its organizational background, including corporate structure, years in operation, ownership, and the maturity of its ERP SaaS offering.

This information shall be provided using Technical Submittal A – SaaS Proposer Profile, along with any supporting narrative necessary to convey the scale, stability, and experience of the organization and its ERP SaaS platform.

• If the proposed solution includes partners, resellers, or third-party software components, the Proposer shall identify such parties and describe their role in the overall solution. This information shall be provided using Technical Submittal B

– Partner / Third-Party Vendor Profile and should clearly describe the nature of the relationship and the role each party will play in supporting the proposed SaaS solution.

• The Proposer shall highlight relevant experience delivering the proposed ERP SaaS solution for organizations of similar size and complexity, with particular emphasis on public sector and/or transportation/transit industry clients, where applicable. The response shall include a summary of representative engagements and outcomes, supported by client references. Proposers shall provide a minimum of three (3) client references using Technical Submittal C – Client References.

• The Proposer shall also provide information demonstrating its financial strength and organizational stability to support the ongoing delivery, maintenance, and enhancement of the SaaS solution throughout the expected contract lifecycle.

This information shall be provided through Technical Submittal D – Financial Qualifications, per requirements in Section 4.4 (Financial Records) of the RFP.

• In addition, the Proposer shall disclose any material legal matters, including bankruptcy, litigation, or contractual disputes within the past five (5) years, using Technical Submittal E – Legal Disclosures.

Section 3.0 – SaaS Solution Overview

The Proposer shall provide a clear and concise overview of the proposed ERP SaaS solution, describing the overall platform, architecture, and core capabilities supporting RTD’s finance, procurement, inventory management, and human resources needs. The response should demonstrate how the solution operates as an integrated, modern SaaS-based ERP system.

• The Proposer shall describe the solution architecture, including key modules and how they function within a unified environment. The response shall clearly distinguish between native functionality and any third-party or bolt-on components.

• The Proposer shall also describe the SaaS delivery model, including tenant architecture, system updates, and overall platform design, demonstrating how the solution is delivered, maintained, and evolved in a cloud environment.

• In addition, the Proposer shall describe its approach to maintaining system stability in production, including how updates, patches, and integrations are managed to minimize disruption and ensure compatibility across releases.

• The Proposer shall provide a high-level system architecture diagram illustrating core components, integrations, and data flows, and describe how the solution integrates with other enterprise systems.

The Proposer must demonstrate the ability to meet both primary and secondary SaaS objectives as described in Section 1.1 (Summary) of the RFP. Proposers should briefly describe the breadth and scalability of their platform and any additional value it may provide as RTD evolves toward a more integrated environment. The Proposer shall ensure that this section aligns with the detailed functional and non-functional responses provided elsewhere in the proposal.

Section 4.0 – Functional Requirements Response

The Proposer shall provide a comprehensive response to RTD’s functional requirements for finance, procurement, inventory management, and human resources requirements using the requirements compliance matrix (Technical Submittal F – ERP Functional and Technical Requirements).

• The Proposer shall complete the requirements matrix in its entirety and shall not modify RTD-provided content. Responses shall clearly indicate the level of support for each requirement in accordance with the response options and instructions defined within the matrix.

• Proposers shall ensure that responses accurately reflect the capabilities of the proposed ERP SaaS solution. Where functionality requires configuration, extension, or third-party components, the Proposer shall clearly describe the approach and any associated considerations.

• Responses should be specific, concise, and directly aligned with the proposed solution. Generic or unsupported responses are discouraged and may adversely impact evaluation.

The completed requirements matrix will be a primary input to RTD’s evaluation and will be incorporated into the final contract. Proposers are expected to exercise due diligence in preparing responses, as the Proposers response will be considered binding commitment.

Section 5.0 – SaaS Non-Functional Requirements Response

The Proposer shall provide a comprehensive response to RTD’s SaaS Non-Functional Requirements (SLRs) using the requirements compliance matrix (Technical Submittal F.1 – SaaS Service Level Requirements / Non-Functional Requirements).

• The Proposer shall complete the SLR matrix in its entirety and shall not modify RTD-provided content. Responses shall clearly indicate compliance with each requirement in accordance with the response options and instructions defined within the matrix.

• Proposers shall ensure that responses accurately reflect the capabilities of the proposed SaaS platform, including security, performance, availability, disaster recovery, data management, and compliance.

• Responses should be specific and substantiated and should reflect established capabilities rather than future or conceptual functionality. Generic or unsupported responses are discouraged and may adversely impact evaluation.

The completed SLR compliance matrix will be a key component of RTD’s evaluation and will be incorporated into the final SaaS contract, including service level commitments.

Proposers are expected to exercise due diligence in preparing responses, as they may be considered binding.

Section 6.0 – Integration and Data Architecture

The Proposer shall describe the integration capabilities and data architecture of the proposed ERP SaaS solution, demonstrating how the platform supports a connected and scalable enterprise environment.

• The Proposer shall describe the available integration mechanisms, including APIs, data exchange methods, and support for real-time and batch integrations.

The response should convey how the solution enables interoperability with external systems and supports seamless data flow across functional domains.

• The Proposer shall also describe the underlying data architecture, including data management practices, data consistency, and support for reporting and analytics. The response should demonstrate how the solution enables reliable, accurate, and timely access to enterprise data.

• In addition, the Proposer shall describe how integrations and data flows are managed and maintained over time, including compatibility across system updates and releases, to ensure long-term stability and minimize disruption to RTD operations.

The Proposer shall provide a high-level integration and data architecture diagram illustrating key systems, interfaces, and data flows relevant to the proposed solution.

Section 7.0 – Product Strategy, Innovation, and Roadmap

The Proposer shall describe the long-term strategy and evolution of the proposed ERP SaaS platform, demonstrating its ability to support RTD’s needs over time.

• The Proposer shall outline the product roadmap, including planned enhancements, release cadence, and approach to continuous improvement. The response should convey the maturity of the platform and the Proposer’s commitment to ongoing investment and innovation.

• The Proposer shall also describe key innovation areas within the platform, including capabilities related to automation, advanced analytics, and artificial intelligence (AI). The response should highlight how these capabilities can improve efficiency, enhance decision-making, and support evolving business requirements.

In addition, the Proposer shall describe how new features and innovations are introduced to customers, including how updates are managed and how RTD can adopt new capabilities with minimal disruption.

Section 8.0 – Implementation Ecosystem and Customer Success Model

The Proposer shall describe the system integrator (SI) ecosystem associated with the proposed ERP SaaS solution and how it supports successful implementation and long-term sustainability.

• The Proposer shall describe the breadth and maturity of its SI partner network, including the types of partners available (e.g., global system integrators, regional firms, industry specialists), the approximate scale of the ecosystem, and the capabilities each partner type provides. The response should highlight the availability of partners with public sector and/or transit experience, and any relevant specialization.

• The Proposer shall also describe how the SI ecosystem is structured and governed, including partner certification, enablement, and quality assurance practices, and whether the ecosystem includes partners capable of providing post-implementation managed services. The response should convey how RTD would benefit from this ecosystem and any key considerations associated with engaging SI partners.

In addition, the Proposer shall describe its customer support model, including support channels, service levels, and escalation procedures, as well as its approach to customer success, including onboarding, adoption, and ongoing engagement. This section should focus on the overall SI ecosystem and post-deployment support model for the SaaS solution. Detailed system implementation services are not in scope for this RFP and should not be included.

Section 9.0 – SaaS Licensing and Contractual Terms

This section is intended to provide RTD with a clear understanding of the Proposer’s SaaS licensing model and standard contractual framework. This section is not part of the evaluation of technical capabilities, but will inform RTD’s review, due diligence, and contract negotiations.

• The Proposer shall describe its SaaS licensing approach, including subscription structure, user licensing model, and any relevant considerations related to scalability, usage, or access. The response should clearly convey how the proposed licensing model aligns with RTD’s operating environment. Please Note:

Only include this part of the narrative under the Section 9.0 (part of the 60-page count), and all other information requested below must be submitted as part of Submittal G.

• The Proposer shall provide creative options to enable RTD to first purchase the Finance/Procurement SaaS licenses and at a later time expand to human resources licensing, with the objective towards an unified solution and lower total Cost of ERP Ownership.

• The Proposer shall also submit, as Submittal G – SaaS and Other Agreements/Documents, its standard SaaS subscription agreements, licensing terms, ordering documents, and any related contractual materials that would form the basis of the agreement with RTD. Proposers should clearly identify any key terms, assumptions, or constraints associated with their standard agreements.

RTD will include some, some of its own standard terms and conditions and SaaS-related contractual provisions as part of this RFP. Proposers shall acknowledge that all submitted contractual documents will be subject to review by RTD’s legal, procurement, and technical teams, and that the final agreement will be subject to negotiation to align with RTD’s contractual, business, and regulatory requirements.

Proposers shall not include any pricing or cost-related information in this section. All pricing information shall be provided exclusively in Volume III – Cost/Price Proposal.