Wisconsin’s Path to Integrated Tax Administration Vicki R. Siekert Wisconsin Department of Revenue...
28
Wisconsin’s Path to Integrated Tax Administration Vicki R. Siekert Wisconsin Department of Revenue Wisconsin Digital Government Summit Madison, WI December 3, 2008
-
Upload
ariel-waters -
Category
Documents
-
view
217 -
download
0
Transcript of Wisconsin’s Path to Integrated Tax Administration Vicki R. Siekert Wisconsin Department of Revenue...
Wisconsin’s Path to Integrated Tax Administration
Vicki R. SiekertWisconsin Department of Revenue
Wisconsin Digital Government SummitMadison, WI
December 3, 2008
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
Current vendor timeline
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
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
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
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
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
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…
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
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
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
Wisconsin DOR Enterprise Data Warehouse
Janna BaganzWisconsin Department of Revenue
Wisconsin Digital Government SummitMadison, WI
December 3, 2008
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.
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.
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.DW Resources 2007 Q3 2007 Q4 2008 Q1 2008 Q2 2008 Q3 2008 Q4 2009 Q1 2009 Q2Team Member 1 Project Manager Project Manager Project Manager Project Manager Project Manager Project Manager Project Manager Project Manager
Team Member 2Cross-Trained Reports/Jobs Project Manager Project Manager Project Manager Project Manager Project Manager Project Manager Project Manager
Team Member 3 Data Admin Data Admin Data Admin Data Admin Data Admin Data Admin Data Admin Data Admin
Team Member 4 ETL Job Writer ETL Job Writer ETL Job Writer Report Writer GUI Report Writer GUI Report Writer GUICross-Trained Reports/Jobs
Cross-Trained Reports/Jobs
Team Member 5Report Writer Hand-Coding
Report Writer Hand-Coding
Report Writer Hand-Coding
Report Writer Hand-Coding
Cross-Trained Reports/Jobs
Cross-Trained Reports/Jobs
Cross-Trained Reports/Jobs Project Manager
Team Member 6 ETL Job Writer Report Writer GUIReport Writer Hand-Coding
Cross-Trained Reports/Jobs
Cross-Trained Reports/Jobs
Cross-Trained Reports/Jobs
Cross-Trained Reports/Jobs
Cross-Trained Reports/Jobs
Team Member 7 Report Writer GUI Report Writer GUI Report Writer GUIReport Writer Hand-Coding
Report Writer Hand-Coding
Cross-Trained Reports/Jobs
Cross-Trained Reports/Jobs
Cross-Trained Reports/Jobs
Team Member 8 ETL Job Writer ETL Job Writer ETL Job Writer ETL Job Writer Report Writer GUIReport Writer Hand-Coding
Report Writer Hand-Coding
Cross-Trained Reports/Jobs
Resource Unknown ETL Job Writer ETL Job Writer ETL Job Writer ETL Job Writer ETL Job Writer Report Writer GUICross-Trained Reports/Jobs
Resource Unknown ETL Job Writer ETL Job Writer
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.
DW Steering Teamdeterm ines Data Source
B usiness Requirem entsM eetings
(A udit, Com pliance, & R& P)
Business Requirem entsDocum ent
(Deliverables Determ ined)
DW Team Begins DesignProcess
Steering Team votes onphase Deliverables
Question
s back
to u
ser g
roups
DW Build Process Begins
Build / M atchUser Data
MatchTesting
BuildContinue
User DataTesting
R aw D ataAccepted /
Report Build
User ReportTesting
R eport andD ata A ccepted
by U sers
Steering TeamA pproves Phase
Com pletion
DW Team m oves phasedata and reports into
ProductionUser Training and M entoring
How Does This Iterative Project Approach Work?
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
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.
Where We Are Today: Data Warehouse Functionality
WINPAS Interface
WINPAS Interface
SAS EG Project
Capability
SAS EG Project
Capability
SAS Web Report StudioSAS Web Report Studio
SAS Portal (run pre-created reports)SAS Portal (run pre-created reports)
Com
plex
ity In
crea
ses
Mor
e
Spe
cial
ized
Use
rs R
equi
red
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.
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.
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.
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.
DW and Operational Support
WINPAS / DW Interface (tables, Views, Web-Services)
Data Warehouse Reporting Tables
Data Warehouse Backend Storage Tables
Data Warehouse Operational Data Store Tables
Batch (Tables)
On the fly Request (View)
During Processing (Table, future: Web Service)
