Att F- Technical Proposal.docx

RFP 26-85299

TECHNICAL PROPOSAL

ATTACHMENT F

INSTRUCTIONS

· Please supply requested information in the blue-shaded areas and indicate any attachments that have been included.

· Document all attachments with which section and question they pertain to.

Mandatory Requirements Yes/No

1. Does your proposed solution provide a secure, reliable, and scalable enterprise platform that provides GPS tracking, diagnostics telemetry, and driver‑behavior analytics across all participating agencies? Please explicitly confirm that your hosting model supports deployment within a State-owned tenant, as required by the SOW (Security Standards → Hosting Requirements).

2. Can you deliver the full operational stack (including hardware devices, secure hosting, web/mobile interfaces, user training, data retention, and transition services) as a complete, turnkey service?

3. The respondent must demonstrate a minimum of five (5) years of relevant experience providing services similar in scope, complexity, and industry alignment to those described in this RFP. The proposal must include clear evidence of this experience in the response box below.

4. The respondent must be the original developer, owner, or authorized primary provider of the proposed software solution. Resellers, distributors, or third‑party intermediaries are not eligible to respond to this RFP. Please confirm that you’re the original developer, owner, or authorized primary provider below.

Technical Proposal

5. Background

5.1. Explain your plan to support diverse agency needs (INDOT, DNR, DOC, ISP) both during the initial statewide implementation phase and throughout the contract lifecycle.

5.2. Provide two examples of multi-agency, public-sector, or highly complex enterprise implementations of similar size, scope, and technical complexity to the State of Indiana's requirements.

5.3. Explain how your platform handles multi-tenant organizational structures. Detail how individual agencies (e.g., IDOA vs. INDOT) can manage their own sub-fleets, construct custom geofences, and establish agency-specific alert distribution rules, while still allowing IDOA central administrators global visibility and reporting capabilities. Please detail how your solution integrates with State IAM (Microsoft Entra ID) to support SSO, MFA, and role-based access, consistent with SOW Section 3.3 Security Requirements.

6. Telematics System Functional Requirements

6.1. Detail the capabilities of your platform's web and mobile interfaces. Specifically describe how the system processes and displays near-real-time GPS tracking latency, historical route playback rendering, and the creation of dynamic, rule-based geofences.

6.2. Detail your platform’s methodology for driver behavior scoring and safety profiling. Explain the specific mathematical or logical parameters used to define and log events such as harsh braking, rapid acceleration, speeding (including correlation with posted speed limits), and excessive idling, and detail how these are synthesized into configurable alerts and reports. If AI or ML is used in driver scoring, please confirm full compliance with the State’s AI Policy and the AI Readiness Assessment Process, consistent with the SOW’s Artificial Intelligence Standards.

6.3. Describe the telemetry and engine diagnostics data points natively captured by your platform (including Diagnostic Trouble Codes [DTCs], odometer readings, and fuel consumption indicators). Detail how this data is visualized on the platform and how it can be utilized by fleet managers to trigger automated preventive maintenance actions.

6.4. Provide two examples of configurable dashboards and reports used for oversight/incident review. (These may be included as attachments. Please list the attachment title in the response box below.)

7. Hardware & Telematics Devices

7.1. Detail your hardware's plug-and-play compatibility with standard OBD-II and J1939 protocols, as well as specialty assets (including light-duty, heavy-duty, specialty vocational equipment, and off-road vehicles) across the State’s diverse fleet.

7.2. Detail your hardware's capabilities regarding secure, encrypted data transmission (device-to-cloud), over-the-air (OTA) firmware updates, physical tamper detection/disconnection alerts, offline caching capabilities during network outages, and cellular network connectivity protocols. Additionally, please identify supported carriers and describe your failover logic (e.g., automatic carrier/SIM profile switching).

7.3. Describe your deployment and installation options (including professional contractor-led installation vs. self-install options). Include average installation times per asset type, hardware durability specifications (e.g., IP water/dust ratings), warranty coverage, and your expedited replacement and Return Merchandise Authorization (RMA) procedures for faulty equipment.

7.4. Provide your GPS accuracy metrics (in feet) and your standard update/ping rates (both when the vehicle is in motion and when the ignition is off). Detail any platform limits on modifying ping frequencies.

7.5. Do your devices have battery draw protection?

7.6. Provide the estimated operational lifecycle of the proposed hardware models. Detail your roadmap for supporting future cellular network technology shifts (e.g., transitions beyond 5G) to ensure the State does not face premature hardware obsolescence during the contract term.

8. Deliverables

8.1. Describe how your platform meets the State’s requirement for encryption in transit and at rest, including technologies used and compliance standards followed.

8.2. Explain your cybersecurity incident response process, including notification timeframes, escalation paths, and coordination with State security teams.

8.3. Describe your API capabilities, including authentication methods, rate limits, available endpoints, and documentation.

8.4. Explain how your system integrates with existing State financial systems (Peoplesoft) and describe any required vendor-led configuration. Identify the specific technical requirements and the level of vendor-led configuration required to implement these integrations.

8.5. Provide your Project Management Plan, including a work breakdown structure, implementation schedule, milestones, and resource assignments.

8.6. Describe your ongoing customer support and technical help desk model. Specifically detail support hours, tier-escalation pathways, and your guaranteed response and resolution timeframes (SLAs) for critical system-wide outages versus individual device reporting failures.

8.7. Describe your transition plan for migrating from legacy platforms to your solution with zero operational downtime.

8.8. Describe the documentation your team provides related to system configuration, installation, updates, retention policies, and SLA performance reporting.

8.9. Explain your automated or manual processes for delivering recurring monthly service performance reports, including platform uptime statistics, device reporting reliability, documented security/operational incidents, and contract KPIs.

8.10. Describe how your organization guarantees platform uptime and interface responsiveness. Detail the system monitoring tools utilized and specify your contractually committed system uptime percentage (SLA).

8.11. Explain how your system actively monitors and maintains high location/spatial accuracy and consistent device reporting reliability, including automated diagnostic checks for "non-communicating" devices.

9. Transition In & Out

9.1. Describe your change management and user adoption strategy. Beyond standard user guides, detail how you will assist agencies in driving system adoption and technical proficiency among field staff, operators, and labor groups who may be resistant to telematics monitoring.

9.2. Explain your logistical plan to support physical hardware return, replacement, recycling, and device decommissioning during the 90-day contract transition period, ensuring zero disruption to active agency operations, and describe steps for legacy data migration without loss.

9.3. Describe the process for transferring all data and archives to the State or a successor vendor at contract end.

9.4. Explain how you support hardware return or replacement and device decommissioning during contract transition.