1 / 18

BUILDING AN IT ARCHITECTURE FOR DATA CAPTURE

BUILDING AN IT ARCHITECTURE FOR DATA CAPTURE. Terry Garber South Carolina Department of Revenue August 15, 2000. IT STARTS WITH A VISION…. Integrated multi-platform environment Total e-Government environment support Fingertip access to documents

cian
Télécharger la présentation

BUILDING AN IT ARCHITECTURE FOR DATA CAPTURE

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. BUILDING AN IT ARCHITECTURE FOR DATA CAPTURE Terry Garber South Carolina Department of Revenue August 15, 2000

  2. IT STARTS WITH A VISION…. • Integrated multi-platform environment • Total e-Government environment support • Fingertip access to documents • Become an Enterprise processor

  3. IIT Electronic Filing Other Agency Data Electronic Data Interchange Other Agency Data Interactive Voice Response Internet Filing Data Warehouse SCATS Data Entry Paper Non-IIT Scan / Image Outsource IIT SC DOR’s Technology Vision

  4. WHERE WE WERE • Mainframe-base Integrated Tax System • Developed in-house 1985 - 1997 • IDMS Database Management System • ELF/OLF, Telefile and Web Filing • Developed as pilot programs • Limited budget and resources • High-volume, award-winning programs!

  5. WHERE WE WERE, cont. • Highly manual paper processes • Difficulty finding key-entry operators • Scan/Image Pilot • Low-budget entry-level system • Limited OCR (primarily zero returns) • Limited access to images

  6. We Needed….THE INTEGRATOR • Outside “expert” analysis • Business Process Reengineering • IT Architecture recommendations • Ongoing project management • System and vendor integration

  7. SYSTEMS INTEGRATION RFP • Initial short-term report • Timeframe dictated by budget cycle • Analysis of current situation • Preliminary recommendations • Full Business Process Reengineering • Detailed process and IT recommendations • Cost/Benefit analysis • PriceWaterhouseCoopers selected

  8. INITIAL FINDINGS • Everything we knew about, PLUS: • Stovepiped data capture channels • Redundant system interfaces • Many single points of failure

  9. PRELIMINARY RECOMMENDATION YR 1 YR 2 YR 3 YR 4 YR 5 Automate Doc. & Records Mgmt. Phase One Reengineer Workflow Data Integration & Staging Modify Mainframe Systems Upgrade Electronic Filing & Payment Methods Preparation and Phase Two Pilot Test of Relational Databases Implement a Cashiering System Implement Data Warehouse Phase Three Planning for Next Phases Implement a CRM System Upgrade Technical Infrastructure Ongoing Implement Technical Process Improvements Implement Organizational Process Improvements Manage Organizational Change

  10. NEXT STEP: DETAILED ANALYSIS • Identify core business processes • Design team for each business process • Reengineer process flows • Technology requirements analysis • Cost/benefits analysis • Communications and change management • Implementation plan

  11. Manual Key Punch Data Capture Document Scanning OCR Engine OCR & Manual Validation ETL Engine WebFile SCATS TeleFile EDI/EFT ELF/OLF MISC Storage & Retrieval Non-IIT Storage & Retrieval IIT Conceptual Architecture Document Management External Data Data W-house & Operational Data Store Staging Engine

  12. OUTSTANDING PROCESS ISSUES • Document identifiers • What format should we use? • How would they be applied? • How soon would they be in the system? • Scanning configuration • Few large scanners or many smaller scanners? • What about remittance processing?

  13. PROCESS RECOMMENDATIONS • Packet identification (PID) for all items within one return packet (returns, schedules, payment) • Transaction identification (TID) for each general ledger account code • Multiple smaller scanners for redundancy and greater scheduling flexibility

  14. TECHNOLOGY ISSUES • Novell vs NT networking? • Fat vs thin clients? • IDMS vs relational database? • How would we manage redundant data?

  15. TECHNOLOGY RECOMMENDATIONS • Novell Directory Services for now, continue to evaluate Microsoft solution • Thin client where applicable, even if full function hardware • Continue with IDMS for processing, pilot relational approach for retrieval • Redundant data stores minimized

  16. REALITY CHECK: FUNDING • Historically modest in funding requests • Our good reputation works against us • Modest allocation this fiscal year • Need to build credibility • Seek alternative funding approaches

  17. NEXT STEPS • Finalize process and technology decisions • Functional design team for staging engine • Functional design team for PID/TID implications • Develop RFPs to have ready when funding becomes available

  18. QUESTIONS???

More Related