11954_Final RFI_Posted.docx

Oregon Department of Transportation ODOT Procurement Office 355 Capitol Street NE, MS #33 Salem, OR 97301

REQUEST FOR INFORMATION (“RFI”)

Information Technology Service Management Replacement

RFI Number: S-73000-00011954

RFI Issue Date: January 23, 2025

Response Due Date: See Bid Opening Date and time for this RFI in OregonBuys

Written responses to this RFI are due no later than the date identified above. Responses must be submitted via OregonBuys.

All inquiries must be submitted via email to Katie Bighill, the Purchaser or Single Point of Contact at katie.bighill@odot.oregon.gov.

NOTE: All proposed information, methodology, and options presented in this RFI are subject to change based upon the ability, discretion and need of the Oregon Department of Transportation (“ODOT”).

Table of Contents

Project Name Information Technology Service Management (“ITSM”) Replacement

Purpose ODOT is interested in obtaining valuable information about ITSM software that could improve services and increase productivity for its customers.

The information provided may assist ODOT in preparing and issuing a formal Request for Quote (“RFQ”) or a Request for Proposal (“RFP”) at a later date. ODOT anticipates utilizing a participating supplier from Statewide Purchase Agreement 9404. Below are the current listed participants. ODOT encourages interested parties to reach out to the below participants for possible contracting opportunities prior to the potential release of a formal RFQ (or RFP).

NO CONTRACTS WILL BE AWARDED AS A RESULT OF THIS RFI.

The contact information below is included as a courtesy and ODOT recommends validating this information independently.

Bartek Kurek coty.clack@lumen.com Bartek.kurek@lumen.com

(458) 221-7424

(971) 346-4053

TeamOregon@SHI.com

(503) 805-5442

Dominque Mitchell Alejandra Ratchford Gfishbein@smxtech.com Dmitchell@smxtech.com Aratchford@smxtech.com

(617) 921-2278

(571) 895-4529

(512) 998-1887

ODOT anticipates releasing an RFQ (or RFP) for the ITSM solution by March 1, 2025, and have the new ITSM system in place and functioning by October 2025.

High-Level Description of Current System and Desired System ODOT’s current ITSM system is primarily utilized to manage its information technology (“IT”) assets and to track help desk calls, emails, and requests. In addition to incident and asset management, ODOT also utilizes a service catalog for internal personnel to submit incidents and requests. The current ITSM system used by ODOT is no longer supported by the vendor and ODOT is seeking a replacement.

a) High-Level Description of the Current System:

1) Incident Management (tracking service disruptions or break-fix events)

2) Asset Management (tracking IT asset purchases and lifecycle)

3) Service Request Management (submission of incidents and requests with Level 1 & Level 2 support)

4) Reporting Console (able to report on all data contained within the ITSM system)

5) Knowledge Management (testing completed, but not in use)

6) Change Management (testing completed, but not in use)

7) Service Level Management (testing completed, but not in use)

b) High-Level Description of the Desired System ODOT is seeking information for a cloud-based Software-as-a-Service (“SaaS”) offering to provide ITSM support services and capabilities. At initial implementation, the desired system must replace items 1 – 4 in the preceding section and it must have the capability of expanding to include items 5 – 7 in the preceding section. ODOT has approximately 5,000 employees who will require access to the system for Request and Incident submission. Of the 5,000 there are approximately 252 IT personnel who will require varying levels of access to the different components, modules and functions within the ITSM system. The following is a rough breakdown of IT roles:

1) Service desk: 16 users

2) Asset management: 4 users

3) Administrative: 2 users

4) Resolver groups: 230 users Responses to this RFI must include how a cloud-based SaaS replacement for the ITSM system will meet the requirements described below. The SaaS replacement must:

General Requirements

1. Integrate with ODOT’s Entra or on-premises Active Directory to manage authentication and authorization.

2. Be available, 24 hours a day, 7 days a week, 365 days a year at least 99.8% of the time.

3. Synchronize with ODOT employee data (Workday, Active Directory) for automatic creation of new employee records and automatic updates to attributes of existing employee records (e.g., location, phone #).

4. Include a mobile app that includes, but is not limited to, the following: request and incident submission, updates, status, etc.

5. Exchange data with source systems or systems of record. An Application Programming Interface or other mechanisms are preferable to flat file import and export.

a. Asset Accounting System

b. Financial Accounting System

c. Configuration Management Database

d. Procurement System

6. Be compatible with, and adhere to, ODOT’s preferred technology stack which includes, but is not limited to, the following:

a. Windows Server

b. Microsoft SQL Server

c. IIS

d. C#

7. Comply with ODOT’s cloud use requirements which include, but are not limited to, the following:

a. Encryption of ODOT data, in transit and at rest.

b. Support for Entra ID Single Sign-On via Security Assertion Markup Language or OpenID Connect.

c. The State of Oregon retains ownership of the data.

d. ODOT has the ability to extract all of its data from the SaaS offering on demand.

e. The service incorporates data loss protection into its design.

f. ODOT data must not be stored outside the continental United States.

g. Supplier must remain current with security patches and operating system patches for the servers and systems supporting the SaaS offering.

h. Supplier must have an active intrusion detection and response practice and report any breaches to ODOT within 24 hours of detection.

i. Supplier must comply with the applicable requirements set forth in DAS Oregon Statewide Information Technology and Security Policies, which may be amended from time to time: Department of Administrative Services : Statewide Policies and Guidelines : State of Oregon

j. Supplier will have third-party security audits at least once every three years and provide ODOT the audit results.

8. Integrate with Azure DevOps code management for any customizations (or similar code management capability).

9. Support non-IT business cases (e.g., employee onboarding).

10. Provide system administration and configuration without code or significant redesign or recreation of artifacts—a system that is easily changed with business change.

11. Provide licensing structure and breakdown and access descriptions by license type, where relevant, for the different components, modules, systems, and subsystems for the ITSM system.

Incident Management Requirements

1. Include a dedicated incident console or module for creating customer incidents and managing them through their lifecycle.

2. Include an incident dashboard with Key Performance Indicators (“KPIs”) of incidents to include, but not limited to, the number of incidents by status, priority, and resolver group.

3. Relate a user to an incident and have a unique tracking number.

4. Populate fields in a ticket with pre-determined information using a template.

5. Categorize incidents operationally (what action needs to be done) and by product type (tangible or virtual IT asset).

6. Categorize incidents by urgency, impact and priority with service level and time alerting and reporting.

7. Escalate and assign incidents to different resolver and support groups.

8. Relate an IT asset or IT service to an incident.

9. Email the customer from an incident or a message and have that communication added to a work log within the incident.

10. Look-up knowledge articles from an incident and relate it to the incident and initiate the creation of a new knowledge article from an incident.

11. Add attachments to the incident with no file size limit.

12. Include a time-stamped worklog for tracking the work being done for the incident.

13. Create an incident with multiple tasks that can be assigned to various resolver groups.

14. Include an audit log that will show all action taken on an incident by user, date, time and attribute changed or updated etc.

15. Allow incidents to be automatically created from an email.

16. Generate an email inviting the customer to complete a survey when Incidents are closed and ensure survey data is collected and available for reporting. The email and survey must be configurable with low or no code.

Asset Management

1. Have a dedicated asset console or module for inventory and tracking to include, but not limited to, hardware, software, software systems, servers, network equipment and other related IT assets. Be able to manage the lifecycle of an asset from within the console or module.

2. Track license keys for software.

3. Track subscriptions for licenses, support and maintenance with an alert system for upcoming renewals.

4. Connect to the System Center Configuration Manager (“SCCM”) to import computer system information (e.g., installed software, tag number, serial number, last scan date etc.). Alternatively, have an out-of-the-box scanning utility similar to SCCM that can bring in information from computer systems in our environment. Relate a person to a computer system asset record.

5. Include an asset dashboard with KPIs of assets to include, but not limited to, the number of computers and by type, number of installs by software etc.

6. Include an audit log that will show all changes, updates and modifications to an asset record by user, date, time and attribute changed or updated etc.

Knowledge Management

1. Include a dedicated knowledge console or module for creating, sharing and managing knowledge articles through the lifecycle of the article.

2. Include knowledge article visibility and management that can be handled at the support group level.

3. Include knowledge articles that can be emailed from within the system to customers.

4. Include knowledge articles that can be added to a customer service portal for self-help.

5. Include an audit log that will show all changes, updates and modifications to a knowledge article by user, date and time and attribute changed or updated etc.

6. Include customizable format and templates for knowledge articles.

7. Be able to search for knowledge articles from all other consoles and modules in the system.

8. Export knowledge articles from the system to a pdf.

9. Include knowledge article approval for articles to be published and visible internally and externally.

10. Include articles that are rich text and that can include screenshots and hyperlinks.

11. Include a rating system for knowledge articles on their usefulness.

12. Include metrics showing how often knowledge articles are searched for, accessed or shared.

13. Categorize knowledge articles.

14. Include the ability for system users to like and comment on knowledge articles.

Change Management

1. Include a dedicated Change console or module for submitting change requests and managing them through their lifecycle.

2. Include a change calendar that shows upcoming changes and the changes listed can be highlighted different colors according to change type and priority or risk.

3. Include a change dashboard with KPIs: number of changes shown by type, priority, risk etc.

4. Relate assets that are listed in the asset console to a change record.

5. Include a flexible change approval process with varying numbers of participants before changes can be added to the change calendar.

6. Include an audit log that will show all changes, updates and modifications to a change request by user, date and time and attribute changed or updated etc.

7. Include different views of changes that are in different stages of the submittal, review and approval process.

8. Include an automated report that can be emailed from the system with a list of upcoming changes.

9. Allow changes to be assigned to a user.

10. Allow changes to be commented on and send a system alert notifying the assignee of the comment.

11. Include templates that can be used for the creation of standard changes.

12. Allow opening of an incident from a change for unsuccessful changes.

Service Request Management and Work Orders

1. Include a dedicated service request console or module that internal and external customers can access to submit service requests.

2. Include service requests that can initiate the creation of an incident or a work order.

3. Include a customizable service catalog with unique forms and workflows for each request type.

4. Include a service request template or form creation that can be accomplished with low or no code.

5. Include a chat or communication mechanism for customers to interact with the support person handling their request.

6. Include an approval process that can be applied to requests.

7. Allow service requests, when closed, to generate an email inviting the customer to complete a survey. The survey data is collected and available for reporting. The email and survey are configurable with low or no code.

8. Include service requests that can be rated with the most submitted or highly rated services showing under a popular requests section.

9. Allow a customer to submit suggestions for future service requests (provide feedback option).

10. Include a search form for requests which can be searched by name, submitter, assignee, type, and keywords.

11. Include work orders that have similar functionality and requirements as listed under incident management.

12. Have the ability to categorize requests and work orders by urgency, impact and priority with service level and time alerting and reporting.

Problem Management

1. Include a dedicated problem management console or module for identifying, creating and managing known errors and causes of incidents.

2. Create known errors.

3. Create a problem.

4. Create a problem from an incident.

5. Search for problems.

6. Search for known errors.

7. Create solutions for known errors.

8. Relate a known error to a change, incident or asset.

9. Include an approval process for solutions and or workarounds to known errors or problems.

10. Relate solutions to known errors or problems to a knowledge article.

11. Include support groups that can submit known errors or problems for review.

12. Have the ability to categorize known errors and problems by urgency, impact and or priority with service level and time alerting and reporting.

13. Include an analysis feature that can track trending of incidents based on templates or keywords being used.

14. Allow known errors and problems to be assigned to different support groups for investigation.

15. Allow known errors and problems to be liked or upvoted.

Reporting

1. Include a dedicated report console from which reports can be run for information from all other ITSM consoles and or modules. All fields and attributes contained in those modules are available as fields that can be added to reports.

2. Include low code or no code report creation.

3. Allow reports to be exported to: Word, Excel and PDF.

4. Custom reports may be created.

5. Reports can be set-up on an automated schedule to be emailed in various formats to specified users.

Response Content This RFI does not constitute a solicitation for bids or proposals.

Responses submitted hereunder are voluntary, non-binding and do not create obligations, or confer any rights, on any party. This RFI does not constitute a solicitation for bids or proposals, or a guarantee for a solicitation. This RFI cannot be used to issue the award of any contract or agreement. At any time, ODOT may request additional information from any supplier and may terminate this RFI without incurring any liability to any supplier. By submitting a response, each supplier expressly waives claims for any costs and expenses the supplier incurs in connection with preparation and submission of a response to this RFI.

At a minimum, interested firms should include the following general information in their response.

1. Legal name and address of the company.

2. Name, telephone number, and email addresses of key contact person(s).

3. A short description of supplier’s general experience and qualifications with ITSM systems.

4. A general description of the functionality and offerings of ITSM provided by your Company.

5. Please provide written responses that include information on your system that correspond to ODOT’s requirements described under Section 3 of this RFI.

6. Please provide written responses that include information on the following topics:

a. Application interface capabilities and standards

b. Upgrade path to prevent obsolescence

c. Ongoing service and maintenance plan after installation

d. Design path for growth and expandability

e. Administrator and User training program

f. Security standards met

g. User access management administration

h. Archival functionality and retrieval of data including, but not limited to incidents, requests, knowledge articles, and audit trail information.

i. Any references or lists of other customers, especially if they are other state or similar government agencies

j. Your SaaS model and technical requirements

k. Please describe other available features that may be of value that are not part of the response to 4.5.

l. Explain what Americans with Disabilities Act compliance and translation services are provided by your system.

m. Any other ideas, product suggestions or information that would help ODOT understand the breadth of services offered by your application.

n. Please provide a list of qualified implementation partners ODOT could contact if desired.

Public Records This RFI, and responses received from an interested supplier, shall be kept by ODOT and made a part of the public record.

INTERESTED SUPPLIERS SHOULD NOT SUBMIT ANY INFORMATION DEEMED PROPRIETARY OR CONFIDENTIAL IN THEIR RESPONSE.

However, if an interested supplier chooses to submit information they consider exempt from public disclosure as specified in Oregon Public Records Law ORS 192.410 through 192.505, or under the grounds set forth in ORS 367.800 through 367.824, then the interested supplier must clearly designate the portion of its response that it considers exempt and provide a justification consistent with the statutes identified. The State cannot guarantee the confidentiality of any documents or written comments submitted by suppliers in response to this RFI, as it is available under the "Public Records Law”.

By submitting a response to this RFI, supplier grants the State a non-exclusive, perpetual, irrevocable, royalty-free, worldwide license for the rights to copy, distribute, display, prepare derivative works and transmit the response for the purpose of conducting this procurement and to fulfill obligations under Oregon Public Records Laws.

OregonBuys All Suppliers must be registered in OregonBuys to do business with the state and to respond to this RFI. Registration is free. To create a Supplier account, click the blue “Register” button in the top right corner of the OregonBuys website: https://oregonbuys.gov/bso . For registration assistance see Supplier registration guidance (https://www.oregon.gov/das/ORBuys/Documents/SupplierRegistrationGuide.pdf ). Suppliers are responsible for ensuring that their Supplier information is current and correct in OregonBuys. ODOT will accept no responsibility for incorrect Supplier information.

See OregonBuys User Guides located on OPO’s Contracting with ODOT page (https://www.oregon.gov/odot/Business/Procurement/Pages/HowTo.aspx ) for quick reference information regarding common questions from Suppliers when using OregonBuys.

Submitting RFI Response to ODOT Supplier is solely responsible for ensuring its RFI response and all required submittal items, if any, are submitted through OregonBuys in accordance with the RFI requirements. RFIs submitted by any other means will be rejected.

ODOT will not accept responses submitted after the Bid Opening Date and time specified in OregonBuys for this RFI.

ODOT is not responsible for any delays by transmission errors or delays, or for any mis-delivery for any reason. Additional information may be found in the OregonBuys Terms of Use.

It is the supplier’s responsibility to verify receipt of a submitted response.

ODOT reserves the right to invite suppliers that respond to this RFI for system demonstrations or presentations for further information gathering.

Questions and Answers All inquiries, whether relating to the RFI process, administration, deadline, the intent or technical aspects of the RFI, or any other provision must:

· Be submitted in writing via email to the Purchaser identified in OregonBuys for this RFI. The email must include the RFI number and identify supplier’s name and contact information;

· Refer to the specific area of the RFI being questioned (e.g. page, section and paragraph number); and

· Be received 2 business days prior to the Bid Opening Date and time specified in OregonBuys for this RFI.

· Answers to questions ODOT receives will be posted in OregonBuys to ensure that all suppliers base their responses on the same information. Responses to questions provide clarifications and interpretations but do not change RFI requirements.

Notes OregonBuys: This RFI is advertised as an “Open Market Bid” in the OregonBuys web-based eProcurement system (https://oregonbuys.gov/bso/).

Accessibility: The Oregon Department of Transportation is committed to complying with all statutory requirements to ensure that it is providing information that is more accessible to people with disabilities, as required by Section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. 794d), and 36 C.F.R. 1194 Appendix A. This includes information regarding the RFI process. Please contact the Single Point of Contact (“SPC”) identified in OregonBuys (see “Purchaser” and “Info Contact”) to request reasonable accommodation for access, due to a disability, to information related to this RFI . Accommodation requests must be received by the SPC 3 business days prior to the response deadline (see “Bid Opening Date” and time in OregonBuys).

Non-Discrimination: ODOT, in accordance with the Title VI of the Civil Rights Act of 1964, 78 Stat. 252. 42 U.S.C. 2000d to 2000d-4 and Title 49, Code of Federal Regulations, Department of Transportation, Subtitle A, Office of the Secretary, Part 21, Nondiscrimination in Federally-Assisted programs of the Department of Transportation issued pursuant to such Act, hereby notifies all suppliers that it will affirmatively ensure that all business enterprises will be afforded full opportunity to submit responses to this RFI and will not be discriminated against on the grounds of race, color, sex, or national origin in consideration for an award.

image1.wmf