Hr technology landscape overview

HR Technology Landscape Overview
October 1st, 2013
Marcino Waas (HCM Technology - Solution Group Leader)
SSI

Evolution of HRIS
Early (pre-WW II)
••Personnel
••Old term for human
resources
••Historically isolated from
core organizational
functions
••Record keeping
••Name, address, phone,
employment history
Between 1945 and 1960
••Human capital issues
••Employee morale
••Formal selection and
development
••No real changes from earlier
days
1960’s and 1970’s
••large companies felt a need to
centralize their personnel data in large
part to facilitate record keeping and
meet regulatory needs. Programs
were written on large mainframe
computers that acted as a central data
repository with little transactional
processing, usually only for payroll
••Government and regulatory agencies
increased reporting requirements:
••Affirmative action
••Tax
••Pension, etc
••Still, HRIS was used mostly for
keeping administrative records
••Personnel became HR
1980’s
••The Human Resource Information
System (HRIS), also know as a
Human Resource Management
System (HRMS), became prevalent in
the 1980’s with the popularity of
Enterprise Resource Management
(ERP) applications and the move from
mainframe systems to client server
technology
••The birth of tier #1 ERP vendors
••Oracle
••PeopleSoft
••SAP
••HRIS systems now included a host
of feature sets and functional
capabilities aimed at attracting,
retaining and properly compensating
the workforce
2000’s
••HRIS grow to include recruitment,
benefits management, time
management, payroll,
compensation management,
learning management, expense
reporting and reimbursements, and
performance management
••Self-service applications built on
top of the underlining data
empowered employees to manage
their own data and make timely
changes
••Online employee portals further
consolidated disparate systems,
documents and information into one
place

9Proprietary & Confidential | 2013
Common reason for HR Technology
Failure

When Technology Fails
Common reasons for HR Technology Failure
• “They allowed software sales people to demo what they wanted to
demo. They did not write any scenarios to say 'this is how we want to
run our business. Show us how',”
• “There is not a supplier out there that cannot gin up a usable demo
and make it look fabulous. You don’t know how much work went into
it, and how much of it is real,”
• The failure of human resources (HR) departments to understand how
a business works is one of the most common reasons why HR IT
projects fail
• Others common causes of failed HR technology implementations
which are gradually being neutralized in the HCM solutions arena
relate to change management and the customization of on-premise,
installed software.

Requirements for successful technology enablement
Clear goals and success measures
The right program design
Functional and effective processes
The right technology solution
A strong business case
Effective implementation and change management

Clear goals and success measures
••Companies consider technology solutions when they are:
••Replacing manual processes,
••Looking to roll out new or revised processes, or
••When their current technology is not working as desired.
••Unfortunately, they sometimes rush to a technology solution
when the problem is really much more complex and relates to
the basic design of the HR program or service.
••The important things is how the technology helps achieve
the program’s objectives and how it will both contribute to
and measure the key indicators of the program’s success.

The right program design
•• If program design is the problem, the next step is to define or confirm
what the program—not the technology—is intended to accomplish.
•• Although research consistently shows that the majority of
organizations are not satisfied with their HR programs—such as
compensation administration, performance management, or
rewards programs—they still purchase software to help administer
them. Why? *Automation!!!
•• One possible explanation is that they believe—or hope—that
technology will solve the problem. But making an ineffective program
more efficient through technology is hardly a reasonable goal.

Functional and effective processes
••Once the program design is determined, you need to develop or revise the roles,
processes, and procedures for administering the program. These are fundamental
inputs in determining technology requirements.
••Ask yourself the following questions to help identify the strengths and weaknesses of
your processes, and determine where changes
may be needed:
••Does your organization follow a uniform process?
••Does the process ensure that the results of the program are consistent, fair, and
aligned with the organization’s strategy?
••Does it work well with other processes (e.g., compensation
with payroll)?
•• Do business leaders and other stakeholders find the process valuable?
••Process improvements should always be made in advance of choosing a technology
solution.

The right technology solution
••Program design should influence technology design, not the reverse. Your
decisions about technology should never compromise plan design or result in setting
aside aspiration objectives simply because “the system can’t support it.” Too often,
technology gets implemented in isolation from other systems and programs, and
misses the big picture, or organizations sacrifice program goals for the sake of ease of
implementation.
••The current state of technology can bring great benefits through data aggregation and
coordinated display and administration. Its ability to actively reach users with targeted
messaging and action items can leverage the investment you’ve already made by
bringing existing systems into a seamless user experience.
••It is also important to engage other parts of HR (e.g., payroll, benefits, etc.), as they
might be expecting data or information from your new program design that you had not
anticipated. Be sure to gather any additional business requirements now as identifying
them later in the process could result in a scope change, causing an increase in fees
and/or a delay in delivery.

A strong business case (Building your business case will help you determine if
investing in a highly configurable or customized tool is worthwhile)
••“heavily productized” or “highly configurable.” Heavily productized means that the basic program
framework remains unchanged—customers can modify screen views, add/remove a set of data
fields, modify elements of output (e.g., reports). Highly configurable means you have more flexibility
in the structure of the system, the output is user-determined, and data fields are very flexible.
••Each of these solutions has pros and cons—and different costs. The benefits of the productized
approach include a lower cost and a shorter implementation time. While you might find a
productized software tool that meets all of your demands, you might need to “settle” on a solution
that doesn’t fulfil all your requirements.
••The highly configurable approach will provide a more targeted solution that meets your specific
needs and integrates with existing applications across the organization.
••Drawbacks could include higher expense, longer development time, and difficulty in making future
modifications and upgrades.
••Building your business case will help you determine if investing in a highly configurable or
customized tool is worthwhile
••Heavily productized means that the basic program framework remains
unchanged—customers can modify screen views, add/remove a set of
data fields, modify elements of output (e.g., reports)
••The benefits of the productized approach include a lower cost and a
shorter implementation time
Heavily
productized
••Highly configurable means you have more flexibility in the structure of
the system, the output is user-determined, and data fields are very
flexible.
••Higher expense, longer development time, and difficulty in making
future modifications and upgrades.
Highly
configurable

Effective implementation and change management
••Although the official execution and implementation
phase comes at the end of the project, you must
support the changes from the beginning. The
change management component runs the entire
duration of the project. It can be separated into two
distinct and equally critical components: the
background research or “homework” portion and
the go-live/launch or “exam” portion. Having one
without the other can almost guarantee some level
of failure.
Change Management

End of presentation

Hr technology landscape overview

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Hr technology landscape overview

Semelhante a Hr technology landscape overview (20)

Último

Último (11)

Hr technology landscape overview