Wisconsin’s Path to Integrated Tax Administration

1. Wisconsin’s Path to Integrated Tax Administration Vicki R. Siekert Wisconsin Department of Revenue Wisconsin Digital Government Summit Madison, WI December 3, 2008

2. Cow path vs. Interstate • 1996 – Action plan • 1998 – Vendor selection and master plan • 1999 – Sales and use tax requirements for custom build • 2000 – Vendor change • 2002 – Sales and use tax transfer system implemented • 2003 – Individual income requirements defined • 2004 – Vendor change • 2005 – COTS product

3. Current vendor timeline

4. COTS Product • Configuration and reference tables rather than development • Site-specific modules for interfaces • Site-specific modules for things specific to state which aren’t supported by the base product • The less site-specific code, the less Fast support needed after implementation • Fits with statewide IT direction to COTS products

5. COTS Project Lessons Learned • Requirements definition phase starts with core product functionality rather than with a clean slate • Shortens development cycle, can put pressure on organization to staff project and manage change • Shorter cycle means less external change affecting project

6. COTS Project Lessons Learned • Need commitment on the part of business staff to stick close to product functionality • Business functional groups need to coordinate more, agree on standards, common practices • Use of steering team to coordinate decision-making and enforce consistency

7. COTS Project Lessons Learned • Vendor approach – I’d rather get an answer today that might change tomorrow than wait till next month when you have it finalized • Promotes continuous process improvement, even after implementation

8. COTS Project Lessons Learned • Ability to affect the core product by making the case for need modification or enhancement • Especially effective on things that are common among jurisdictions • Participate in user group with customers from other states and provinces

9. COTS Project Lessons Learned • Quote from Periodic Project Evaluation Report (9/24/08): • This project involves configuring a completely built application to meet specific state needs, not designing and building an application from scratch. Therefore, the project management complexity is significantly less than for a typical state application development project…

10. WI Wins – Image Management • Previously images stored in separate application, IBM Content Manager • Staff time spent looking up return record and image in two different systems • Now return images displayed within WINPAS, side-by-side with captured data • Non-return documents stored as inbound correspondence or attachment • Converting necessary old images from Content Manager to WINPAS

11. WI Wins – Image Management • Scanning old paper files that need to be retained • Eliminating old heads-down data entry of paper returns in favor of scanning • Increasing e-filing penetration • Correspondence generated within WINPAS is visible within WINPAS • Rapidly approaching the time when all documents related to a taxpayer are available within WINPAS • Able to redirect staff that once managed all that paper

12. WI Wins –Modernized E-File • An example of the kind of thing that Fast wants to support within their core product because many states will use • Developed site-specific component for Wisconsin in 2006, then “productized” • MeF communication gateway, acknowledge-ment process & return viewing all part of product • WI has been receiving corporation returns since late 2006, partnership returns since early 2008 & will be ready for individual returns in mid 2009

13. Questions? Contact information: Vicki R. Siekert Phone: 608-264-9907 E-mail: vicki.siekert@revenue.wi.gov

14. Wisconsin DOR Enterprise Data Warehouse Janna Baganz Wisconsin Department of Revenue Wisconsin Digital Government Summit Madison, WI December 3, 2008

15. Data Warehouse Beginnings • In 2004 a small team was established to build an internal Enterprise Data Warehouse. • The purpose was to develop a place where reporting could take place in one location across previously disparate data sources. • Reinforced the agency’s ability to provide efficient and effective customer support internally and externally. • A steering team of top management was established to manage direction of development team.

16. Team Roles • ETL Job Writer – Loading data into DW tables. • Report Writer – Writing reports in the GUI tools • Report Writer – Hand-coding more complex reports in SAS or Java. • Project Manager – Managing project phases.

17. Resource Planning • Careful planning to cross-train resources • Develop each individual on all tools and applications • Two employees and two contractors supported Phase I. Today we have a team of nine.

18. Vision • Although there was a strong sense of what information should be available, we started small. • Integrating information a few sources at a time and making reports available along the way. • The shortest deliverables have been performed in as short as two months, and the longest in a 9 month phase. • To date, five formal phases and three significant enhancement initiatives have been completed.

19. How Does This Iterative Project Approach Work?

20. Business Requirements Process Users Specify Business Rules DW Team Translates Business Rules into Code that transforms the data into a reportable format Users Run Finalized Reports

21. Where We Are Today: Data Warehouse Value • Match uniform data elements across disparate data sources for reporting purposes. • Users can research multiple items in one location rather than logging onto multiple systems. • Various reporting tools provide access and insights into the information available to end-users.

22. Where We Are Today: Data Warehouse Functionality Complexity Increases More Specialized Users Required

23. Where We Are Today:Usage • Number of Business Users continues to grow: 498 to date. • Overall Quantity of queries continue to increase: • Query Counts Q3 08: 157,291 • Query Counts Q3 07: 52,846 • Most recent two months show continued increases. • Three batch processes that interact with the processing system.

24. Where We Are Today: Challenges • Managing growing demand, while maintaining existing reports and data sources. • Establishing formalized processes to meet the growth of our team. • Managing cross-training without sacrificing speed or quality. • Finding time to have needed business requirements meetings when end-users are so busy.

25. Where We Are Today: Data Warehouse Benefits • Efficiency increases in daily work and customer support • Leveraging the DW Information for making business decisions and gaining insights into tax administration legislation. • Business Divisions are collaborating through the Business Requirements process. Working together and learning from each other. • Business needs continue to grow as they explore ways to automate and leverage DW data for additional process efficiencies.

26. WINPAS & Data Warehouse Collaboration • The need to automate manual activities are continually increasing. • Additional opportunities are being identified to support the operational needs of the business users. • This user driven demand has forged strong collaboration between WINPAS and DW development teams.

27. Data Warehouse Backend Storage Tables Data Warehouse Operational Data Store Tables On the fly Request (View) During Processing (Table, future: Web Service) Data Warehouse Reporting Tables Batch (Tables) DW and Operational Support WINPAS / DW Interface (tables, Views, Web-Services)

28. Questions? Contact information: Janna Baganz Phone: 608-261-5357 E-mail: janna.baganz@revenue.wi.gov