Beruflich Dokumente
Kultur Dokumente
In addition to payroll processing, the UW currently uses HEPPS and related systems to collect and
interact with available workforce data (e.g., dates of employment, time and leave information, salary
and benefit information) for the University’s 30,000+ employees. HEPPS is a highly customized
implementation of a payroll system produced by Integral Systems 30 years ago. This customized
vendor package has assisted the University’s modernization and development for a generation. It
has become over time a valuable repository of our business rules and processes and it has been
extended through the USER projects to continue to provide value to the institution. However, the
University’s HEPPS implementation and its data design have limitations that have not allowed the
University to keep up with changes in the business and regulatory environment. Our workforce
management systems are no longer able to function as a repository of business rules and as tools
to execute them; they are now dictating our business rules and processes and increasing
compliance risks through a lack of flexibility.
Because the basic data design of HEPPS is centered on point-in time payroll processing and labor
distributions rather than people management, there is no access to person level information
required to function as or integrate with a modern workforce management system. In the current
environment we cannot provide information about the nature of our workforce, only about
what individuals were paid. A modern HRMIS is designed to enable an employer to plan and
manage and analyze the organization’s intake, classification, staffing, orientation, compensation
and benefits administration, performance management, and employee and labor relations.
In HEPPS many data elements exist at one point in time, with no history. The combination of up to
seventy budget distributions provides the basis for how University systems view and manage the
employment relationship. Having data elements without history, and managing from aggregated
1
Project Proposal
labor distributions after payrolls are run prevents the integration of data from HEPPS to a HRMIS.
Since HEPPS only collects certain data elements required at the point a person is paid it is possible
to take information from a relational based HRMIS to HEPPS while the reverse is not true.
A HRMIS needs to be based on a time relational data model in order to keep track of an individual’s
entire employment history and to adapt to changes in business or data requirements. Each table in
a relational data model is comprised of a series of rows with attributes held in columns (like the
rows and columns of a spreadsheet). A series of attributes that would form a single row of
information on a person might be name, eid, date of birth, ssn, last review date, etc. In a
hierarchical model like HEPPS the structure of the data is defined in strict relationships that are
much less flexible. Adding attributes in a relational model is akin to adding a new column to a
spreadsheet; adding new data is akin to adding a row to a spreadsheet and can be done without
limit. In contrast, adding available attributes and the amount of information available in a
hierarchical model such as HEPPS is akin to adding a new letter or word of text to a page using a
type writer. It is limited by both the size of the page and the requirement that all other spaces, text
and lines must remain the same or the entire page must be rewritten in order to make sense.
Since the central systems are not able to perform the functions required to manage our workforce,
an army of “shadow systems” replaces them. Departments and administrative offices throughout
the University maintain and use thousands of individual information stores including paper, excel,
word, access and other electronic databases and files. Such shadow systems are inherently
inefficient, insecure with respect to private information and subject to inconsistencies and errors.
They cannot be effectively analyzed, aggregated, audited or used beyond the needs of the
immediate, local problem they were created to solve such as keeping track of performance
evaluations or computer assignments. Sub-optimized business processes around personnel and
data management are the rule in this environment rather than the exception.
The expanding knowledge and talent of our faculty and staff is among the few assets that the
University possesses which has the opportunity to grow rather than depreciate over time. The
University currently spends a great deal of money maintaining an inefficient set of systems and
business processes focused around the management of people. Creating an environment which
enables more effective and efficient personnel management will allow for the most productive use
of the over $1.5 billion spent annually on compensation and benefits.
Project Approach
The project will apply the USER project methodology under the auspices of the Strategic Initiatives
Office. USER approach is a high involvement methodology that engages key business users (both
central and departmental) throughout all phases of the project from initial project definition to final
2
Project Proposal
implementation. The chart below depicts the lifecycle of the project from initial product strategy to
product implementation and ongoing maintenance. This initial phase of the HRMIS project will
focus on two key steps related to product strategy: 1) project scoping and planning and 2) needs
assessment. Subsequent project steps will address the analysis of alternative product solutions
and the development and implementation of those solutions.
Product
Product Strategy Product Development Management
The Needs Assessment phase will be a concentrated six month analysis and visioning exercise that
will result in documented high level requirements to inform the next phase of the project. By
assessing our current and future needs for workforce management systems at a high but
comprehensive level the University positions itself to make the best decisions on future investments
in the renewal of our HR and Payroll systems so that they will serve the needs of the institution for
the next 30 years. The Needs Assessment phase is not intended to gather all of the detailed
business and technical requirements of a full workforce management system for the University. It is
intended to provide the roadmap that will make build or buy decisions and detailed requirements
definition activities more accurate to the needs of the whole University. The USER approach to
product acquisition is an iterative process that will involve further scoping and planning following
this Needs Assessment phase.
Executive
The needs assessment will be undertaken by a Executive
Sponsors
Sponsors
project team drawn from throughout the
University. The primary participants will be a
Process Improvement Team of subject matter Technical Business
Technical Business
experts in an impacted area of workforce Advisory
Advisory
SIO/Project Advisory
Advisory
Group Leadership Group
management. They will meet regularly and will Group Group
In addition the project will require time from senior leaders, line managers and employees
throughout the University for survey and focus group participation. This will be a recursive process
3
Project Proposal
in which communities of interest are drawn together to express requirements and validate the
requirements put forth by other communities.
4
Project Proposal
environment. Examples of multi-year systems projects initiated by changes in the business
environment include UWorks in response to Personnel Service Reform Act and a ten year effort
around retirement reporting to react to changes in DRS plans. These would have been much less
traumatic changes in a flexible systems environment.
1.7 Project Risk (factors that may cause the project to fail)
Low. A fixed requirement of this project is that it must result in the University having a HRMIS that
is flexible enough to respond effectively to changes in internal business needs and external factors
such as changing regulation. Other large institutions, responding to similar business and technical
drivers to those that University of Washington faces have had well publicized and very expensive
failures when attempting necessary modernization of their workforce management systems. There
are several common themes in such failures that are instructive. They include having project
managers that do not have the expertise and experience to deliver results, insufficient oversight
mechanisms and failure to determine the needs of the institution(s) at the very beginning of the
process. In order to mitigate the last of these risks the University will invest at the beginning in a
Needs Assessment phase to determine the needs of the whole University. This phase will be the
start of a Product Strategy phase in which the University will determine its needs, assess the best
path to obtaining those needs and perform the pre-development work necessary to a successful
outcome.
5
Project Proposal
2.0 Project Elements
2.1 Scope of Work
HRMIS Project
1. Assess UW, regulatory and best practice requirements for workforce management data
and systems.
2. Determine build or buy path including high level scope, budget and timeline.
3. Detailed requirements and migration planning including detailed budget and timelines.
4. Development and/or implementation phases.
5. Ongoing support model developed and implemented.
6
Project Proposal
3.0 Resource Needs—Preliminary
Preliminary estimates of functional and technical resources needed for this project. Hours are
rounded to nearest 10.
All salaries include benefits. Travel and training is high to accommodate multiple site visits if
necessary by Process Improvement Team. SIO support is based on a estimated overhead rate of
approximately 10 – 15%.
7
Project Proposal
5.0 Funding Sources
5.1 Implementation Cost Funding
5.3 Indirect Cost Recovery Funds (does this project predominately provide
infrastructure support for research?)
None
8
Project Proposal
HRMIS Project
1. A flexible HRMIS with required data for effective, compliant workforce management
delivered on time and on budget.
Comments: