Information Systems Implementation

скачати

Information Systems Implementation Essay, Research Paper

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.

Додати в блог або на сайт

Цей текст може містити помилки.

A Free essays | Essay
26.6кб. | download | скачати


Related works:
Systems Implementation
Strategic Information Systems
Geographic Information Systems
Planning Information Systems
Computer Information Systems
Management Information Systems
Geographic Information Systems
Business Information Systems
Geographic Information Systems
© Усі права захищені
написати до нас