For many of us the idea of going through a vendor selection process can be a daunting task. The day-to-day task of running an
IT department has its own schedule with staff meetings, working
with business management, and keeping the systems available for
the general corporate workforce. These are enough to challenge
a typical workday to say nothing of adding a strategic initiative
on top of everything else. However, like most things in the IT
management process, you have the task of getting it done.
My goal with this article is to bring some process and methodology to the task for IT managers who may not have been
through the process before, or for tried-and-true managers that
may want to reaffirm their practice. For a significant vendor
selection process, such as searching for a claim, policy, or billing
system, plan for six to eight months to do it properly.
The first set of tasks is to establish a vendor selection
committee. In our organization, this is usually comprised of
a business sponsor, a member or two from their department,
other business stakeholders, and IT resources. From this group,
we select a subcommittee that will follow the vendor selection
process through the selection of three vendors. The full committee is then responsible for the final vendor selected.
The selection process begins with determining what your
requirements are. Without solid requirements generated from
business stakeholders, the rest of the progression will be in
vein. This step in the process may be more challenging than
originally anticipated as stakeholders may not agree on what the
requirements should be. However, getting the stakeholders on
the same page is critical and fundamental to the success of the
vendor selection and the final system implementation.
My preferred method for documenting high-level requirements in the vendor selection process is using Excel with the
requirements in the first column, and assigning a relative
point factor to the requirement in the second column. The
relative point factor is the importance placed on the requirement as it relates to the organization. As an organization, we
recently went through a vendor selection process for a claims
system. Figure 1 provides two examples. First, an example of
what is meant by high-level business requirements for a claims
system, and second what the relative point factors are for each
requirement.
The requirements shown in Figure 1 are business-related
requirements. The requirement gathering step should also take
into consideration technical, financial, implementation risk, and
contractual requirements. In our claims system example, we pro-
vided technical requirements where the system must be written
in .Net and support the use of SQL server. The financial require-
ments were around company size (revenue), number of employ-
ees (onshore, offshore, near shore) with the proper skill set, and
contract requirements (fixed vs. time and material). Lastly, we
included factors that would reduce implementation risk (experi-
ence, unofficial references, and key vendor employees).
Now that a list of high-level requirements are in place with
business representatives in agreement as to the relative priority
to the organization, the focus can shift to generating a list of
potential vendors. For a claims, or policy system, our goal was
to identify 12-15 potential vendors. To generate a list of potential vendors, reach out to your personal network of industry
IT managers, insurance and technology conferences, research
analysts, and trusted consultants.
Leveraging Social Networks
There are several social networks that you can leverage. I
belong to a couple of IT management LinkedIn groups that
are specifically focused on the insurance industry. Following a couple of groups will allow you to post questions about
potential vendors as well as interact with individuals that have
specific experience with different products. The new Insurance
Technology Association (ITA) group provides a forum for IT
managers to interact.
Organization is the Key for Selecting Vendors
An inside look at how one insurance IT manager goes about the difficult
task of keeping existing systems humming while searching for new
software solutions.