october 6, 2015 2:00 pmpurchasing.nv.gov/uploadedfiles/purchasingnvgov/...the vendor’s proposed...

Amendment 1 RFP 3158 of 50

State of Nevada

Brian Sandoval Department of Administration Governor Purchasing Division 515 E. Musser Street, Suite 300 Lisa Sherych Carson City, NV 89701 Interim Administrator

SUBJECT: Amendment 1 to Request for Proposal 3158

RFP TITLE: Nevada Department of Motor Vehicles System Modernization

DATE OF AMENDMENT: August 26, 2015

DATE OF RFP RELEASE: July 17, 2015

OPENING DATE: October 6, 2015

OPENING TIME: 2:00 PM

CONTACT: Shannon Berry, Assistant Chief Procurement Officer The following shall be a part of RFP 3158. If a vendor has already returned a proposal and any of the information provided below changes that proposal, please submit the changes along with this amendment. You need not re-submit an entire proposal prior to the opening date and time. Revisions to the RFP: Section 1.3.4, Customer Relations and Business Processes, 2nd paragraph is amended as follows:

The vendor’s proposed CRM solution will include the software application and the business strategy. . The CRM solution should include a homogenous enablement of both application and strategy to ensure ease of maintenance, unpredicable adaption enhancements, reliablity of interactive systems, and meet the future business process changes and the subsequent deployments. The CRM solution should include methods, strategies, software, and network capabilities with the goal to improve NV DMV’s resource management and enhance the customer’s experience. In addition, the CRM solution should allow dynamic collection and distribution of data into all core business areas.

Section 4.3, Case Management and Business Process Model is amended to include the following:

4.3.4.5 The vendor’s proposed solution shall support outcome-focused case management.

Section 4.3.11.2 has been deleted.


Attachment L – Requirements Matrix is revised and replaced as follows:

Attachment L - Requirements Matrix -

To open the document, double click on the icon.

If you are unable to access the above inserted file

once you have doubled clicked on the icon, please contact Nevada State Purchasing at

[email protected] for an emailed copy.

Questions and Answers to the RFP: 1. Are vendors providing responses to the RFP only to submit a complete solution for RFP 3158, or is the customer open to looking at solutions which cover parts of the requirement - for instance hardware systems for running the software portions of the solution?

The NV DMV is looking for a vendor to respond to the entire RFP. However, this RFP does not preclude vendors from partnering to provide a consolidated solution. In addition, this RFP allows the NV DMV to purchase hardware/software from the chosen vendor or on its own; thru the State’s bid process.

2. Was an RFI for this project released and/or was there was any additional work done beforehand to receive information on what requirements would be needed?

A RFI was not released for this project. Additional analysis was completed by the NV DMV for completion of the RFP requirements.

3. In 4.1 it states that the solution must include an integrated Oracle software stack and hardware. Where as in 4.1.1 thru 4.1.14 it states that the vendor consider capabilities similar to Oracle like capabilities. Is the RFP open to other solutions other than Oracle or is this a sole source procurement?

The NV DMV desires an Oracle based solution. However, the NV DMV will consider all proposals that meet or exceed the requirements of this RFP.

4. We have the following questions relating to Request for Proposal: 3158 for Nevada Department of Motor Vehicles System Modernization: In the RFP Section 1. Project Overview and RFP and Section 1.4 Goals and Objectives, NV DMV expresses that they are seeking, to “stay “implement a modernized Information Technology (IT) platform that is easy to configure and maintain”, improve customer service, align and automate business processes to be more customer centric, and more. In RFP Section 4.2.21, Cloud Ready, NV DMV also indicates that it wishes to deploy an on-premise solution and then eventually move to Cloud.

a. Can NV DMV re-evaluate and open up its RFP requirements to also evaluate cloud-based SaaS/PaaS solutions from cloud computing industry leaders that can meet its

mailto:[email protected]


objectives both today and into the future? The requirements within the RFP appear to limit participation and competition to one particular solution provider.

As outlined in the RFP, the core solution shall be on-premise. Please see section 4.2.21, Cloud Ready.

b. If yes, can NV DMV please adjust the requirements in the RFP including the evaluation

criteria to evaluate SaaS/PaaS solutions? Leading cloud services providers, with proven customer success can enable the NV DMV to modernize to cloud today, rather than implementing an on-premise solution that will then include all of the unnecessary costs to migrate to the cloud at a later date.

See response in #4.a above.

5. There are places in the RFP where Oracle is specifically called out as a required technology platform and other places where the technology is not specifically noted with the requirement. Is it a requirement to propose a total Oracle solution?

See response in #3 above.

6. Related to question above, is it a requirement to propose an Oracle MDM? Is NV open to non- Oracle MDM solutions?


7. “In Section 4.1 of the RFP; Oracle is specified by brand name (The solution shall include an integrated stack of Oracle software and hardware that provides performance, reliability, and flexibility). Our experience shows that specifications by brand will reduce competition and increase risk. Will the department consider specifying “functionality desired” instead of brand name?


a. If so, will the scoring be fairly assessed by how it will meet the desired functionality and not by brand name?”

The NV DMV follows strict State of Nevada Purchasing and N.R.S requirements for all evaluation and scoring. The current process allows for fair and equitable scoring of all vendor proposals.

8. Given the size and complexity of this initiative, wouldn’t it be prudent to have vendors be required to have at least one of its references include a DMV to confirm the breadth of vendor experience in DMV business function as outlined in the RFP?

The NV DMV will accept all references that meet or exceed the requirements of this RFP.

9. We would like to confirm that what is not permissible under Section 4.2.24.1 is open source software such as DOXYGEN(to document source code) and not open source languages such as Java/.NET/PHP/HTML5 that are used to write many of the available applications in the market.


Refer to entire Section 4.2.24, Open Source of the RFP. The languages that are widely used and employed to build software are permissible as long as it is supported, patched, and secured by vendor.

10. In Proof Of Concept Section 4.5.2.14, point #10 states that “The System shall allow for additional permits to be created such as, but not limited to: Duplicates, Renewals etc.”. We assume this means additional permits for the same customer. However the question is, once a Drive Away permit has expired can it be renewed or the customer should apply for a new Drive Away permit? Please provide more details regarding this use case.

The customer may have an option to renew or apply for a new drive-away permit after expiration. Each permit created by the system shall have its own business rules that dictate if a renewal is allowed; based on statutory, regulatory, or federal mandates. For the POC, the NV DMV will consider all creative solutions that meet or exceed the requirements of this RFP.

11. 4.2.24.5 - All major software vendors include some OSS technology in their COTS solutions. For example, both Java and Linux are Open Source, but have COTS-vendor-specific distributions available. Were these OSS requirements stated in overly broad terms? Would NV DMV consider rewording to clarify the type of exclusion envisioned?

Vendor specific distributions that are secure and supported shall be included. Open Source Software that are not patched, maintained, and supported shall not be accepted as part of the solution.

12. 3.4 How many 10Gb Ethernet ports are available for connectivity to a new equipment?

The following ports are available: 2 switches, 2 per switch, expandable. The vendor shall propose all requirements as part of the RFP response.

13. 3.4 What types of 10 Gb Ethernet ports are available and how many of each; LC fiber SFP+ modules, copper 10GBase-T?

The following ports are available: 2 switches, 2 per switch, expandable SFP+. The vendor shall propose all requirements as part of the RFP response.

14. 3.4 Does the LAN support vLAN tagging? Is it in use today?

The LAN supports vLAN tagging. It is currently in use today. 15. 3.4 Are there separate virtual LANs assigned to the various types of workloads? For example,

production, user acceptance, development, testing, management, and backup traffic workloads? Please list the LANs that are segregated by vLANs.

Yes. The LAN segregation shall be provided to awarded vendor during the requirements phase of the project.

16. 3.4 What is the average response times from your DNS servers at the primary production and secondary DR locations?

The average response is < 1MS.


17. 3.4 Is there a Network Time Protocol (NTP) service enabled on the LANs?

Yes, NTP service is enabled.

18. 3.4 What is the response time for the Network Time Protocol service enabled on the LANs?

The response time for NTP Service is < 1MS

19. 3.4 What contiguous IP addresses are available to use for the new solution?

The NV DMV shall assign contiguous IP address. The IP addresses available shall be provided to awarded vendor during the requirements phase of the sub-projects.

20. 3.4 Does the data center power equipment support 3-phase power to power system racks and storage cabinets? Or, does the data center power equipment require single phase power?

Yes, 3-phase power is available.

21. 3.4 If 3-phase power is preferred, can your data center power equipment support 24kVA outlets?


22. 3.4 If single phase power is preferred, can your data center power equipment support 22kVA outlets? Or, do you have to use 15kVA power outlets? The greater the power rating the higher the concentration of equipment can be obtained per cabinet.


23. 3.4.5.4 Will the new DMV solution be able to leverage the existing MVIT disk backup infrastructure?

The existing MVIT disk backup infrastructure will be available. However, the NV DMV shall work with awarded vendor to determine if existing backup infrastructure can be leveraged. The vendor shall provide infrastructure requirements as part of the RFP response.

24. 3.4.5.4 and 3.4.8 Will the new DMV solution be able to leverage the existing MVIT tape infrastructure?


25. 3.4.8 Approximately how much capacity would be available in the existing Tape and Disk backup infrastructure? Approximately how much storage is in use today for all current DMV applications?

The current tape and disk backup infrastructure is expandable. At present there is no capacity; without expansion.


The estimated production database storage size is approximately 400 GB inclusive of indexes. Note that NV DMV maintains additional non-production environments and the cumulative database size of all environments including production is approximately 2 TB. In addition, the estimated storage of non-database storage that includes reports, job outputs, source code, executables, etc. is approximately 280 GB. We hold data in tape storage whose size could not be computed easily because of the compression factor and those that are scratched after retention period expires. For planning purposes, the use of tape storage can be assumed to be 3 TB. The size of the SQL Server database is estimated to be approximately 800 GB. The NV DMV also utilizes external vendor services to store scanned documents and the estimated storage size is approximately 10 TB. The proposed solution shall require additional storage to store data, documents and other information that are not currently being stored digitally. The vendor shall provide estimated storage requirements as part of the response. The NV DMV shall work with awarded vendor to determine additional capacity requirements prior to procurement.

26. 4.2.5.9 Can you clarify what you mean by “vertical portals”?

A vertical portal typically aggregates information concerning a specific subject or interest area or a specialized corporate portal that provides personalized access to selected information. See Section 4.2.5.9 of the RFP.

27. 4.2.17.9 What is the current NV DMV document system that needs to be interfaced with?

Refer to Section 3.4.8 Computing Infrastructure of the RFP for current NV DMV document systems.

28. 4.2.17.15 indicates that the solution shall integrate with existing NV DMV document imaging; what is the current document imaging solution used by NV DMV – there are four listed in the current environment section? Is it required to interface with existing solution or can the proposed solution provide an alternate document imaging capability?

Yes, the NV DMV shall require the proposed vendor solution to interface with existing imaging solutions. The NV DMV will consider alternate solutions that meet or exceed the requirements of this RFP.

29. 4.2.23.3 and 4.2.25.5 the RFP states a requirement to exclude Open Source Software and GNU licensed products. Are these requirements meant only to exclude OSS software used in creating a custom solution? In other words, does this exclusion not apply to OSS technologies embedded within a COTS product? See response in # 11 above. 30. 4.2.25.3 the RFP mentions a requirement to support the Microsoft Spartan browser. Microsoft now calls this browser Microsoft Edge. The MS Edge browser was not officially released until July 29, 2015 (after the release of the RFP). It also requires Microsoft Windows 10 while NV DMV’s standard client platform is listed as Windows 7. Does NV DMV want the solution to


currently support Windows 10 and Microsoft Edge, or does NV DMV want the solution to be capable of supporting MS Edge in the future within a reasonable timeframe?

With System Modernization, the NV DMV is looking to expand the portfolio of services offered through portal. Customers who choose to avail our alternate services may be using Windows 10 and running EDGE. Though NV DMV current standard client platform is Windows 7, the proposed solution shall not restrict NV DMV from migrating to future versions of Windows platform and newer browsers as they become available. The vendor’s proposed solution shall support all leading browsers including Microsoft EDGE and any new versions of browsers that might become available in future.

31. 4.2.25.5 the RFP requires a maximum response time of 0.70 seconds during peak periods. The RFP does not specify which functionality must meet this performance requirement. It is not possible to meet this requirement for all activities. For example, printing a permit will take significantly longer than 0.7 seconds due to physical limitations of printing technology. Does NV DMV intend for this requirement to apply only to data entry screens?

The response time is defined as the elapsed time between the request and response by the computer system. Specifically, the time that elapses while waiting for a computer to respond to a command. It does not include the amount of time needed to do data entry or interaction time or printing of documents. NV DMV understands that the amount of time needed to complete data entry on a simple form with few fields would take more than 0.7 seconds.

32. 4.2.25.9 The vendor’s proposed solution shall allow access to a minimum of 1,500 internal, 1 million external registered users, and 500,000 external non-registered guest users. In the Attachment L spreadsheet, tab R03 – Bus Intelligence, the description of item BR03.06 is just a “1”. What was the original text of this requirement? Also, can the state breakdown the counts and types of users and their job functions?

See updates to Attachment L, BR03.06. The vendor shall design the solution to allow access to a minimum of 1500 internal (NV DMV Employees), 1 million external registered users (portal users), and 500, 000 external non-registered users (guest users who do not have a login). NV DMV shall work with awarded vendor to define the job functions and access rights needed.

33. 4.3.1.3 Are ‘alternate platforms’ defined under BR02.02 in the Requirements Matrix as

‘alternative services platforms’? If not, please define or elaborate on ‘alternate platforms’.

The definition of alternate platforms can be found in Attachment L, BR1.50. 34. 4.3.11.2 Should this be under the Siebel section? if it is not then it should be handled by the case mgmt application and not IDM?

See Revisions to RFP above. 35. 4.4.11.2 What is meant by app collaboration? Do you want to have SSO among all the components within the container?


As userid/password schemas are outmoded security constructs, user authentication needs to be designed in such a way to be cost effective and increase productivity for users and applications. From the human element lens (perspective), the use by all authorized individuals to access application using a Biometric ID cards with two factor authentication would be one method for a critical to quality (CTQ) element. From the application to application lens, we would like to see the ability for applications to communicate securely by negotiating an automated sign on reusing elements of the human factor sign on. Yes, the NV DMV will look to the vendor to propose an alternative to meet or exceed the requirements of this RFP.

36. 4.4.11.3 What is meant by low level Single Sign On? Can you elaborate this use case?

A lower level sign on is considered as a secure negotiation between applications without human intervention. It is a behavior we would like mimicked as if two individuals were negotiating a secure communication before executing implicitly secure exchanges of information, while not compromising the speed at which information can be exchanged.

As this is the basis of the request, we would like some assurance that data is not being accessed without permission or knowledge of the agency. This concept holds with our overarching master security model to have built in mechanisms to ensure that data is as safe as possible. While the use of keys for unlocking exchanges is nothing new, we would want the ability to have ensure our secure keys held in escrow with its own encryption algorithm and process.

One such use case would be an application exchange of files using an AES-256 based encryption with Open Application Program Integration (API) before they are transferred online. The escrowed keys would be used to ensure the exchange between the original data uploader and retriever is valid and secure.

Our interest using extensive encryption manifests itself for future expansion of highly sensitive elements of our system to cloud services.

37. 4.4.12.4 Does the requirement mean that NV DMV wants to monitor the entire environment from a single console/interface? Do you want to monitor and do a heath check of all mobile application from a single console?

Yes, to the extent practical. The vendor’s proposed solution shall ensure that NV DMV system administrators do not have to access multiple disparate consoles to monitor and manage environments.

38. 12 Section 12 of the RFP provides strict guidelines about how the 3 parts of the response must be formatted and what their content should be. In section 3.3.1.3, the RFP states that “The vendor shall include the 2015 legislative mandates listed below as part of their RFP response” be. In section 3.3.1.3, the RFP states that “The vendor shall include the 2015 legislative mandates listed below as part of their RFP response”. Should the list be included in “Tab XII – Other Information Material”?


No. The response to section 3.3.1.3, should be included in “Tab XI, Requirements Matrix”. The 2015 legislative mandates are included in Attachment L, BR26, Legislative Mandates (2015).

39. 12 We would like to include items such as Executive Summary (Letter of Introduction), and Solution Overview. Section 12 in the RFP doesn’t specify a place for these items. Please advise in which tabs these items should be placed? Vendors may include this information in Tab III – Vendor Information Sheet. 40. 14.3.20 While we are committed to delivering all critical and secured tasks performed using the resources located on-site, certain non-critical tasks may be accomplished using resources from off-site and/or off-shore locations to both speed up the process and to realize larger savings. Does NV DMV have any conditions and/or restrictions regarding the off-site and/or off-shore resources? If so, please specify.

The requirements for off-site/off-shore resources can be found in this RFP as follows: 6.2 SUBCONTRACTOR INFORMATION 6.4 VENDOR STAFF SKILLS AND EXPERIENCE REQUIRED 14.2.1 Background Checks 14.2.2 14.2.3 14.3.19 Key Personnel

41. BR16.30 Does this include phone conversations and voicemail?

See updates to Attachment L, BR16.

42. BR01.102 Can you clarify this use case to provide more detail?


43. BR01.108 What are the password guidelines referenced in this requirement?

General password details shall be provided to the vendor upon contract award. The current password guideline is as follows and dictated through the State of Nevada Information Security Committee Control # 118. Standard #118 applies to all state entity employees, contractors, and all other authorized users, including outsourced third parties, who have access to, use, store, transmit or manage state data or information within or for the Executive Branch of Nevada State Government. Access to State systems must be adequately protected against unauthorized modification, disclosure or destruction.

44. BR01.10 Can you provide more information regarding the State retention schedules?

See the State’s Retention Schedule as follows:


Http://nsla.nv.gov/Records/State/State_-_Motor_Vehicles 45. BR01.36 - 38 How long should data be retained in the history database?

The NV DMV retains all electronic data indefinitely; per retention schedules.

46. BR01.53 The system shall include an integrated and secure undercover NV DMV functions - Can the state elaborate on this requirement? What does integrated and secure undercover mean?

See updates to Attachment L, BR1.53. Refer to Section 6.4 VENDOR STAFF SKILLS AND EXPERIENCE REQUIRED, 5th Paragraph, for a description of functions.

47. BR01.113 The system shall prevent changes to be made to their user ID, role, etc. - Can the State elaborate on who/role ‘they’ are in this requirement?

See updates to Attachment L, BR1.113.

48. BR11.14 The system shall allow DMV staff to broadcast information through an integrated intranet communication function - What type of broadcast information is the state looking for?


49. BR12.20 The system shall allow a supervisor to remote into the technician's computer to observe activities or transactions - Does the state envision that a supervisor would monitor the telephony system only or remote capability to a computer desktop?


50. BR12.55 The system shall allow a technician to review customer records in any environment such as, but not limited to: Test, System Test, User Acceptance, Production, etc - Does the state envision that each environment would be a copy of the production environment to view customer records?


51. BR01.32 “The system shall allow partial or fuzzy search functionality”. Can you please provide

examples or elaborate on this requirement? See updates to Attachment L, BR01.32.

52. BR01.40 “The system may include ability for digital scanning of hand-written forms”; In section 4.2.17.15 it is indicated that the system shall integrate with current document imaging used by NV DMV, does the current document imaging solution that is used by NV DMV provide hand-written recognition.

The current imaging solution does provide some features that allow for OCR and some hand-written recognition.

53. BR01.41 “The system may include ability for digital scanning of hand-written forms”; In section 4.2.17.15 it is indicated that the system shall integrate with current document imaging

http://nsla.nv.gov/Records/State/State_-_Motor_Vehicles


used by NV DMV, does the current document imaging solution that is used by NV DMV provide hand-written recognition.


54. BR01.53 “The system shall include an integrated and secure undercover NV DMV functions. “; what is meant by undercover NV DMV functions? Is there a list of NV DMV undercover functions?


55. BR01.55 “The system shall integrate with existing customer queueing systems. “; what is the current customer queueing systems used by NV DMV?

The current contracted vendor for the queueing system is QLess Inc. 56. BR24.01 “The system shall interface with existing business partners using the prescribed transport modes. “; Can we get a list of business partners that need to be interfaced with along with the transport modes?

The list of applications/interfaces can be found in Attachment L, Interfaces_Lists.

57. BR19.03 “The vendor shall create a repeatable process to backup data from the training environment from a point in time.” What is the retention policy for backups taken from the training environment?

Currently, there is no retention policy for lower environments. The new retention policy shall be crafted and be based on business needs, when data has become stale, or no longer usable.

58. BR16.20 “The system shall include records management capabilities to tag content for retention and archiving. “ What is NV DMV’s document retention policy – in terms of the duration?


59. BR15.12.1 “• Secure storage of documents, images, and correspondences.” How many document on an average is captured for every transaction within NV DMV? Also what is the typical size of these documents?

The average number of documents will vary, based on transaction type, and may be up to 15 pages. The average size of these documents is approximately 300KB. All documents are scanned in Black/White.

60. General In order to meet certain timelines during the implementation phase, our resources will be working 2nd and 3rd shifts as well as during the weekends and holidays. Would the State provide us the required access to premises, systems and department personnel to meet our collective objectives? If no, what are the restrictions and conditions?


The NV DMV will work with the contractor, based on agreed upon implementation project timelines, to provide the required access to premises, systems, and department personnel.

61. General All major software vendors include some OSS technology in their COTS solutions. For example, both Java and Linux are Open Source, but have COTS-vendor-specific distributions available. Were these OSS requirements stated in overly broad terms? Would NV DMV consider rewording to clarify the type of exclusion envisioned?

See response to question #11. 62. General What are the different Social media channels to be supported?

The solution architecture shall include capabilities to integrate with Social media channels such as, but not limited to: Facebook, Twitter, etc., or any future social media outlets.

63. General Is Fixed Asset maintenance and depreciation in the scope?

A fixed asset maintenance depreciation module may be included as part of the scope. The NV DMV will consider all proposed solutions that meet or exceed the requirements of this RFP.

64. General What is the telephony solution anticipated for the future production system? Any anticipated changes/upgrades? Using any chat functionality? Analytics/reporting created by or from the telephony system? Avaya is noted briefly in a few documents, but versions and expanded functionality for a ‘current’ implementations may impact how a solution is approached.

As part of the RFP, the proposed vendor system shall allow interface capabilities to various available functions in the current telephony system. There no anticipated changes at this time. Upgrades may be available at the time of project planning. The current system provides analytics and reporting that may be included or imported as part of the system requirements. The NV DMV will determine the details of each function during the requirements phase of the project, based on funding, functions available, etc.

65. General Would you please provide a breakdown of system users by criteria such as job role, activity level in the system – such as, are they utilizing the system 100% of the time on the job like a Call Center Agent would or are they more like a casual user that only reviews reports around 5% of the time - and any other criteria you may think is useful?

Division Number of Users

Front/Backoffice % of system use

Director’s Office 36 Backoffice 50% Administrative Services 49 Backoffice 50% Central Services 171 Backoffice 100% Compliance Enforcement 94 Frontoffice/Backoffice 100% Field Services 762 Frontoffce 100% Management Services 16 Backoffice 100% Motor Carrier 52 Frontoffice/Backoffice 100% Motor Vehicle Information 68 Backoffice 100%


Technology External Users Business Partners (Kiosk, Assessors, etc)

Unavailable FrontOffice 100%

66. Reference 1.1.1.2 – In an effort to reduce risk and the impact of change on the organization, this section conveys the state’s desire for the contractor to optimize the project with a concurrent and iterative implementation. In order for vendors to propose an iterative implementation, we would need to modify the cost sheet to reflect the same. Will the state consider modifying the cost sheet for an iterative process or allow vendors to present the iterative plan and associated cost as an alternative proposal ?

The NV DMV will allow vendors to present or propose an iterative plan. However, the proposals must be within the confines of the existing cost sheet.

67. Reference 1.1.3.2 – The RFP states “This RFP provides the WHAT and not the How.”, yet in many sections like 4.1.7 and 4.1.10 there is a specific reference to a technology. Would the State be open to other technological COTS components as long as the “WHAT” is met ?

See response in question #3 above.

68. Reference 3.2.13 – Would the State be open to a pool of change order hours to deal with the future legislative changes ? If so where in the cost proposal can we include them ?

Attachment J, Tab 7.1.10 Rate Sch Change Orders, allows for the vendors to add the required cost for all change orders.

69. Reference 8.4.1. – 30 % holdback is very onerous – would the State be willing to negotiate a different holdback amount or performance bond as an alternative?

Vendors must note as an exception a different holdback amount or performance bond as an alternative on Attachment B – Technical Proposal Certification and Compliance with Terms and Conditions of RFP. The NV DMV is willing to consider holdbacks or alternatives during contract negotiations.

70. Reference Cost Proposal – Attachment J – Would the State be open to breaking down the deliverables into a more granular level to mitigate risk for all parties? E.g. 5.4.2.16 (Modernize System) would have several significant sub deliverables like configuration, detailed design, technical design unit testing, etc. It would be difficult to tie a very large portion of the payment to one deliverable of this size and not have interim progress payments.

Attachment J, Tab 7.1.1 Detl Cost Schedule, allows the vendor to add the additional subcomponents, in the document, to describe the costs associated with the implementation of the project.

71. Reference 1.3.4 –Please clarify the sentence - "The vendor’s proposed CRM solution will include the software application and the business strategy". Also, Can the State provide examples of 'Unpredictable adaption enhancements'.

See Revisions to RFP above. Examples are as follows:


The NV DMV was tasked to disburse excess State funds to Nevada citizens, based on vehicle registration fees, as required by mandated legislation (Nevada Rebate Project). The NV DMV was tasked to identify vehicle owners who do not carry liability insurance.

72. Reference 3.2.12.2 –Is it a fair assumption that the Existing Sharepoint Server can be utilized to create the repository for the Project collaboration? Is State open to creating the collaboration repository in Cloud, in case State hardware licensing procurement would not allow the product development and collaboration environment to be brought up within a month from the project kick off date?

The Cloud collaboration solution is not an option at this time. The NV DMV shall work with the vendor to determine optimal solution for project collaboration.

73. Reference 4.1– While Section says that the RFP does not dictate the technology components, it lists various technology pieces as example and some are identified as the technology to use such as Exadata, Oracle Database Vault, OPA, Oracle GL, and Inventory management. Does that mean that the vendor is mandated to use products not prefixed with "such as" ?


74. Reference 4.2.2.1 –Is the State using the Exadata and Exalogic as example of engineered system or requiring the use of these servers?

Refer to Section 4.2.2.1 of the RFP, which states that “The vendor “Shall Consider”… See response in #3 above.

See response in #167 below.

75. Reference 4.2.15– Does this refer to consent of the Customer for sharing information for various record sale purposes? If not, can the State clarify the details behind the business requirement for this item?

No. This section refers to having a data consent management tool that allows PII data to be segmented, controlled, and protected. This management tool will provide a way to audit data usage and reduce unauthorized data inquiries.

76. Reference 4.2.17.4– What data is being proposed to be OCRed here ?

The data to be captured may include all data elements that are described in the various documents, forms, reports, etc. described in Section 4.2 Electronic Documents and Records Management System (EDRMS).

77. Reference 4.2.18– In this section there is a graphic of the portal architecture – Can the State please provide additional text/description for this graphic to provide details?

The suggested Enterprise Portal architecture is a generalized enterprise portal reference architecture that provides insight into the functionality desired. The vendor shall propose best-in-class Enterprise Portal Architecture that integrates information from disparate sources or applications and offers ability to personalize navigation, data or content, and


layout. The portal Management Support Online (MSO) shall offer comprehensive range of governance, management, operational and administrative resources. The suggested architecture illustrates access to application services through SOA platform.

78. Reference 4.2.19– Please clarify - Is this referring to the Crypto APIs used by Microsoft? https://en.wikipedia.org/wiki/Data_Protection_API

The reference to Microsoft is to provide context to the requirement. The deliverables the NV DMV is seeking are more reflected in the concept of Enterprise Application Integration (EAI) which uses software and computer systems architectural principles to integrate the various enterprise applications. The ultimate response would be an integration framework composed of a collection of technologies and services which form a middleware to enable integration of systems and applications across an enterprise.

79. Reference 4.2.25.12– 60 times the ratio of normal business will create significantly high resource requirements for the infrastructure – is the State’s intent for the vendors to use this as a guideline or propose a system infrastructure for these specifications.

Yes. The vendor should use this as a guideline for the proposed system.

80. Reference 5.4.2.19 Training Plan– What will be extent of Vendor's involvement in arranging for/scheduling trainings? Is it expected for the vendor to train the entire user group in the State vendor. Please provide more clarity on this.

The vendor shall work with the project team to develop the training plan and schedule for implementation of the sub-projects. The vendor may propose training plans, alternatives, and training solutions that meet or exceed the requirements of this RFP.

81. Reference 5.4.2.24 Customer Support – What will be Vendor's role in customer support? What kind of training support will be needed for NV DMV's staff?

The vendor shall provide training to customer support team to help them become self-sufficient in the developed system. Training support shall include such as, but not limited to: guidance, training (to include hands-on), system help, online videos, documentation, operating manuals, etc. The support will also include resource availability (Human, system, or alternative training resources) to maximize the self-sufficiency of the NV DMV customer support staff.

82. Reference 4.3.2.1 – What are the social networking platforms that we intend to interface with?

The vendor shall propose a solution that enables NV DMV to, in future, integrate with social networking platforms including but not limited to Twitter, Facebook, etc.

83. Reference 4.3.2.1 – Which mobile platforms are to be targeted for customer transaction processing? Is there any requirement for integrating social platforms with mobile application? Are there some example use cases of integration use cases that the Agency can please provide

The vendor proposed system shall include industry standard platforms and allow for any future platforms. See response in #82 above. See Attachment L for examples of use cases.

https://en.wikipedia.org/wiki/Data_Protection_API


84. Reference 4.3.7.1 – Is there any existing tool being used for web-conferencing? Is there a use case for this web conferencing with the End customer, citizen also, or it is primarily being looked at as internal collaboration tool

The NV DMV currently has licenses for “GOTO Meetings by Citrix”. At this time, only an internal collaboration tool is required. The NV DMV will consider a proposed solution that meets or exceeds the requirement of this RFP.

85. Reference 4.2.13.6 – Does NV DMV want to build a complete, comprehensive Enterprise Data

Warehouse (EDW) structure to deliver their BI and Analytics requirements?

Yes. The vendor shall recommend the EDW structure and include it in their proposed solution.

86. Reference 1.4.4.8 – Does DMV have following security devices / solutions/licenses which can be reused – 1) Network Security controls – Firewall, IPS, Network DLP, Network Access Control, anti-DDOS, anti-APT etc. 2)Application Security controls - Web Application firewall. 3) Host Security controls – HIPS, Endpoint Security, Host DLP, File Integrity Monitoring etc. 4) Data Protection controls - Encryption tools, Database Activity monitoring etc. If yes, please share details. If not, is the bidder expected to provide, implement and/or manage these tools?

Yes. 1). Provided by the State EITS Division. 2). Provided by State EITS Division. 3). Provided by State EITS Division. 4). No. The NV DMV will work with the vendor for the proposed data protection controls; based on the vendor’s proposed system.

87. Reference 4.2.27 – Are the Data Centers(DCs) in Las Vegas and Carson City to be set up as Greenfield DCs or are they already established in terms of hardware and software including security tools?

The vendor shall assume Greenfield DCs. However, NV DMV will work with the awarded vendor to determine if the existing hardware/software, if any, can be reused.

88. Reference 4.4.2.3 – Is the bidder expected to provide a network based sandboxing solution?

Yes. See response in #167 below. 89. Reference 4.4.12 – Is Vulnerability Assessment/Penetration Testing of the infrastructure to be provided by the vendors? If yes, please let us know if there are any specific requirements for this or the State wants the vendors to recommend solutions.

No.

90. Section 4.2.17. Would the current Document Imaging systems such as Kodak, WebXtender, ASD Document Imaging and Colfax continue to be in use in the To-Be world?

Yes.


91. Section 4.1.2. Is there any specific reason for DMV Nevada to prefer the Oracle stack of Products?


92. Section 4.1.2. Will DMV negotiate Oracle Product Licenses directly with Oracle ? Or do you want the vendor to include the license cost as part of the RFP quote.

The vendor may include the license cost as part of the response. This RFP allows the NV DMV to purchase hardware/software from the chosen vendor or on its own; thru the State’s bid process.

93. Section 1.3.4. Please specify if the existing online application portal will be retained or a new application is required.

The NV DMV shall require a new application to be created as part of the vendor solution. 94. Section 4.2.25.9. Please provide the number of total and concurrent users accessing your portal today?

Approximate values: Total Portal users: 495,000 Concurrent users: 80-90

95. Section 1.3.1. Please provide us with list of services on the to-be CRM system.

See Attachment L, BR11, Customer Relationship Management. 96. Section 4.3.9.5. How many automated alerts need to be scoped?

The current system sends customer alerts up to 4 times. However, the detailed requirements shall be defined during the requirements phase of the sub-projects.

97. Please specify if the future application is expected to be multi-lingual and if so, the languages to be supported.

Currently the NV DMV does not support multi-lingual application. However, the NV DMV will consider all proposals that meet or exceed the requirements of this RFP.

98. Section 1.4.17. What are the manual processes that need to be automated? Please provide us the business processes required to be supported.

Section 3.2.9, DMV Current Processes and Functionality, provides a diagram of all manual and system processes currently used in this RFP. Manual processes have been incorporated in the requirements listed in Attachment L – Requirements Matrix.

99. Section 4.3.9.5. What are the different modes in which alerts need to be sent ? E.g.. Email, SMS,etc.


Alerts should be incorporated as allowed by technology, legislative mandates, or future technological advances. The detailed requirements shall be defined during the requirements phase of the sub-projects.

100. Section 4.2.25.7. What is the cut-over window available for the new system including data migration and code deployment?

The NV DMV shall work with the awarded vendor to determine migration and code deployment timelines. The current NV DMV migration is completed monthly, Sundays, between 2:00 AM and 7:00 AM.

101. Section 1.3.4. Is there a need for portal to have in-built “user management” capabilities where the users are categorized according to roles(each having a certain set of privileges)?

Yes. Refer to Sections 4.2.7 Privacy, Security, Identity, and Access Management, 4.3.8 User Administration – Identity and Access Management, and Attachment L, BR01.91 – BR01.114 of the RFP.

102. Section 1.4.6.. What is meant by “unauthorized data injection” into the DMV system? What is the expectation from the to-be system?

Unauthorized data injection is a means by where unauthorized data input fields are populated with controls that allow privileged malicious or unauthorized programs to be run. The vendor’s proposed system shall prevent such actions.

103. Section 3.4. What it the expectation on Social Media integration on the to-be system? Is social media data analyzed in the current architecture?

The expected social media may include Facebook, Twitter, Etc. Social media is not analyzed in the current environment. However, the NV DMV will consider all proposals that meet or exceed the requirements of this RFP.

104. Section 4.3.12. Which system is currently being used for booking the appointments, can that be leveraged in the to-be world? Is appointment booking restricted only to hearings(as per RTM) or include other areas?

An internal application and process is currently used for all appointments, which includes both system and manual processes. The currently appointment functionality cannot be leveraged. Appointment bookings may include Drive Tests, Hearings, etc. The NV DMV does not have an integrated appointment scheduling application.

105. Section 4.3.12. Is there a requirement to build any integration with MS Outlook?

Yes. 106. Section 4.2.25.9. What is meant by 500,000 external non-registered users? What are their typical capabilities of non-registered users?

Non-registered users are customers that are not registered through the NV DMV myDMV Portal. These users may do various online transactions such as, but not limited to: Vehicle registration Renewal, DL Renewal, Driver History etc.


107. Section 4.2.25.9. There are 1 Million registered portal users. During migration, will we have access to the existing user ids and passwords to be ported on to the new system or can these users sign up afresh on the new portal application?

The NV DMV will work with the awarded vendor, during the conversion sub-project to further define the requirements. The NV DMV may consider that users re-establish their identity and choose a new password in the proposed system.

108. Section 3.2.12.3. Is there a clean source of data to be migrated? Or is data cleansing part of scope? If so, what are the requirements on data cleansing?

As outlined in the RFP, the majority of the data is clean. However data to be imported from third party applications and manual processes may require cleansing. NV DMV resources shall assist and work with the awarded vendor to finalize data cleansing requirements.

109. Section 3.2.12.3. What is the format of Legacy Data?

Most of the legacy data resides on the relation database (DB2). See Attachment L, BR08. 110. Section 3.2.12.3. What is the approximate data Volume for each entity (DL, Vehicle Registrations, Vehicle Plates, etc.)?

Approximate count: License Plate: 2,277,307 Vehicle Registration: 2,331,250 Driver License: 1,881,963 See Attachment L, BR08.

111. Section 3.2.12.3. Please specify the period of time historical data is required to be migrated in the system.

The question is unclear. If the question is how much data must be converted, see response in #45 above. If the question is when conversion shall take place, see section 5.4.2.15 Project Schedule.

112. Section 08-Conversion. Please let us know the kind of data present in non-core systems, that account to around 10% of the data volume. Do they correspond to entities that will be part of the to-be CRM system? If so, please provide the counts.

The NV DMV has one application completely developed and maintained by a vendor, which is not part of the core system. The kind of data from this application is similar to that of our core system. This data comes from the daily Motor Carrier fuel tax transactions done by NV DMV employees tied to business and individual records. This application and the corresponding data will become a part of the to-be CRM system. The volume of data pertaining to this application will be approximate 2,000,000 rows spread across dozen different tables.


113. Do you require P2P in Oracle apps? Are you planning to implement payables, purchasing in Oracle apps?

The NV DMV will look to the vendor to propose a P2P application; if required. See response in #167 below.

114. How many sites are to be implemented in Oracle apps?

The question is unclear. The NV DMV is replacing the entire system. See response in #3 above. See response in #167 below. Refer to Section 3.2.4, DMV Field Offices and Assessors office and 3.2.10, DMV Current Network of the RFP.

115. Section 1.3.3.2. Are there any integration requirements with external Journal systems? E.g.: State’s Financial System, AMS Advantage 2000.

Section 1.3.3.2, refers to interfacing with other business partners; not to integrate with the external applications. The NV DMV shall require the proposed system provide interface protocols such as web-services, SFTP, etc. The interface requirements shall be defined during the requirements phase of each sub-project.

116. Are there any integration requirements with 3rd party financial systems? e.g.: For credit cards, receivable transactions etc.


117. Do you carry out certain activity as projects? If yes, do you bill your customer through the projects? In this case PA module might be required.

The NV DMV will bill customers based on various functions, such as revenue recovery, or motor carrier invoicing. All project related activity invoicing is billed from the State’s system not the NV DMV.

118. Are you using any scheduling tools for the above mentioned projects?

No.

119. How are employee expenses currently managed? Is iExpenses to be implemented? Could it be

used in conjunction with Oracle MAF as mentioned in the RFP? The NV DMV uses the State’s Human Resources (HR) system for all employee expenses. It is not the intent of this RFP to replace the State’s HR system.

120. How are timecards for employees currently managed? Could OTL be used in conjunction with Oracle MAF as mentioned in the RFP?

The NV DMV uses the State’s HR system for all employee time management. It is not the intent of this RFP to replace the State’s HR system.


121. Do you required HRMS in Oracle apps or are you planning to use other systems like People- hub?

The NV DMV uses the State’s HR system for all Human Resource management. It is not the intent of this RFP to replace the State’s HR system.

122. Section 1.1.7. How is Master Data Managed in the current application landscape? And which application will be the source of truth whilst migrating data?

The existing NV DMV application does not have a comprehensive Master Data Management solution in place. The identities of core customer information (names and addresses) are managed through custom application using Informatica IDS (Identity System) and QAS (Experian Quick Address System). Our current integrated NV DMV application, residing on a Mainframe and are the system-of-record for all data.

The system-of-record will be the data residing in a core DB2 database. The conversion requirements shall be defined during the requirements phase of the sub-project.

123. BR10 - Cust Data Integrity. As per our Understanding as part of Customer Master Data, the expectation is to Capture Information on both Individuals(e.g.: Driver) and Organization( e.g. Attorney company name). Could you approximately provide the Volume of Individual and Organization records that you currently have?

Approximate Count: Individuals: 9,670,000 Businesses (Organizations): 620,000

124. BR10 - Cust Data Integrity. We understand the requirement for capturing name, address, contact information for Individual and Organizations. Is there any requirement to capture and master, additional information like hierarchies or Relationships among organizations and Individuals?

The vendor may propose alternate hierarchies, relationships as part of their response. The NV DMV will consider all proposals that meet or exceed the requirements of this RFP.

125. BR10 - Cust Data Integrity. Is there any documentation around the Customer Master Data Management process (Creation, Deletion and Updation)?

The NV DMV shall provide all documentation to awarded vendor, if deemed appropriate, to assist awarded vendor design and implement a robust solution.

126. BR10 - Cust Data Integrity. We understand that ERP-CRM and ODS would be Source/ destination for MDM Solution Landscape. Would any additional legacy system also be part of solution landscape. Would the Customer master data be created from multiple systems in future as well?

The scope of this project is to replace the existing system hardware/software, processes, etc., as defined in this RFP. Existing systems will not be part of the solution landscape.


Customer master data shall be created from/in a single source/system as defined in the vendor’s proposed system.

127. BR10 - Cust Data Integrity. Please specify if any means of identifying duplicates through a combination of attributes is already specified by the business (e.g.: Name or Name and Address or SSN etc.)

The NV DMV currently has a manual and systematic process to identify duplicate customers. The NV DMV will consider all proposals that meet or exceed the requirements of this RFP.

128. BR12.50/BR12.51. Can you specify which systems would require real time integration with MDM system? Which systems would need a batch interface?

The “system” in BR12.50/BR12.51 refers to the integrated solution that is being proposed. Based on the proposed solution, the NV DMV will work with the awarded vendor to help determine systems that require real time integration and those that would need batch interface.

129. BR10 - Cust Data Integrity. Please specify the approximate percentage of duplicates that is existing within your enterprise, if you have carried any such profiling exercise in recent past

The current number of customer duplicates is +- <1% of the customer data.

130. Where "Production Support instance" will be set-up to replicate critical production issue.

The NV DMV shall work with the awarded vendor to determine Production Support Instance requirements. The NV DMV is looking to the vendor to propose a solution to meet production support issues and will consider all proposals that meet or exceed the requirements of this RFP.

131. What is the EBS application and database version and size?

The NV DMV does not have an EBS application. 132. How code will be migrated to pre- production system from DEV instance and then production instance and who will be responsible for this?

The NV DMV is looking to the vendor to include this item in their proposals. The NV DMV will consider all proposals that meet or exceed the requirements of this RFP.

133. Pls. provide the current system landscape with the interfaces and databases. (Diagrammatic representation)

See diagram in section 3.4 Current Computing Environment of the RFP.

134. Are there any metrics used for assessing Performance currently?

The NV DMV current metrics include system and manual statistics captured and used for assessing performance.


135. Are there any custom scripts or tools in place for: 1) Monitoring of databases and applications(like OEM - Oracle Enterprise Manager)? 2) Patching of eBusiness suite instances?

No. See Section 3.4, Current Computing Environment of the RFP. 136. How many patches (including database and application) are applied on an average per instance/application per month?

At this time, the NV DMV has a production build once a month. For the future environment, the NV DMV will look to the vendor to propose alternatives that meet or exceed the requirements of this RFP.

137. What are the scope of activities covered under DBA consulting? And will it be limited to Non- Production Instance or Productions Instance as well?

The NV DMV DBAs will be available to assist and manage database environments. The NV DMV will not require or solicit DBA consulting separately.

138. Are the DBA support services (System Administration, Monitoring, Maintenance, Performance issue, Troubleshooting, backup/recovery etc.) required from AMS provider for production instances?


139. Please describe the current cloning methodology from Production? How many cloning activities (including application and database) will take place per month?

The NV DMV has a custom cloning methodology leveraging DB2 utilities to clone data. In addition, the NV DMV is currently working on configuring IBM OPTIM TEST DATA MANAGEMENT tool to extract and load specific sets of privatized/masked data to non-production environments. Databases are cloned on demand. The NV DMV will look to the vendor to propose alternatives to data cloning required to test and maintain the proposed solution that meets or exceeds the requirements of this RFP.

140. Is there a plan to maintain Production and non-production tickets separately by helpdesk ? In that case Will production tickets be routed directly to OOD ad non production tickets will be routed to AMS?

The NV DMV shall be the source for all tickets. The detailed plan for production tickets will be sent to appropriate resources based on SLAs.

141. Please provide relevant hardware details for all nodes:?; For all nodes of DB Tier and Oracle EBS Application Tier ?; System Model: ?; Processor Type: ?; Processor Clock Speed: MHz?; Number Of Processors: ?; Kernel Type: ?; Memory Size: ?; Platform Firmware level: ?; External Storage details (vendor, storage type and capacity)?; Is will be anticipated growth?

The NV DMV will look to the vendor to propose the solution architecture and the recommended infrastructure requirements as part of this RFP response.


142. Please provide the below details for DBA support:

1) Number of environments that AMS need to support? 2) Architecture? 3) Topology? 4) OS Platforms and versions? 5) Applications and Versions.

The question is unclear. The vendor shall provide knowledge-transfer, see Section 5.4.2.26 Knowledge Transfer Plan of the RFP. In addition the vendor must meet post production SLA’s, see question #200 below. The vendor shall provide the required DBA resource as part of implementation; therefore, the NV DMV will look to the vendor to provide support to entire system. Once the application (sub-projects) has been move to production and the post production support has been completed the NV DMV shall take ownership of system/applications, etc.

143. Do you have any special configurations? E.g., split configurations i.e. DB node and Concurrent/admin node on different OS? If yes, please provide details.

The NV DMV does not have special configurations at this time. The NV DMV will look to the vendor to provide the recommended configurations. The NV DMV will consider proposals that meet or exceed the requirements of the system.

144. Have you implemented Load balancing for forms or web servers? If yes, please provide details

The NV DMV currently uses Microsoft NLB and we are moving to F5. 145. How many languages are installed/set up in Oracle EBS?

See response in #131 above. 146. Please provide details about backup strategy and information about type of tape drive, time taken for backup of the database and application layers and any software's used for taking backups.

The NV DMV currently uses Commvault, ML6020 tape library for backups. The backup information shall be provided to the awarded vendor, if appropriate. The NV DMV will look to the vendor to propose alternatives to system backups/strategy based on the proposed system. The NV DMV will consider all proposals that meet or exceed the requirements of this RFP.

147. Please describe the current data retention and data archiving policies, if any? Please provide details of tools used for archiving, if any (e.g., Application, etc.).

See response in #44, #45, and #146 above.

148. How is the current implementation DBA team structured?


The current DBA team is structured to handle existing DB2 and SQL Server databases. The Enterprise Information Technology Services (EITS) division within Department of Administration currently handles patching and upgrade of databases. NV DMV has 3 full time DBAs who manage the current environment. The NV DMV will look to the vendor to propose recommendations to DBA structure, as part of their response, based on the proposed system.

149. Pls. provide the different types of reports along with the parameters, frequency and access levels.

The frequency of current reports for internal customers are: on demand, daily, weekly, monthly, semi-monthly, quarterly, annual (yearly) and Semi-annual. The NV DMV provides printed reports, reports via FTP, and reports via intranet access from the batch processes. The objective is to minimize printed output. The NV DMV creates daily, weekly and monthly analytical and statistical reports such as, but not limited to: Transaction counts, Vehicle and Registration, Driver License, License plates, etc. The NV DMV is looking for the vendor to provide a reports management system. See Attachment L, BR37.

150. Where is DRS site?

The current Disaster Recovery process relies on EITS services to replicate storage to the DR site. Refer to Section 4.2.27, Disaster Recovery of the RFP, for details. The vendor shall propose DR strategy that meets the requirements outlined in the RFP.

151. How is the DRS setup?

The DRS setup/configuration shall be provided to awarded vendor; if appropriate. The NV DMV will look to the vendor to propose DRS configuration as part of their proposal that meets or exceeds the requirements of this RFP.

152. How much time does it take to switch to DRS?

The current switch to the DRS is manual. See response in #151 above.

153. Is DRS configured as production to handle user load?

Yes. 154. Is there somebody always present at DRS and PROD environments?

See response in #151 above. 155. How the DRS gets updated regularly?

This question is unclear. If the question, how often does the DRS get updated regularly? The response is daily. See response in #151 above.


156. NV DMV Att Interfaces.xls. The sheet seems to mention source system. Can you please provide target systems as well?

There are no multiple target systems. The NV DMV requires one complete integrated target system as the end product.

157. NV DMV Att Interfaces.xls. What is layout information in context of SOA. Is this the message payload?

This message may contain payload, message structure, meta-data, or any such information required to build a SOA based application. The requirements of the message shall be defined during the requirements phase of the sub-projects. The NV DMV will look to the vendor to recommend the message payload that meets or exceed the requirements of this RFP.

158. 69. NV DMV Att Interfaces.xls. If the interfaces are to be migrated to SOA platform, is it safe to assume that the same will be re-written/ developed to adhere to SOA design patterns?

Yes.

159. NV DMV Att Interfaces.xls. The interfaces present in the list which are already active; are they expected to be used as is (even if they are non web services)?

The interface end-point shall be the same. However, some external interfaces have more industry standard interface protocols that shall be used. The interface requirements shall be defined during the requirements phase of the sub-projects.

160. NV DMV Att Interfaces.xls. Can you please provide response time for each interfacing systems in current landscape.

The response times may vary depending on the interface. The NV DMV wants to improve response times as defined in the RFP.

161. NV DMV Att Interfaces.xls. For communication between two interfacing systems what is the maximum message size that is supported today.

The message size may be up to 100 MB, with a potential to grow in the future. 162. NV DMV Att L Requirements Matrix.xls. Have you identified any rule engine for business function transaction? Can you give few examples of simple, medium and complex rules?

No. The business rules shall be defined during the requirements phase of each sub-project.

163. NV DMV Att L Requirements Matrix.xls. What kind of data needs to be searched ? Please specify partial search. Most partial search e.g. N* might result in degradation of system performance. Also please give example for fuzzy search.

See updates to Attachment L, BR01.31 and BR01.32.


164. NV DMV Att L Requirements Matrix.xls. As per the requirement 'The system shall allow transactions to be deleted/voided prior to completion'. Please elaborate the scenario of incomplete transaction with an example.

Example scenarios are: A customer comes into the NV DMV to get to initiate a financial transaction and does not have the correct amount of funds to cover transaction. Another would be, the customer requires a credential and they do not have the required documentation to complete the transaction.

165. NV DMV Att L Requirements Matrix.xls. As per the requirement 'The system shall include a transaction rules engine to create and maintain definitions, rules, General Ledger, etc.' Please elaborate with example the functionality of transaction rule engine.

The system shall allow for all NV DMV functions that require a transaction, monetary and non-monetary, to be executed. Some examples include: a transaction may be defined and include any additional costs associated with the specific transaction such as, but not limited to: Taxes, fines, penalties, etc. During legislative sessions, the NV DMV may be required to add an additional fee, tax, or penalty to specific transactions. The rules engine would allow for these added fees or functions to be included for all future transactions using the rules based engine. The rules based engine shall allow unique transaction definition. Another example would be the specific G/L to be assigned to each financial transaction as part of the rules based engine. Another example would be allowing the creation of an email to be generated once a transaction has been initiated.

166. Section 4.2.14.10. Referring to the SOA technology diagram that has 'API Management' : Have you considered any API management product?

No. The NV DMV will look to the vendor to propose solutions that meet or exceed the requirements of this RFP.

167. Section 4.2.21. In order to make sure that the solution is cloud ready we recommend using Oracle SOA suite 12c. Please let us know if you also agree to the same.

The NV DMV will look to the vendor to propose solutions that meet or exceed the requirements of this RFP.

168. Section 4.4.15. For SSO, we are assuming SAML token will be used. Please confirm if you have any requirement that does not support SAML or prefer some other method of SSO.


169. Section 4.2.4. For policy management, we recommend using oracle web services manager ( OWSM). This will be single place for all policy management. Please confirm if you favor some other way of SOA policy management.



170. Section 4.2.4. Please share your current security policies in general and specifically for SOA too if any. SSO is one of the requirements for security. However would like to know other security requirements like confidentiality, integrity and non-repudiation etc.

The number of security policies is extensive and will be shared with the awarded vendor. Respective of the SSO element of the question, see response in #35 and #36 above.

171. Do you have mapping of business process to interfaces document. This will help us to understand the number of business processes, number of interfaces for each business process, number of operations supported by each interface. (E.g. Business process to issue driver license -> Citizen data interface (GetCitizenAddress operation, VerifyAddressOperation) etc.

The business functions and interfaces are included in Attachment L, Requirements Matrix. A graphical representation of the processes can be found in Section 3.2.9 DMV Current Processes and Functionality of the RFP.

172. Section 4.3.15. Are the Inspectors equipped with handheld devices? Is there a need to integrate with existing hand held devices?

Section 4.3.15 Application Consolidation of the RFP, refers to the consolidation of applications. The requirements for Vehicle inspections can be found in Attachment L, BR42 Vehicle Inspections. Inspectors are currently equipped with handheld devices. This requirement shall be defined during detailed business requirements.

173. Section 4.3.15. Are Tabletss and Mobile phones a channel of service requisition/fulfilment today.

Section 4.3.15 Application Consolidation, refers to the consolidation of applications. The NV DMV does not currently support tablet or mobile services as a service channel at this time. The NV DMV is looking to have this feature available in the future.

174. Section 4.2.5.5. What the devices on which mobility needs to be supported? Will Nevada DMV, procure tablets or will users continue to use their personal smart phones to carry out business transactions?

The NV DMV is looking for the vendor to propose a system that shall support industry standard mobile platforms. The NV DMV will consider all proposals that meet or exceed the requirements of this RFP. The NV DMV may procure tablets or mobile devices for internal use by NV DMV employees. The system shall allow for all functionality to be ported to the alternative platforms.

175. Section 4.2.5.5. Can the to-be system’s in-built mobile/tab capabilities leveraged or is the direction to build mobility on Oracle Mobile Application framework?



176. Section 4.2.5.5. How many screens or business processes need to be enabled on tablets/mobile phones?

See Attachment L, BR01.50 and BR02. The detailed requirements of each function shall be defined during the requirements phase of the sub-project.

177. Would the solution be limited to Oracle suite of products or are we open to try a combination of

Oracle and non-Oracle products? For e.g., using ‘R’ language for statistical analysis along with OBIEE for visualization. See response in #3 above.

178. Requirement Matrix –BR37 – Rpt Mgmt. Are there any reports that are available and do we need to migrate them, if so how many? What is the scope of historical data migration?

The NV DMV will not migrate existing reports to the new system. All new reports shall be generated using the requirements in Attachment L, BR37, Row 6. The conversion scope can be found in Attachment L, BR08 Conversion.

179. Requirement Matrix –BR37 - Rpt Mgmt ( BR37.18 & BR37.19). What would be the data volume and the user base?

The data volume shall depend on the business requirements for a specific function. The user base may include internal as well as external users; depending on system access. For example, a request made to our records division may require several fields requested by law enforcement on a specific vehicle to generate a report. While in other instances, we may need to just know the total number of Specific vehicle types.

180. Requirement Matrix –BR37 – Rpt Mgmt. What all would be the data sources that we would be working with? Apart from flat files and Oracle sources (Siebel/Ebiz/MDM), would there be any third party sources that we would have to integrate with?

The vendors proposed system shall become the System of Record. Therefore, most of the reports shall come from the new proposed system. Some external 3rd party sources may be used to retrieve additional information; using interface protocols (such as web-services, SFTP, etc.).

181. Requirement Matrix –BR37 – Rpt Mgmt. Do we know if there are any non-functional requirements like report performance.

The NV DMV, along with the vendor shall determine the reporting requirements that meet the need of the business function; while taking into consideration system performance, system degradation, or other system impacts.

182. Requirement Matrix –BR37 – Rpt Mgmt (BR37.13). Would reporting be limited to users

within the DMV intranet or is there a need for the reports to be available on the web or even in Mobile?


The NV DMV is looking for report availability to meet the business need. Reports shall be primarily for internal uses. However, the reports may be required to be available on the Web, Mobile, or other platforms as required.

183. Requirement Matrix BR37 – Rpt Mgmt. Apart from data integration that we develop for reporting purposes, are we responsible for developing data-integration between non-reporting systems as well.


184. Requirement Matrix –BR37 – Rpt Mgmt (BR37.14). “The system shall allow reports to be available via a subscription function. “, are you expecting the reports to be delivered to each users, if so how many reports are you expecting to be subscribed/delivered?

Yes. The requirements of each report and delivery shall be completed during the detailed business requirements phase of the project.

185. Requirement Matrix –BR37 – Rpt Mgmt (BR37.03, BR37.04, BR37.05). How many dashboards, canned reports and executive reports are required? Will the detailed specifications be supplied before starting the project?

The requirements of each report and delivery shall be completed during the detailed business requirements phase of the project.

186. Requirement Matrix –BR37 – Rpt Mgmt. Does the scope include data sharing and running reports in combination with other state DMVs as well.

See response in #180 above. Certain reports may require delivery to other jurisdictions. The requirements of each report and delivery shall be completed during the detailed business requirements phase of the project.

187. What are the Functional Areas for which BI is to be implemented? We understand from the RFP that CRM, Financial and Inventory Management (SCM) are in scope. Please let us know if there are any other areas we need to scope in.

BI should be available for all DMV Functions outlined in Attachment L, Requirements Matrix. This will allow the NV DMV to look for business opportunities to better service the NV Citizens.

188. Is there a study conducted to compare the requirements with Oracle provided content?

See response in #2 and #3 above.

189. Are there any existing ETL and scheduling tool currently used? Is there any preference for the same for the new reporting structure?

Yes. Microsoft SQL Server Integration Services and ZEKE (Mainframe). See response in #167 above.

190. What is the timeframe available for data load process that needs to be carried out?


If the question is when conversion shall take place, refer to Section 5.4.2.15 Project Schedule of the RFP. The timeframe for the conversion data load, shall be determined based on how the conversion effort shall take place. The expectation is that data loads would be completed during off-hours, between Saturday and the next business day.

191. What output formats are expected to be supported by the reports?

See Attachment L, BR37.11.

192. Section # 4.2.22. Is the scope of Big Data readiness limited to a consulting endeavor to come up with a framework for Big Data implementation in the future or do we have to build something?

The vendor is not expected to build or implement a Big Data solution at this time. The vendor shall identify opportunities and potential use of Big Data as part of the response. See response in #167 above.

193. Requirement Matrix –BR37 – Rpt Mgmt (BR37.26 & BR37.27). “The system shall print the unique environment indicator on all created reports. “, can you be more specific on this?

The reports generated shall have an indicator such as, but not limited to: Development Environment, Training Environment, User Acceptance Environment, etc., printed on each generated report.

194. What is BI DB used for currently? What reports are being generated from this? Is there any plan to use this for any reporting purposes?

The NV DMV uses SQL Server Analytical Services (OLAP) DB. See response in #149 above. See response in #167 above.

195. Requirement Matrix –BR03 – Bus Intelligence (BR03.06). The Requirement details are missing here.

See updates to Attachment L, BR03.06. 196. Requirement Matrix –BR03 – Bus Intelligence (BR03.11). “The system shall provide hierarchy of performance metrics.” Can you be more specific on this?


197. Requirement Matrix –BR03 – Bus Intelligence (BR03.12). “The system shall provide hierarchy of benchmarking.”, can you be more specific on this?


198. Requirement Matrix –BR03 - Bus Intelligence (BR03.13). The analytics solution will provide data mining and other capabilities. What is expected from 'Process Mining' mentioned here? Please elaborate.

The expected results are to allow the NV DMV to mine data to enhance processes and make decisions that will improve customer service.


199. What is the main driver for the implementation of Oracle Tools and products? See response in #3 above.

200. Section 5.9. Can you please specify the number of years of service level support that DMV is anticipating, specifically after each of the phases goes live?

The NV DMV anticipates the vendor to meet SLAs by subproject up to 6 months post implementation. The duration shall be part of the SLA/SLO negotiations. It is anticipated that the NV DMV shall take ownership of functionality once the subprojects are implemented to production.

201. Requirement Matrix –BR19 – Emp Dev. Do you require integration with any 3rd party external learning system? If yes, please specify.

Yes. See requirements in Attachment L, BR19.49 to BR19.57.

202. Requirement Matrix –BR19 – Emp Dev. In what form is the Learning history data available presently? How many years of data will be part of scope?

The current learning history data is available electronically; allowing use of the current system. The duration of data will be dependent on the relevancy of the data and how stale it becomes. This requirement shall be defined during the detailed requirements phase of the subprojects.

203. Let us know if Organizational change management, will it be in scope for vendor or will be managed by DMV.

This question is unclear. If the question is will the vendor manage NV DMV organization changes: No. The NV DMV shall manage its organizational change. If the question is, will system change management be in scope for the vendor: Yes. The vendor shall include the proposed change management system for all migrations required.

204. As mentioned in the RFP, the Director’s office handles the HRD of NV_DMV. In this case, which system do you use for Human Resources, Compensation, Benefits etc.?

The NV DMV uses the States’ Human Resource system for all Compensation, benefits, etc.

205. With reference to “Requirements Matrix (BR01.52)”, could you please elaborate on what you mean by Integrated research function?


206. With reference to “Requirements Matrix (BR03.03)”, would you be able to specify the different forecasts you deal in NV_DMV in terms of type, timeline.


207. Please specify if NV_DMV ships the License plate directly to the Customer. In that case, would there be a requirement of an Order Fulfilment system?


The NV DMV currently has on-demand-fulfillment functionality for license plate creation. See response in #167 above.

208. With reference to “Requirements Matrix (BR06.300)”, the system shall generate a unique barcode. Is there a requirement for Label Printing?

At this time, there are no requirements for label printing.

209. Post Production Stabilization period is not mentioned. What is the expected Post Production Stabilization timeline for each Go-Live?


210. What are all the existing NV_DMV IT systems, which will not be retired. Please state the application names, purpose, version, interface requirements etc.

The majority of the NV DMV IT systems shall be retired or decommissioned. The NV DMV is looking to replace the existing system hardware/software, processes, etc., as defined in this RFP. Refer to the following sections of the RFP: 1, Project Overview, 2nd Paragraph 1.3, PROCESS AND SYSTEM TRANSFORMATION 1.4 Goals and Objectives 3.2.9, DMV Current Processes and Functionality Attachment L, Interfaces_List

211. Are the sub-ledger functionalities required in the proposed solution including Oracle Accounts Payables, Accounts Receivables etc. or they continue to be maintained in the current system and interfaced to Oracle General Ledger.

At this time, it is anticipated that all sub-ledger functionality be kept with the system of record. Interfaces to the current States’ system shall be required. See response in #167 above.

212. Section 4.2.8: The vendor’s proposed solution shall consider using a Siebel CRM commercial off-the-shelf solution; Are you open for any other application that best suits your requirement?

Section 4.2.8 of the RFP states: The vendor’s proposed solution shall consider… See response in #167 above.

213. Section 4.1.3: The solution shall include Oracle Exadata as an integrated database platform; Are you open for any other platform that best suits your requirement?

See response #3 above. 214. Can any part of the services be rendered from Nearshore and Offshore locations/resources?



215. Is there is a specific timeline for the managed services needs to be included in the proposal?

The NV DMV does not expect to solicit managed services at this time. 216. Is there a LDAP directory service used in the current environment for user account maintenance? If yes, please provide details.

The NV DMV uses Windows 2008 AD.

217. Is there a requirement for migration of legacy data from DB2 to new Exadata. If yes, what would be the type and volume of data?

The awarded vendor will be required to migrate legacy data from DB2. The data to be migrated is mostly standard data types supported by DB2. The volume of data is estimated to be approximately 250 GB (table data only).

218. Please share current CPU/ IOPS utilization from existing system DB and Mainframe.

The current capacity consumption is approximately around 33 MSUs. 219. Do you have any specific CPU /IOPS Upper limit in the proposed implementation. Please specify.

The vendor shall propose a system that shall have enough capacity to meet or exceed the requirements outlined in the RFP. There is no specific CPU / IOPS upper limit.

220. Section 1.3 illustrates the limitations in the current IBM BPM, and the need for a new BPM. Please confirm.

NV DMV does not use IBM BPM. See Section 1.3, Process and System Transformation of the RFP.

221. Section 4.2.6.3: Is IBM Message Broker used as Service bus in the current system needs to be replaced?

The current system does not use IBM Message Broker as a service bus. 222. What are the different system that need to be integrated through SOA?

See Attachment L, BR24. 223. In the Interface List there are requirements given as future interface between Business partner and NV DMV. What are the different modes, these business partner expose their data for interfacing eg: webservice, file, db, etc?

It is unknown what future protocols shall be used. Examples of existing protocols can be found in Attachment L, Interfaces_Lists.

224. Section 4.3.5: Please share different type of rules that need to be configured?


See response in #165 above. 225. Section 4.3.2: Please list out the social site and type of business activity is expected based on this interface?


226. Do you have a requirement to integrate CRM application with CTI for call routing and screen pop up?

The NV DMV desires to efficiently manage customer interactions through multiple channels. See response in #167 above.

227. Can you provide existing business flow for Customer Support?

The NV DMV will look to reengineer the process and business flow for all divisions and business functions based on the vendor’s proposed system architecture. All new business flows shall be defined during the detailed business requirements phase of the sub-projects.

228. Section 1.4.6.7: It is stated that (Eliminate unnecessary builds and Extract Transform Load (ETL) processes used in the legacy technology) and OBIEE is to provide comprehensive reporting at all levels. Question: OBIEE has the capability to connect to various databases and provide simple reports with raw data but for comprehensive reporting we will need tools like informitica to extract data and transform it in a way that OBIEE can build complex reporting so we might need to use ETL extensively.Can the proposed solution include ETL?

See response in #167 above. 229. Please confirm if you have an Employee Expense reporting system.


230. Section 1.4.4.: Please provide total number of users managed through the present Identity management system.

At present we have 434,731 users actively managed through Identity Management system.

231. Section 1.4.4.: Please provide the present overall security architecture highlighting the different tools & components (e.g. Directory servers, Access management tools, Identity management tools etc.) used for managing security?

The NV DMV security architecture is highly classified. Details will be shared with awarded vendor, if appropriate. See response in #167 above.

232. Section 1.4.4.: Which are the internal/external applications identities attributes need to be synchronized?

The NV DMV is requesting a closed loop security system that provides both Advanced Infection Lifecycle identification and remediation while simultaneously having the ability to control legacy vulnerability remediation through a systematic function. The NV DMV


wants the ability to detect and defend against unknown threats while also dealing with known threats in a very methodical and productive method. See response in #167 above.

233. Section 1.4.4: What are the different complacence adherences under the scope of work?

Specific levels of complacence’s will depend upon the modernized system architecture and the remediation tools sets designed to respond to advanced and/or known threats. The levels of risk would need to be characterized and displayed in the Information Security Health dashboard, with dynamic status changes as remediation were applied to specific vulnerabilities. Relating to the security health of the agency, rule sets defined during design and modified as the modernized solution becomes “run business” is deployed and response case information is added to the security health engine.

234. Section 1.4.4: Would it be a managed service support?

Identification of advanced / known vulnerabilities and their subsequent remediation is preferred to be automated. The NV DMV sees several instances where the creation, response and maintenance to obtain a zero tolerant master security environment will require managed service to complete and/or execute various functions. As most security systems do need governance to maintain or deal with dynamic changes to the cyber world, OIS foresees the need to have a team dedicated to operational execution control.

235. Please list the existing Defect tracking and management tools that are available.

Refer to Section 3.5. Project Software of the RFP. 236. Please provide the list of inventory and its functionality to capture the existing system business rules and behavior.

The NV DMV currently keeps items such as, but not limited to: forms, documentation, printing materials, labels, office materials, etc., as part of inventory. These items may decrease inventory based on the various business functions as they are executed.

237. Is source code review is in the scope of assessment?

This question is unclear. If the question is regarding reviewing existing code to define the vendor’s proposed system: The answer is no. If the question is regarding code review as part of change management and source code migration: The answer is yes. All code must be reviewed to ensure it meets the source-code standards and architecture approval.

238. What should be the frequency of security assessment?

Internally – Continuous with quarterly reporting to the Governance Board via scorecard Externally – PCI Requirement Based

239. How many Maps/Screens are currently present (CICS, IMS DC, and Natural)?

NV DMV does not use CICS BMS, IMS DC or Natural. See Section 3.4, Current Computing Environment of the RFP.

240. How many batch jobs are running in production which would be required for migration?


The number of current batch jobs is 1,360; approximately 1100 are production. It is anticipated that no current batch jobs will be migrated to the new system. The detailed requirements shall be defined during the requirements phase, based on the vendor’s proposed system.

241. What is the number of files (VSAM/PS/GDG) that are required to be migrated to the new platform?

The NV DMV Data residing VSAM/PS/GDG typically holds log, configuration information specific to Mainframe software, or batch job output. Consequently, data residing in VSAM/PS/GDG will not be required for migration.

242. Please specify the number of IMS segments/DB2 tables that are to be migrated.

The current system utilizes approximately 420 tables. The proposed solution might need more or less tables. NV DMV will work with the awarded vendor to determine data that need migration. The conversion requirements shall be defined during the requirements phase of the sub-project.

243. Will the programs/JCl’s currently running on production be re-written again in different technology or will be migrated as it is to a different platform?

NV DMV is not seeking to migrate Mainframe programs/JCL/etc. to a different platform. The scope of this project is to replace the existing system hardware/software, processes, etc., as defined in this RFP. Existing systems will not be part of the solution landscape.

244. Section 7.1.3: Who is the responsible for User Acceptance Testing (UAT)? What level of support is expected from contractor’s QA team during UAT?

Both the NV DMV and the vendor. Refer to Section 5.4.2.20 Testing and Test Plan of the RFP.

245. Section 5.4.2.20: Point B under section states that “The contractor shall work with the NV DMV to execute parallel tests with the current legacy environment, as well as, perform standalone unit, integrated, and end-to-end testing on the proposed system”. Does Nevada DMV already have regression test suites defined for existing applications that can be leveraged by Contractor’s QA team?

Sections 3.1.8.4 Integrated and Automated Testing System and 4.1.11 of the RFP. 246. Section 14.3.4.1: Please clarify if there are any testing activities that are to be carried out only at onsite?

See Section 14.3.10 Travel Requirements of the RFP.

247. Will there be a separate test instance that will be made available for testing?

See Section 4.2.26, Application Environments of the RFP.

248. Could you please let us know if any Test Management/ Automation tool currently exist?



249. Please specify if there is any existing SOA tool like (SOAP UI ) for SOA Testing?

See response in #245 above. 250. Please provide the list of applications/ interfaces that are in scope of performance testing with respect to Web Applications, Web Services, Batch jobs & SFTP?

See response in #56 above. 251. Has all the requirements have been covered in the document “Attachment L Requirements Matrix”? Or do you anticipate an assessment to understand the existing legacy code to determine the gap and appropriate solutioning?

It is not expected that understanding of legacy code be assessed. The NV DMV will look for all new solutions to be created using the vendor’s proposed system.

252. We understand that there are backlog requirements that are not currently being implemented in the existing legacy system, Has all these requirements being covered in the document “Attachment L Requirements Matrix”?

The backlog requirements can be found in Attachment L, BR14 DMV Service Requests.

253. Is it possible to have access to the existing Legacy source code and data structures to Analyze and understand the dependencies, Interoperability with in the existing legacy applications?

The NV DMV will consider this request, if it is relevant to the project, once the vendor has been awarded. The NV DMV expects to replace the entire current system; making all existing code irrelevant to the new system.

254. What is the technology stack that state of Nevada is looking to develop the custom applications other than the specified off-the-shelf Applications? We would assume Java and related software as those are compatible with Oracle Stack. Can you clarify?

See Section 4.1, Computing Platform of the RFP. See response in question #3 above. 255. There were multiple functionalities that were provided within the “Attachment L Requirements Matrix does these requirements have to be implemented as a separate system for each tab or can these requirements be re organized across defined CRM, Policy management, Identity management, Business Intelligence etc. products?

The NV DMV is looking for an integrated vendor system that includes all functions of Attachment L and meets the requirements of this RFP. The vendor can propose a solution that meets or exceeds the requirements of this RFP.

256. What does State of Nevada currently use for their Source code management, Change management and monitoring tools in their distributed environment; if viable can these products be leveraged in the proposed architecture?


The NV DMV utilizes Team Foundation Server to manage distributed artifacts. A customized version of Lifecycle Manager is used to manage Mainframe artifacts. See response in #167 above.

257. Data migration – Is there a preferred approach (ETL) and tools that are preferred to migrate the data from the legacy application to the new architecture by State of Nevada or can we leverage/propose our proprietary tools?


258. From mobile apps we understand the scope is focused on 2 core users. One application for citizen and one for investigators. Please confirm if any other views for the application need to be developed for e.g employees external vendors etc.?

The need for future users and applications will be dependent on the business need, legislative mandates, and technology advances available.

259. Section 4.2.6 talks of existing application, can some screenshots of the application be shared? Please confirm if the application was natively developed for iOS and android or developed hybrid model leveraging html5?

Section 4.2.6, Service Oriented Architecture Capabilities and Key Features, are the requirements for the vendor’s proposed system. The NV DMV shall share existing screens of existing application, if applicable (see response in question #3 above) with awarded vendor. The current system was not developed using any of the platforms described. See response in #167 above.

260. Are there any known business pain points with the current application that need to be addressed in the new mobile application?

See Section 3, Background of the RFP.

261. Is the current portal app build on responsive design approach? Please confirm if the expectation is also to develop the future state as responsive design supporting al form factors?

The current portal application is not build on a responsive design approach. See response in #167 above.

262. Does the POC stage scope also need to address mobile application as well?

The POC does not outline a need for a mobile application to be demonstrated. However, the NV DMV will consider all POC demonstrations that meet or exceed the requirements of this RFP.

263. Does the application need to support both the smartphone and tablet form factor?

Yes. See response in #167 above.

264. The document talks of supporting multiple languages. What languages will the mobile application support?


See response in #97 above. 265. Does the application support only one type of orientation (landscape or portrait). What is the expectation on this?


266. How is the deployment of the application to consumers and investigators planned?

See response in #167 above. 267. What specific (if any) native smartphone or tablet features do you wish to integrate into the new mobile application experience?

See Attachment L, BR01.50.

268. Do you anticipate any alerts / push notifications related user experience in the mobile application for e.g to keep consumers updated with offers etc?

Yes. This will depend on the business needs and legislative mandates. The detailed requirements shall be defined during the requirements phase of each sub-project.

269. Also please confirm if there needs to be a user registration process that needs to be enabled for the tablet/smartphone user?

The NV DMV will look to the vendor to propose user registration process. See response in #167 above.

270. Please confirm if the applications need to work offline?

There may be a need for offline processing. See response in #167 above.

271. There was also mention of kiosk solution. What was the basic development model for the kiosk application?

The NV DMV currently uses a business partner for all kiosk functionality and development effort. See Attachment L, Interfaces_List.

272. 4.2.21.5 talks of sharing document over mobile. Can you share the various types of document that need to be supported on mobile like document,pdf,videos etc?

Section 4.2.21.5 describes the possible future use of cloud-ready online file sharable solution. Section 4.2.21.5.A, describes the possible documents that may need to be supported; based on industry standard formats.

273. What is the total number of current users for mobile application?

The NV DMV does not have enough mobile users as the one mobile application is rudimentary. See Attachment L, BR02.


274. What is the Peak load (Maximum concurrent users) of the app ?What is the Average number of concurrent users?

Approximate values: Maximum 100 concurrent users; average 90 concurrent users.

275. What are the key features that need to be considered for investigators mobile application?

Some of the key features may include case-management access, issuing tickets, etc. The various detailed functions shall be defined during the requirements phase of the subprojects.

276. Please extend the Q&A session by an additional two weeks to allow the vendors to ask follow- on questions to your responses to the first set of questions.

The NV DMV will not consider an extension for additional questions.

277. Will the state consider capitalizing on a private, public cloud and/or hosted solutions? This could take the form of a leveraged solution to utilize multiple platforms for delivery ie. On and/or off premises, on and/or offshore.

Not at this time. See section 4.2.21, Cloud Ready of the RFP. 278. Please specify if the vendor can submit non-government clients as business references matching all the other technical requirements?

Refer to the requirements in Section 6.3.1 of the RFP.

279. Is the State willing to negotiate terms and conditions after award?

Vendors must note requested changes to terms and conditions as an exception in Attachment B – Technical Proposal Certification and Compliance with Terms and Conditions of RFP. The NV DMV may negotiate terms and conditions during contract negotiations.

280. Is the State willing to consider using terms and conditions from an already existing contract (e.g. MHEC)?


281. Is it anticipated that the proposing vendor will perform an assessment of the existing systems to assure no unintended gaps exist in the new RFP requirements?


282. Will the vendor be responsible for providing infrastructure hosting and managed services?

No

283. Payment Hold back of 30%- Is the hold back going to be invoice wise or every invoice will be paid as usual, except invoices amounting to 30% of total deal value which will happen probably at the later stage of the project.


The hold backs will be based on invoice.

284. SLA Credit- We need to have a very specific example in value by taking an invoice of $100.

See Section 5.5, 2nd paragraph of the RFP. Using SLA 5.9.1 as an example. 1. If the negotiated performance credit rate is $50.00/Hour. 2. If the SLA in that specific period met the SLA (Time to Repair) of less than 1 hour. 3. Vendor invoice is $100.00

Invoice Item Line Item Total SLA Credit

(Debited From Invoice)

Invoice Total

Delivery of Test Environment

$100.00 $100.00

SLA Credit $0.00 $0.00 Invoice Total $100.00

1. If the negotiated performance credit rate is $50.00/Hour. 2. If the SLA in that specific period exceeded the SLA (Time to Repair) of less than 1

hour. 3. Vendor invoice is $100.00

Invoice Item Line item Total SLA Credit

(Debited from Invoice)

Invoice Total

Delivery of Test Environment

$100.00 $100.00

SLA Credit ($50.00) ($50.00) Invoice Total $50.00

285. Do you have plan to move to other mobile OS like Windows Phone, BlackBerry, etc. apart from Android and iOS?

The NV DMV will consider all mobile OS’s that meet business needs, legislative mandates, and are/become industry standards. See response in #167 above.

286. Mention how existing mobile apps/sites/systems are being tested. Is proper mobile test strategy in place? Also mention the tools used for mobile testing.


287. What is the current count of users accessing your system and the mobile apps?

Approximate values: 500,000 users

288. Is testing for mobile application performance and user experience in scope?


See Attachment L, BR32.12 to BR32.32. 289. Section 1 Project Overview: You have mentioned BPO in order to provide better service to customers. Is it to improve efficiencies from the service , across the functions namely finance , inventory , correspondence management system, customer relationship management?

The NV DMV expects efficiency improvements across all business functions and divisions which include, but not limited to: Transaction processing, process flows, customer transaction processing, additional functionality using alternate services, etc.

290. Section 1.4: Is the expectation that the new system will need to automate the various processes manually done today, namely in in collection, reconciliation, and distribution of revenue collected. If so, are you planning to optimize resources post this implementation.

Yes. The current manual processes shall be automated to help streamline and optimize all functions, resources, and processes.

291. Section 3.1.5: One of the challenge is the revenue distribution model to track and distribute the 1.2 bn. Is there a standard method for this distribution? What are the factors to be considered for this?

The distribution of funds are mandated by Statute, Regulations, or Federal Guidelines. The proposed vendor solution shall interface with the State’s financial system to provide required distribution transactions. The proposed vendor solution shall not generate bank distribution transactions.

292. Section 3.4.1: Could you provide a split of number of users across the locations in front office and back office functions.


293. Section 3.2.24: Has there been any adverse audit report by the audit and compliance enforcement division . If so could you mention which of the functional areas.

The NV DMV is not at liberty to disclose any audit findings as part of this RFP. Once a vendor has been awarded, any audit remediation may be disclosed, if applicable.

294. Section 5.4.2.21: Any suggested approach for system migration / process transition. Do you think a data management service during the parallel run will be required to support transactional exceptions and ensure validations.

The NV DMV will work with the awarded vendor for system migration. The NV DMV will work with the awarded vendor to determine the optimal solution based on the proposed solution.

295. Please detail out the customer service scope of work for Back Office & Call Centre?

The NV DMV will look to streamline and gain efficiencies in process improvement with the vendor’s proposed system. At this time the NV DMV shall continue to support its customer base with services as outlined in Section 3.2.2.3 Central Services and Records


Division (CSD) of the RFP. Additional information can be found in Section 3.2.9 DMV Current Processes and Functionality of the RFP.

296. What’s the current customer service mix in Back office & Call Centre in terms of volumes?

Approximate Annual Values: Call Center: 875,723 Back-office Transactions: 3,540,592

297. What are the current training timeline and also the trainee certification process before release to Operations?


298. Is there a particular method that DMV has followed in the past to impart trainings to end user community? Are you open to Train The Trainer approach?

The NV DMV has utilized various training methods such as: Hands-on, On-the-Job, Training academies (internal), MOODLE (online training tools), Train-the-Trainer, presentations, etc. The NV DMV will consider all training methods that meet or exceed the requirements of this RFP.

299. Should we consider any travel to various locations to impart trainings to your end/super user groups?

The NV DMV shall review the training plan for all sub-project implementations as required by this RFP. Travel may be required to the various DMV locations; alternate solutions may be proposed by the vendor.

300. Is there a back log of cases which need to be processed and what are the expectations with the vendor on this?

This question is unclear. The expectation is for the vendor to not process any backlogs.

301. Are there any multi lingual requirements on the customer service side?


302. Section 1.4.6.7 and Section 3.4.8: Please confirm if the ETL technology currently being used is SSIS or there is any other ETL tool as well? Is there any plan about replacing the existing ETL (SSIS) tool into new one or we need to eliminate SSIS ETLs if not necessary after analysis.

The NV DMV uses SSIS as our ETL Tool. See response in #167 above.

303. Section 3.4.8: Please clarify the use of three BI reporting tools mentioned in the RFP i.e. Crystal Reports, SSRS, OBIEE in existing and future architecture to understand the demarcation of use of them.

Section 3.4.8, Computing Infrastructure of the RFP, refers to the current computing environment. The tools are currently in use by the NV DMV. The NV DMV will work


with the awarded vendor to determine if the existing tools may work with the vendor’s proposed system. See response in #167 above.

304. What is the technology used for existing DWH/EDW? Is there a description of how data warehousing / business intelligence is developed and supported within the organization today?

The NV DMV uses SSIS, SSAS and SSRS. Yes, there is a description of how this was developed and is supported within the current organization. Details will be shared with awarded vendor, if appropriate. See response in #167 above.

305. What are the source Applications and Size of transactional data each of them are creating on a monthly basis to be consumed by Business Intelligence Plat? Also please mention the respective technologies for each of the transactional data sources.

See response in #304 above. See response in #306, #307, and #308 below.

306. What are no of data sources for the BI applications and the Tables/Views in the same? What is the Type of databases, no. of fields, tables and size of data?

The typical database is SQL server. Details will be shared with awarded vendor, if appropriate.

307. What is the No. of existing ETL jobs under each application, ETL batches? What is the approximate number for to be developed ETL jobs?

The NV DMV currently has 10 ETL jobs. Details will be shared with awarded vendor, if appropriate.

308. Please share the current architecture showing the data flow from source till reporting tools & what will be the expected future architecture along with the technology stack. Through which we can understand the end to end flow: no. of BI reporting & analytical applications, no. of reports/ dashboards/ scorecards per app, cubes if any, packages, ETL jobs, data quality tools used (if any), DW, data sources.

The NV DMV High level architecture: DB2 SQL Server SharePoint The NV DMV uses SSIS, SSAS and SSRS for BI reporting and analytical applications. See response in #167 above.

309. What is the level of data quality in the existing data? Please rate the same in the scale of 1 (lowest) to 10 (highest)?

The data quality of the existing system can be rated as an 8.

310. How is master data currently managed? How are entities such as Customer, Territory, and Product et al managed?



311. If there is no structured master data infrastructure, how are attributes of master entities from multiple sources combined?

Our current DMV application is an integrated application that manages master data through custom application using Informatica’s IDS and Experian’s QAS (See response to Question # 122). Though not robust, attributes from master entities are matches and integrated through custom code.

312. Is there any MDM tool used in current architecture and what is the plan about using an MDM tool in future architecture?

No, MDM tool is used in the current architecture. See response in #167 above. 313. How historic records are currently maintained in each data warehouse? How are historic records linked?

The NV DMV refreshes the data warehouse monthly. Existing data is not over-written. Details will be shared with awarded vendor, if appropriate.

314. What are the number and type of reports currently existing? And what is the number of reports required to be developed (along with the technology stack)?

For internal customers we provide between 200 and 300 total reports; some are printed reports, reports via FTP, and reports via intranet access from the batch process. One of the objectives is to minimize printed output. See Attachment L, BR37 for specific reporting requirements. We also have daily, weekly and monthly analytical reports for Transaction, Vehicle and Registration, Driver License, and License plate statistics along with other reports. We will discuss further with the awarded vendor.

315. Are these reports scheduled? If yes, how frequently? Are there any alerts and thresholds set by the end users?

For internal customers most reports are scheduled during batch run; frequencies of current reports are: on demand, daily, weekly, monthly, semi-monthly, quarterly, annual (yearly) and Semi-annual. We also have daily, weekly and monthly analytical reports for Transaction, Vehicle and Registration, Driver License, and License plate statistics along with other reports. We will discuss further with the awarded vendor.

316. Are there any additional functionalities like export to excel/ pdf , drill down/ drill through, email integration, mobile integration etc. are required for developed reports?

The additional reporting requirements can be found in Attachment L, BR37 REPORTS MANAGEMENT SYSTEM. The vendor may provide additional functionality that meets or exceeds the requirements of this RFP.

317. Section 4.2.5.7: How is the BI platform accessed by the end user? Is it through the tool portal, through an enterprise portal, SharePoint etc.? Kindly elaborate about current and future state on how reports will be accessed by users?


The NV DMV uses SharePoint for end user access. Details will shared with awarded vendor, if appropriate. See response in #167 above.

318. Do you have up-to-date documentation (for example, data models, ETL design specifications, key performance indicators, dimensions, measures, reporting and analytical components, etc.) of existing environments?

Yes. Details will be shared with awarded vendor, if appropriate.

319. What is the no of cubes per application in existing environment? What is the number for new cubes development? Do we have SSAS in place and would be part of future technology stack?

The NV DMV currently has 8 cubes. SSAS is in place. See response in #167 above.

320. Section 3.1.5: Please share some analytics use cases if business is doing across Finance and Customer Relationship?

The NV DMV is looking to derive analytics from an integrated system. For example: 1. Analyze the customer demographics to determine if a specific community is

underserved and a kiosk installation is required. 2. Analyze customer trends when a new DMV product is deployed; such as a new ID

card type. 3. Analyze customer trends for new license plate issuances.

321. Section 3.1.5: As part of analytics requirement, is DMV open to exploring a Standalone Analytics application or inbuilt enterprise functionality to meet business needs?

See response in #167 above. 322. Section 4.2.21: Is DMV also exploring cloud ready analytics solution which can be hosted on premise as well as used in Cloud? Or it is open to leverage already cloud enabled solutions Azure Machine Learning from Microsoft , Amazon Machine Learning

Refer to Section 4.2.21, Cloud Ready of the RFP. See response in #167 above.

323. Section 3.4.8: Is any Statistical application already being used by any of the business in DMV Nevada? There is no mention about analytics in Computing infrastructure list.

Yes. 324. Section 3.1.5: Does DMV Nevada have employees with skills in advanced analytics like doing statistical predictive modeling?

The NV DMV is not aware of resources with this skill set. However, the NV DMV is not precluded from acquiring resources in the future with the required skill set.

325. Section 4.2.22.3: What are the sources of unstructured data? Presently any unstructured data been captured apart from web /social data?


The vendor is not expected to build or implement a Big Data solution at this time. Presently, we do not use any source of unstructured data. However, the vendor shall include their recommendations as part of the RFP response.

326. Section 4.2.22: Has technology selection for BIG Data Architecture already performed? Please elaborate on technological preference if the response is expected to include technological landscape as well? Kindly confirm if the requirement related to Big Data is purely functional and response is also expected covering same?

See response in #325 above. NV DMV has not selected a specific Big Data architecture. The requirement is purely functional and the vendors can include their recommendation as part of the RFP response.

327. Which tool is currently being used for VM scanning and what drawbacks or shortcomings do you see in the current tool?

The NV DMV currently does have tools for VM scanning. 328. How many IPs (internal/external) are projected to be scanned?

The NV DMV does not require any IPs to be scanned.

329. For internal scans how many virtual/physical scanners needs to be currently present?

Two appliances; one in the Northern and one in the Southern region.

330. Please specify if there are any security policies.


331. What reports formats are required to report Vulnerabilities?

See response in #191 above. 332. Please specify if other commercial terms, like COLA, Termination for convenience, etc., will be discussed after awarding the contract.

Vendors must note requested changes or additions to terms and conditions as an exception in Attachment B – Technical Proposal Certification and Compliance with Terms and Conditions of RFP. The NV DMV may negotiate terms and conditions during contract negotiations only. No additional negotiations will be allowed after contract approval; unless and agreed upon contract amendment is allowed.

333. Section 6.3 – At the submission stage of the response, is it mandatory to send the questionnaire through business references? Is there a provision of vendor sharing the reference details with DMV now and share the vital specifics later upon shortlist?

The vendor responses shall meet the requirements as defined in section 6.3 Business References of the RFP.


334. Can you please provide the count of batch entry point programs, e.g. JCLs, shell scripts, or scheduled jobs that invoke offline functionality. In client-server systems, these may be “long running” functions triggered from the user interface.

Approximate values: JCL/PROCLIBs: 1800 Batch programs: 512. This RFP does not expect the vendor to re-platform our existing Mainframe infrastructure. The proposed solution might require far fewer batch jobs than what exists today.

335. Can you please provide us the count of reports. Reports typically present static information in a predefined format. They may be printed or emitted as files and triggered by a scheduler or by an end-user or technician who sets parameters or constraints.

See response in #314 above. See response in #315 above. Details will be shared with awarded vendor, if appropriate.

336. If possible can you please provide us the types, and the count of each type, of interfaces between the system and other systems inside or outside the subject portfolio, e.g. type examples: FTP file transfer to an outside system; MQ/Series message to another system in the portfolio.

See Attachment L, Interfaces_List.

337. Please provide us with the number of programs and associated count of lines of code by language. Note whether the counts include blank lines and/or comments. A single application might be in multiple languages, e.g. COBOL, Powerbuilder, JCL, SQL procedures. Please include the language version, if known.

Estimate lines of code (including comment and blank lines): COBOL: 3,200,000 JCL: 380,000 REXX: 58,000 C/C++: 800 Power Builder, Visual Studio, .NET, & SQL Server Stored Procedures: 1,000,000 This does not include disparate systems used by various divisions to include MS Access, Excel Macros, etc.

338. If any, what is the count of modules, categorizations, or sub-applications within the application? E.g. an accounting system inventory system etc.

The NV DMV currently has approximately 65 different sub-applications. Not including additional disparate systems used.


ALL ELSE REMAINS THE SAME FOR RFP 3158.

Vendor must sign and return this amendment with proposal submitted.

Vendor Name:

Authorized Signature:

Title: Date:

This document must be submitted in the “State Documents” section/tab of vendors’ technical proposal.