Information Systems Implementation

.. dable 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.

We Will Write a Custom Essay Specifically
For You For Only $13.90/page!

order now

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 entitys 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, its possible for policy holder to have zero to many vehicle under its policy. Entities/Legend This explains the Entities in a data model and its 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 companys 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 laymans 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 Vehicles 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.