Information Systems Implementation
Company provides auto insurance coverage for
licensed drivers in the state of
Indiana. The company’s headquarter is
located in the city of Speedway where it
has two strategic business units
located at the cities of Waterloo and Corydon.
In all, BWAIC employs
approximately 150 people with internal departments
consisting of the Policy,
Claims, Payroll, Personnel, and Insurance Agents.
Currently, BWAIC
insures 50,000 policyholders statewide. Last year, BWAIC’s
net profit was
$875,000. With certain state regulations, along with related
socioeconomic
impacts, the company expects an increase of new policies to
underwrite.
Accordingly, BWAIC is interested in positioning itself in the market
where:
1) Internal exchange of information is efficient, 2) It improves
its
Customer Service, 3) Share information with external business
contacts. PROJECT
OBJECTIVE To stimulate a vision within the company of
leading the market in
customer service through an efficient information
system and to utilize the most
current technologies at lowest possible cost.
EXPECTED BENEFITS Internal: An
improved information process where business
applications provide intelligent
solutions, secured data, and improved
communication exchange between units and
offices. External: To provide an
advantage over the market where the
interactions between the company and its
external business environment produces
customer satisfaction. Accordingly,
this will have a positive impact on customer
service where efficiency on the
point of contact, through the lifetime of the
policy, is evident. SYSTEMS
PROFILE Currently, BWAIC’s network setup doesn’t
provide an efficient
exchange of information between its key departments. Each
department utilizes
their own business transaction system within a mainframe
environment. This
input-output process performs the processing of their business
transactions.
The departments: Policy, Claims, Personnel, Payroll, Legal and
Insurance
Agents, have varying application needs. Likewise, they share a
common
interest – to achieve the best customer service possible. The
Policy
department has users that perform the administrative and technical
type of work
as it relates to underwriting insurance policies. The Claims
department has
users that perform calculations for the reserves of claims.
They review the
potential liability costs involve in customers’ claims. The
Legal department
relies heavily on an efficient exchange of information. The
Personnel, Policy
and Legal are information oriented departments. Claims and
Payroll, on the other
hand, relies heavily on accurate calculations of fiscal
data. It is reported
that the current databank is reaching its capacity. The
current system is also
inhibiting their customer service where the turnaround
to process a claim takes
about 90 days. The strategic locations of the
Business units also contribute to
the problems of the current system. The
mainframe system negatively impacts the
company’s ability to reach out to
their customers. The Insurance Agents are
limited to the office in terms of
processing new clients. Under the mainframe
system, the structure of the
database is costly to maintain and support. Also,
it limits the company’s
ability to intelligently process their information and
exchange them with
their external business environment. RECOMMENDED SOLUTIONS
There are a
variety of systems available in today’s market. Costs will depend
on the
company’s desire on long-term solutions. In today’s information
environment
BWAIC needs to position itself to compete with other insurance firms
with an
advantage of having the best technological tools. An efficient system
will
produce satisfied customers and intelligent employees. This change
in
information culture will allow the company to utilize their resources
more
efficiently where performance reports and external data help the
managers make
intelligent business decisions. It is without reservations that
I recommend the
following solutions for the BWAIC: Network Planning of the
backbone and the
network foundation is vital to the success of this project.
It is recommended
that a Client/Server network is implemented through a
TCP/IP protocol. Each
offices will operate as Local Area Network (LAN)
connected together as a Wide
Area Network (WAN). Each office and users
will have the ability to exchange
information instantaneously. This
configuration will produce the best and
secured environment for which
powerful machines (Server) produce and process the
information to the users
(Client) of the information. The backbone (Bandwidth)
have to support the
type of data that will travel between the offices and
through the customers.
Each department will utilize their own groupware that
will process their
information. This information system will be accessible via
remote access to
allow mobility and flexibility for managers to strategically
position their
resources and staff. To supplement this, it is recommended that
an Intranet
is put in place so as to allow information to external business
contacts and
customers via Extranet. The Intranet solution will also be the
method that
will enable E-Commerce activity and gain a market advantage
Conversion of
the database to a Relational Database Management System is also
vital. The
current database cannot be shared with external information
users.
Likewise, it does not produce the type of information that
produces intelligent
reports for management. The existing data will need to
be converted to an SQL
language so that it can be processed and controlled by
an Oracle Server. This
conversion will position the company to be supported
for future technological
growth and will have the ability to control the
anticipated increase of data.
Given the structure of BWAIC, it is
recommended that the headquarter maintains
and administer a central database.
This will provide security and the least
possible cost. Client Side
Information Processing Since each department has
different business needs, it
is vital that an extensive study be conducted as to
how, what, when, where
and why they will process the information. Preliminary
study is as follows:
Policy – This department will require a groupware that
gives them access to
their policy database. This application will be web-enabled
to allow mobile
and speedy access. Claims and Payroll – These departments will
require a
groupware that will give them the ability to make calculations and
have the
control of inventory. The Claims department will utilize a
web-enabled
application that interfaces with the Policy information as to the
status of
policyholders. Payroll, on the other hand, will have an application
for their
internal calculation needs as well as provide a "limited" version
to
frontline supervisors for accurate reporting. Insurance Agents –
This
department will have the most mobile needs. The will have access to
Policy and
underwriting information at their fingertips. Their web-based
application will
interface with the Internet forms that are produced as
customers are solicited.
Legal – This department will gain an advantage
over other firms by having
complete information. The trickle effect of
information efficiency throughout
BWAIC will result in confidence on
Claims adjusters and high level managers.
STUDY An extensive study of the
following will be performed in able to produce a
smooth transition to the new
environment: I. The backbone of the current system
to identify the size and
cost-benefit of the proposed plan II. Each departmental
needs and the
behavior of which they process information III. The users as to
how
sophisticated their computer knowledge to identify the training needs and
to
evaluate how they will adapt to the change (impacts on the rollout) IV.
The
resources of the company V. Identify and compare with a company with a
similar
structure and research the success and the feasibility the proposed
system VI.
Develop a systems support plan and develop a business disaster
plan to recover
the company should a catastrophe of loss data occur VII.
Analyze the complete
cost-benefit of the project and formulate a proposal
plan to the President This
is to apprise you with the second phase of the
Systems Re-Engineering Project
which you have hired my services to perform an
analysis on. This phase involves
the survey and the planning of the
relational database management system for
your company which was articulated
in my project proposal. As mentioned, I
highly recommend re-structuring your
existing current data model, which does not
produce efficient use of the
systems. This study of data modeling is vital to
the success of the overall
project. Afterall, the main asset of your company is
its data. Attached,
please find the following: 1) Entities/Legend 2) Context
Data Model 3)
Relational Data Diagram 4) Narrative Please do not hesitate to
contact me to
arrange a meeting regarding this phase or on any concerns you
might have.
Sincerely, Project Lead Relational Data Diagram Context Data Model
1.
Agents - An agent is assigned to many policies. This representative
maintains
the control of the policies and accordingly, the policies these
agents
underwrite is directly assigned to the writing agent. 2. Claims - A
particular
claim is related to two instances in this model - Estimate and
Policy Holder.
Under one claim, there can be multiple estimates as to a
particular claim. It is
also the standard that an estimate is incurred when a
claim is filed, thus
making the Estimate a dependent entity. As to the Policy
Holder, a claim is
dependent where it does not come to a fruition without
having a policy holder
filing it. 3. Estimate - This type of data is directly
related to the activity
of a claim. There is at least one estimate recordable
to make a claim valid. 4.
Invoice - This type of data has a one to one
relationship with a Policy.
Likewise, a policy cannot have duplicative
invoice and vice-versa. 5. Policy -
This data is central to the other
entities. All of other entities are invalid
without a Policy. Likewise, an
invalid Policy data will directly incur an
invalid data for all relating
entities. 6. Policy Holder - A Policy Holder has
relational data with the
Claims and Vehicle entities. This entity’s one to
many relationship initiates
most of the data activties. This entity can also be
considered as the central
entity. 7. Vehicle - A vehicle has a one to one
relationship with a policy. A
vehicle cannot have multiple policies. Likewise,
it’s possible for policy
holder to have zero to many vehicle under it’s
policy. Entities/Legend This
explains the Entities in a data model and it’s
related data. 1. Agents a)
Name b) Number c) Office Address d) Office City e)
Office State f) Office
Zip Code g) Office Phone Number 2. Claim a) Amount b)
Date c) Description
d) Number e) Payment Amount f) Payment Date g) Payment
Explanation h)
Rejection reason i) Status j) Coverage Amount k) Coverage Code
l)
Coverage Description m) Date of Accident n) Date of Policy
Cancellation o)
Description of Accident p) Driver Street Address q)
Driver City r) Driver State
s) Driver Zip Code t) Driver License Number
u) Driver Name v) Driver Phone
Number 3. Estimate a) Estimate Amount b)
Estimate Company Name c) Estimate
Description 4. Invoice a) Invoice
Amount b) Invoice Amount Due c) Invoice Date
d) Invoice Date Due e)
Invoice Number f) Payment Amount g) Payment Date h) Place
of Accident 5.
Policy a) Effective date b) Cancellation date c) Cancellation
reason d)
Effective date e) Expiration data 6. Policy Holder a) Street address
b)
City c) State d) Zip Code e) Birth date f) Drivers License Number g)
Employer
h) Gender i) Home Phone number j) Marital Status k) Name l)
Number m) Occupation
n) Work Phone Number o) Discount p) Policy Number q)
Policy Officer Badge number
r) Policy Officer name s) Policy Rejected
Date t) Policy Rejected Reason u)
Policy type v) Reason for cancellation
w) Time of Accident 7. Vehicle a) VIN
number b) Vehicle Type (make + model +
style) c) Weather conditions d) Special
coverage Data Model Narrative A
Policy Holder and Policy are the central
information of the data model. From
these entities, come vital information to
make the data relationships valid.
These entities are the parent of the data
structure. Inputs and outputs are
generated from these entities. Consequently,
the context of these entities
must be analyzed thoroughly to avoid the oversight
of important information.
The data study of these two entities should also
result an extensive study of
the technological end to identify the most
efficient, secured and controlled
systems environment. From the Policy Holder
standpoint, a one to many data
relationship is produced within Claims, Vehicle
and Policy. The Claims,
Vehicle and Policy have "children" or subset
entities relating to them. The
Claims entity requires a one to may relationship
to Estimates which is
according to the company policy of approving claims.
Likewise, a policy
holder can have one to many claims and zero to many vehicle
for which to
purchase coverage for. A policy holder also has a choice of a
variety of
insurance coverages. This then creates a one to many relationship
between the
Policy Holder and Policy. From the Policy standpoint, a likely item
that a
policy produces is an Invoice. To control the indexing and proper
account
practice, an implementation of one to one is suggested. An Agent is
also an
identified dependent to a Policy data where a policy is handled by a
particular
agent. Obviously, an agent has the ability to produce many
policies, thus the
relationship of one to many is implemented. Our team has
completed the third
phase of the systems remodeling project. This phase
covers the Information
Process Modeling for your company. You will find
included in this memo: 1)
Decomposition diagram, 2) Context Diagram and
3) Data flow diagram. The diagrams
describe how your data will be structured
and their processes. The Decomposition
diagram dissects your company’s
information process into smaller subsystems,
which further are divided into
subsystems. The Context diagram illustrates and
outlines the system, it hopes
to give you a scope and boundaries for the system.
The Data Flow diagram
illustrates the entire input and output process. While the
diagrams
illustrates the process and the scope of the project, the narrative
will
explain the process in layman’s terms. Please do not hesitate to call
me
should you have any questions, comments or concerns. Sincerely, Narrative
This
documentation consists of three diagrams: the Decomposition diagram, the
Context
Diagram and the Data flow diagram. The Decomposition diagram,
through its term,
is self-explanatory. It decomposes a system into different
subsystems so that it
simplifies the process and updates the various
transactions and data. In our
review, the Big Wheel systems is divided into
two subsystems: Policy and Claims.
This makes the task less complicated
for Big Wheel to identify and process the
various claims related to
corresponding policies. Policy and Claims subsystems
are further divided into
four subsystems: Transaction Process, Management
Process, Decision
Process, and Data Maintenance. The Transaction Process, under
Policy, is
subdivided into Insurance Policy Application, Insurance Policy
Payment,
Insurance Policy Modification and Insurance Policy Cancellation.
The
Management report is divided into: detail report, summary report,
exception
report and query report. The Detail Report has four divisions:
policy master
listing, invoice master listing, policyholder master listing,
agent master
listing. The summary report is broken into: policies by agent,
invoice by agent,
policies by vehicle type. The exception report is broken
into: policy invoice
past due, rejected policy application, and cancelled
policy. The query report is
divided into: policy query, invoices for a
policy, policy payment query, and
policyholder query. The Claim subsystems
transaction process consists of data
from the Policyholder. Since management
reporting under Claims is limited, it
consists of mainly Claims reports and
queries. Claims reports and queries are
further divided into: claim master
listing, claim by policy, claim by vehicle
type, rejected claim, claims
without estimate, claims against a policy query,
estimate for a claim query
and claim payment query. The Context Diagram also is
defined by its term. It
consists of context of the entire system. In our case,
the context diagram
shows that Potential Policyholder or the applicant applies
for a policy. Big
Wheel accepts the application stores it and sends a request to
DMV for
verification of the owner. Depending on the response of DMV, it accepts
or
declines the policy accordingly. Similar types of request regarding
accidents
and other record of applicant are sent to the Police department and
according to
their response, the policy coverage and acceptance are
processed. The data flow
diagram is an expanded version of the context
diagram. The data flow diagram
illustrates how the data flow throughout the
system, from the input and output
of the process. In our review, we identify
three processes: Application process,
Policy modification and
cancellation process and the Claims process. The
Application process is
where the applications are processed through the
verifications from the DMV
and the Police Department. The Policy modification
and cancellation consists
of verifying if the policyholder and the policy. A
refund or balance due is
calculated and either a refund or an invoice is sent to
the policyholder and
the policy is modified or cancelled. The Claims process is
more involved as
compared to the other two processes. It consists of accepting a
claim
application, verifying it against the policy and then the processing of
the
claim. If the claim matches the coverage of the policy, then the claim
is
processed other wise it is rejected. If an accident is reported in the
claim,
the report is sent to the Police Department for their review. Should
the
policyholder be at fault in the accident, then the claim is paid and the
policy
is updated to reflect an increase rate for the next invoice. #4 The
location
connectivity diagram reflects the network structure to its basic
form. The
central headquarter housing the newly created Information Systems
department
will maintain and administrate the overall network operations. As
described,
each location will be operating within its own Local Area Network
connected over
the Wide Area Network. Each office will have its own main
servers and hubs
connected over a gigabit connection. The connection between
a user and the
server under the client-server environment will be connected
on 10/100 megabyte
wiring. The backbone wiring the entire WAN, for ensured
speed and uninterrupted
data flow, will be over an ATM (Asynchronous Transfer
Mode) wiring. The Policy
and Claims database for the entire company will be
on Oracle servers located
centrally. There will also be an Oracle server
dedicated for the Payroll
department located at the Waterloo office. The
central database will be
compatible to the Department of Vehicle’s database
server. This will alleviate
any transmission problems caused by
incompatibilities. In the headquarter
office, there will be a Remote Server
authenticating the mobile Insurance
Agents. There will be an Intranet
environment to support these telecommuters.
Likewise the central database
will be compatible to the web enabled front-end
application for which the
agents will use.