System design and

acquisition
(pg 121)
• design of the HRIS can occur in two phases: logical and physical
design.
• The logical design of a system focuses on the translation of business
requirements into improved business processes, irrespective of any
technological implementation.
• Goal of physical design is determining the most effective means of
translating these business processes into a physical system that
includes hardware and software.
Logical Design
• two ways in which the system can be modeled: the physical model
and the logical model
• physical model focuses on the computer technology for the HRIS, that
is, on the hardware, software, networking plans, and technical
manuals.
• Strength of this type of model is that it focuses on how the system
will actually operate.
• Drawback: by focusing on the actual way the system will be
implemented in terms of technology, analysts and HR staff may be
constrained by the current, operational physical model.
Logical Design
• System developers like to focus on the essence of the business
processes independent of any technological implementation. To do
this, logical models of the system are created.
• Logical models are HRIS models that could be operationalized in
multiple ways
• For example, in the logical model, an organization might focus on
receiving and processing applicant files. in terms of the technology. It
could use a Web portal in an HRIS, a kiosk at a retail outlet, direct e-
mail, or physical mail.
• Strength: HR staff and developers can focus specifically on the
business processes, policies, and procedures instead of on technology.
“separating the ‘what’ from the ‘how’”
• logical model is similar to the blueprints for a home or an airplane.
• It provides the organization with an outline of the key business
processes and goals for the system.
• Then, as the physical system is designed, these are translated into the
hardware and software platforms that best fit the business’s needs.
• For an HRIS, there are two types of models created for the system:
those focused on the system processes and those focused on the
data the system captures.
Two Ways to View an HRIS: Data Versus
Process
• Data perspective focuses on an analysis of what data the organization
captures and uses, and on the definitions and relationships of the
data, while ignoring how or where the data are used by the
organization.
• Focuses on the most efficient and effective way to capture the data to
ensure accuracy.
• For example, a system whose aim is employee recruiting would need
data about the applicants and their knowledge, skills, and abilities
• Process perspective: focuses on the business processes and activities in
which the organization engages and on how data flow through the HRIS.
• designer would focus on the specific business processes, including the
input of the data into the system, the flow of data through the system,
and the storage of the data, but not on precisely what data are captured
and how they are best organized or stored.
• For example, a recruiting module from this perspective would consider
business activities, such as receiving applications, sorting and scanning
resumes to determine the interview pool, scheduling interviews. But
not the data definitions and relationships.
Logical Process Modeling With Data Flow
Diagrams
• process model describes and represents the key business processes or
activities conducted by the organization, such as applicant tracking.
• Type of process model typically used by organizations is a data flow diagram
(DFD).
• DFD is a graphical representation of the key business activities and
processes in the HR system, the boundaries of this system, the data that
flow through the system, and any external individuals or departments that
interact with the system.
• The focus of a DFD is on the movement of data between external entities
(such as a job applicant) and processes (the applicant-tracking process) and
between processes and data stores.
Advantages of DFD
• 1. There is freedom from committing to the technical implementation
of the system too early.
• 2. They provide a deeper understanding of the interrelatedness of
systems and subsystems.
• 3. They allow for stronger communication of system knowledge to the
employees, since the diagrams are in pictorial form.
• 4. They ensure a deeper analysis of the proposed system to
determine if all business processes have been identified.
DFD consists of four symbols
Creating and Using the DFD
• If all of 100,000 employees were included on a single diagram, it would
make the task of developing and using the DFD too complex.
• DFDs are organized by modeling the individual processes (such as the
applicant-tracking process) and components (such as the recruiting
module) of an information system.
• series of DFDs are created to depict visually increasingly detailed views.
• highest-level DFD developed is called the context-level diagram. This
diagram describes the full system, its boundaries, the external entities
that interact with the system, and the primary data flows between the
entities outside the system and the system itself.
Figure 5.2 Context-Level Diagram
• context level diagram contains only one HR process, representing the
system, data flows, and entities.
• single HR process in the context-level diagram is then broken into
greater detail on the level 0 diagram to provide a clearer picture of
the HR business process.
• Level 0 diagram contains the major system processes and the data
that flow between them. Each process should be labeled with a verb
that reflects the action that the process conducts
• numbered consecutively starting with 1.0 (1.0, 2.0, 3.0, 4.0, etc.)
Figure 5.3
Level 0
DFD
• Context-level diagram and the level 0 diagrams should reflect and
communicate the same information. This concept is called the balancing
of DFDs
• level 0 diagram has more detail than the context-level diagram, it
contains the same inflows and outflows from management, applicants,
and human resources.
• context level can be decomposed into a level 0 diagram, the level 0
diagram can be decomposed into additional-level diagrams.
• Next-level diagram (the level 1 diagram) would break down the processes
within the level 0 diagram to better portray and help staff to understand
the HR processes in the system. This level of detail will, improve the
accuracy of the logical design of the system.
Physical Design

• Physical design: goal of this phase of the SDLC is to translate the

logical model and requirements into a physical system, including all
hardware, software, and networking.
• Activities include
• (1) determining whether or not there is value in continuing the system design
and actual implementation processes,
• (2) determining hardware and software options and requirements,
• (3) determining where to obtain the hardware and software (e.g., by in-house
development or commercial software purchase),
• (4) developing an implementation schedule,
• (5) working with potential vendors to assess and select software if system
software is to be obtained externally.
Three Choices in Physical Design
• First, the organization has the option of doing nothing. (companies
have postponed proceeding after learning that a target software
vendor was in the process of a major revision of the software
product.)
• second option is to make changes to only the HR business processes
without implementing new or upgraded technology
• The final option that an organization can choose is to implement the
business process changes along with new or upgraded technology.
Can be done: build it, buy it, or outsource the development.
• Build it : not part of their core competency
• Buy it: buying prepackaged, commercial off-the-shelf (COTS) software fits
many needs
• Outsource it: outsource the development to an external company or to obtain
access to existing software through an application service provider (ASP).
Table 5.1 Software
Acquisition
Strategies
Working With Vendors
• first step in this process is to develop a request for proposal (RFP).
• An RFP is a document that solicits proposals and bids for proposed work
from potential consultants or vendors.
• RFP defines the organization’s goals and requirements for the new
information system.
• It provides the details that define hardware, software, and services
requirements.
• When developing the RFP, organizations should keep several things in
mind. The first recommendation is to focus on the business
requirements. review the requirements and logical redesign of the
business processes. These should then be communicated to each vendor.
• Second recommendation is to be specific
• third recommendation is to keep it simple. The problem with
including many technical details in the plan is that vendors may
review the RFP and screen themselves out because they think they
cannot fill the needs outlined in the RFP.
• fourth recommendation, which is to work closely with the HRIS and
IT staff as the RFP is developed.
Vendor Selection
• After the RFPs are sent, the vendors will then evaluate them to
determine if they have a product that would fit the company’s needs.
• If the HR and IT staff have put together a strong RFP, then they should
get a set of vendors who have a better understanding of the
company’s specific needs and who can provide a better-tailored
response and proposal for the HRIS.
• evaluate the relative strengths and weaknesses of each vendor. To do
this, you should consider several things and assess software options
according to a number of criteria. These are described below.
Vendor Selection
• Functionality: evaluate how fully the functionality of the HRIS meets
the HR needs. For example, a software product that meets 70% of the
organization’s needs will be less desirable than one that meets 98% of
its requirements
• IT Architecture and IT Integration: need to know whether
• HRIS will be a stand-alone system or a networked system or a Web-based
one, and so on.,
• know with what technology or platform the HRIS has been developed (e.g.,
UNIX, Linux, Windows).
• Understanding the extent to which the HRIS will integrate within the broader
corporate IT architecture.
Vendor Selection
• Price: price should be secondary to the goal of finding a system that
meets your process needs. At the same time, price will ultimately
determine which system is selected.
• Vendor Longevity and Viability: evaluate the quality of the vendor
itself. many vendors have been in business for 10 to 20 years. vendors
assessed through their responsiveness to existing clients and their
history of providing timely upgrades and increasingly flexible systems.
Assessing System Feasibility
• it is important to conduct a thorough feasibility assessment of the
project.
• A feasibility assessment should go beyond the traditional economic
metrics and should include multiple dimensions, such as technical,
operatio
• nal, human factors, legal, political, and economic.
Technical feasibility
• Technical feasibility focuses on the current technological capabilities
of the organization and the technological capabilities required for the
implementation of the proposed system
• Typical questions an organization might ask as part of a technical
feasibility assessment are as follows:
• 1. Do the hardware and software exist to implement this system? Are they
practical to obtain?
• 2. Do we add on or patch the current software or start from scratch?
• 3. Does our organization have the ability to construct this system?
• 4. Can we integrate the new system with our current systems?
Operational Feasibility
• Operational feasibility focuses on how well the proposed system fits
in with the current and future organizational environment.
• For example, a system, despite meeting technical feasibility criteria,
may make such a drastic change in how the organization operates that
it may not have a strong chance of being successfully implemented.
• operational feasibility assesses the extent to which the project fits
within the overall strategic plans of the HR and IT departments as
well as within the organization’s overall strategy.
• second area of operational feasibility focuses on human factors. An
assessment of the human factors feasibility focuses on how the
employee uses and works with the system, on the system’s usability,
and on the training the employee receives.
Operational Feasibility
• Typical questions asked as part of the assessment of operational
feasibility would include the following:
• 1. How well does the system fit within our organizational context? Will this make
us better?
• 2. How much will our organization change because of the new business and
technical changes?
• 3. How long will this take to do, and does the schedule fit our business’s needs?
• 4. If we have to squeeze, what might we be able to eliminate?
• 5. Do we have or can we get the personnel to do this?
• 6. Can people use the system?
• 7. What kind of training do we need?
Legal and Political Feasibility
• Legal and political issues also play a very important role in assessing
the feasibility of an HRIS.
• The best-designed and -implemented system can end up causing
major headaches for the organization if it violates existing laws and
regulations.
• Political feasibility focuses on the political environment of the
organization in which the HRIS is being implemented. Issues such as
power redistribution involving loss of individual or department
control can have major political implications that can affect the
effectiveness of the implementation.
Legal and Political Feasibility
• Typical questions asked as part of a legal and political feasibility analysis
include the following:
• 1. Does the implementation of this system infringe on existing copyrights?
• 2. Are we violating any antitrust issues by implementing the system?
• 3. Do we have contracts with other companies that don’t allow use of the new
software?
• 4. Does the system violate any governmental policies?
• 5. Does the system violate any foreign laws? (This question would be significant
for global
• companies who have operations in multiple countries where different laws
require different
• practices supporting the capture and use of HR data, for example.)
• 6. Who is likely to resist the implementation of the system?
• 7. Who may “win” or “lose” as a result of this implementation?
• 8. What is the risk of system sabotage?
Economic Feasibility
• The goal of an economic feasibility analysis is to determine whether
the costs of developing, implementing, and running the system are
worth the benefits derived from its use.
• analyst would identify the appropriate costs and benefits of the HRIS
and assign precise values to each. Then, these costs and benefits
should be subjected to a thorough cost-benefit analysis.