TRD\MVD Document Management System. Close Phase Certification Request. Agenda. Need Goals of the Project Scope vs. Delivered Scope Budget vs. Actual Enhancements – Post Implementation Questions. Need.
PowerPoint Slideshow about ' TRD\MVD Document Management System ' - rhiannon-fischer
An Image/Link below is provided (as is) to download presentation
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
The New Mexico Taxation and Revenue Department (TRD) processes approximately 12,000,000 Motor Vehicle Division (MVD)-related documents per year.
All documents that are required to be preserved and available for later reference are currently photocopied and microfilmed.
Retrieval of the current images is probably about 10X more time consuming than would be possible with a DMS. Retrieval currently requires a partial *.xls log of document to microfilm reel, entries in “green screens”, all with no indexing except the date and sometimes the MVD office.
Provide DMS capabilities to all MVD Field Offices, “Munis”, and any MVD unit that is currently involved with document capture and retention for selected driver and vehicle transactions performed within MVD 2.0.
Move MVD scanning, and payment processing to the Montoya Building.
OCR and OMR of selected documents and regions within documents.
No ICR planned.
Creation of “bridge” software between existing transaction programs (MVD 2.0, and other web-base. apps for capturing data) and the DMS. Integration will be performed in the most flexible technology possible, to enable transfer to the reengineered system at a later date.
Payment processing for the citation payments via COTS software and revision of current interface with existing MVD systems.
TRD attempted to reuse an existing KFI web application that had been placed into production around 2001 or 2002. Going into the project, the concept was to make no changes to that existing, old application. The reasoning was that this would be replaced with the Modernization project and was already mandatory in those requirements. Reuse of this tool created a disproportional amount of extra development and testing resources.
If anything, the Contractor was too accommodating to MVD changes to requirements, design, and development. Wholesale accommodation of changes led to strains on the remainder of the project schedule. The project started with some slack in the schedule, and ended with none, including a considerable amount of OT on the part of the Contractor, at no additional cost to TRD.
TRD thought that the risk that the OPEX was not going to perform all of the necessary OCR was mitigated by performance testing prior to acceptance of the equipment. A workable solution was developed using both the OPEX and EMC Captiva capabilities, but the solution was not ideal. In the month following implementation, unauthorized changes were made to the OPEX job and untested changes were made to the UTC format. Both created a “snowball” effect through this portion of the system. The lesson learned here, what the technical team needs to continue their involvement in the Change Control process after production implementation.
MVD made the decision not to exercise the full optional amount of the Maintenance, support and Enhancements from the RFP. Instead MVD opted to purchase a limited number of hours post-production for Level 2 support, and selected enhancements.
TRD\ITD was unable to provide (1) FTE with the Deloitte-specified technical expertise to work on the project and receive the Knowledge transfer. Therefore, the maintenance and support has increased to include an State Price Agreement contractor with the necessary skills and expertise. TRD\ITD will be requesting the necessary position for FY15.