Đề tài Phân tích và thiết kế chương trình quản lý hợp đồng bảo hiểm

SS (Decision Support System). + Hệ thống chuyên gia ES (Expert System). + Hệ thống thông tin tăng cường khả năng cạnh tranh ISCA (Information System For Competitive Advantage). Phân loại HTTT trong tổ chức doanh nghiệp Các thông tin trong một tổ chức được phân chia theo cấp quản lý và trong mỗi cấp quản lý chúng lại được chia theo nghiệp vụ mà chúng phục vụ, được thể hiện qua sơ đồ sau: Tài chính chiến lược Marketing chiến lược Nhân lực chiến lược Kinh doanh và sản xuất chiến lược Tài chính chiến thuật Marketing chiến thuật Nhân lực chiến thuật Kinh doanh và sản xuất chiến thuật Hệ thống thông tin văn phòng Tài chính tác nghiệp Marketing tác nghiệp Nhân lực tác nghiệp Kinh doanh và sản xuất tác nghiệp Phân loại HTTT theo lĩnh vực và mức ra quyết định 2.1.2.4. Mô hình biểu diễn hệ thống thông tin Một HTTT có thể được mô tả theo nhiều cách khác nhau, khái niệm mô hình rất quan trọng vì nó tạo ra một trong những nền tảng của phương pháp phân tích thiết kế và cài đặt hệ thống thông tin. Có ba mô hình được dùng để mô tả hệ thống thông tin: Mô hình logic, mô hình vật lý ngoài, mô hình vật lý trong. Mô hình logic (Góc nhìn quản lý) Mô hình vật lý ngoài (Góc nhìn sử dụng) Mô hình vật lý trong (Góc nhìn kỹ thuật) Mô hình ổn định nhất Mô hình hay thay đổi nhất Cái gì? Để làm gì? Cái gì? Ở đâu? Khi nào? Như thế nào? Mô hình biểu diễn một hệ thống thông tin Mô hình logic: Mô tả hệ thống làm gì, dữ liệu mà nó thu thập xử lý phải thực hiện, các kho để chứa các kết quả hoặc dữ liệu để lấy ra cho các xử lý phải thực hiện, các kho để chứa các kết quả hoặc dữ liệu để lấy ra cho các xử lý và những thông tin mà hệ thống sản sinh ra. Mô hình này trả lời các câu hỏi “cái gì” và “để làm gì?” chứ nó không quan tâm đến phương tiện được sử dụng cũng như địa điểm hay thời điểm mà dữ liệu được xử lý. Mô hình vật lý ngoài: Chú ý tới những khía cạnh nhìn thấy được hệ thống như: vật mang dữ liệu và vật mang kết quả cũng như hình thức đầu vào và đầu ra, phương tiện để thao tác với hệ thống, những dịch vụ, bộ phận, con người và vị trí công tác trong hoạt động xử lý, các thủ tục thủ công cũng như các yếu tố về địa điểm thực hiện xử lý dữ liệu, loại màn hình, bàn phím sử dụng. Mô hình này cũng chú ý tới mặt thời điểm mà các hoạt động xử lýdữ liệu cùng xảy ra. Nó trả lời câu hỏi: Cái gì? Ai? Ở đâu? Khi nào? Mô hình vật lý trong: liên quan tới những khía cạnh vật lý của hệ thống tuy nhiên không phải là cái nhìn của người sử dụng mà là của nhân viên kỹ thuật. Chẳng hạn đó là thông tin liên quan tới trang thiết bị được dùng để thể hiện hệ thống dung lượng kho lưu trữ và tốc độ xử lý của các thiết bị, tổ chức vật lý của dữ liệu trong kho chứa, cấu trúc các chương trình và ngôn ngữ thể hiện. Mô hình trả lời câu hỏi: Như thế nào? Cả ba mô hình đều có độ ổn định khác nhau trong đó mô hình logic có độ ổn định cao nhất và hay thay đổi nhiều nhất là mô hình vật lý trong. Trong một HTTT, với một mô hình vật lý ngoài có thể tồn tại nhiều mô hình vật lý trong tương ứng nên dựa vào thực tế chi phí, hiệu quả kỹ thuật và nhiều yếu tố liên quan để xét duyệt và lựa chọn mô hình vật lý trong sao cho phù hợp. Một HTTT thường được mô tả theo ba mô hình sau: Lưu trữ dữ liệu Logic Vật lý ngoài Vật lý trong Logic Vật lý ngoài Vật lý trong Logic Vật lý ngoài Vật lý trong Thông tin ra Thông tin vào Logic Vật lý ngoài Vật lý trong Đích Nguồn Một HTTT theo ba mô hình 2.2. Nguyên nhân dẫn đến viếc phát triển một HTTT 2.2.1. Những vấn đề về quản lý Trước khi có máy tính, vấn đề quản lý đối với một doanh nghiệp thực sự là rất khó khăn và phức tạp. Ví dụ như việc truyền yêu cầu và mệnh lệnh từ giám đốc tới nhân viên sẽ phải thông qua nhiều người, tốn nhiều thời gian, thậm chí có thể bị sia lệch về nội dung. Trong khi đó nếu sử dụng HTTT trong doanh nghiệp và sự kết nối mạng, thông tin sẽ được truyền đi một cách nhanh chóng và chính xác, người quản lý có thể truyền mệnh lệnh trực tiếp cho cá nhân phụ trách công việc. Ngoài vấn đề về truyền đạt các yêu cầu và mệnh lệnh, vấn đề cập nhật thông tin như chính sách thuế, thông tin về khách hàng… cũng được thực hiện nhanh chóng và chính xác hơn. Căn cứ vào thông tin được cập nhật cán bộ quản lý có thể ra những quyết định nhanh chóng mang tính chiến lược. Ngày nay, cùng với sự phát triển rất nhanh của xã hội thì quy mô các doanh nghiệp cũng phát triển với tốc độ tương tự. Các tổ chức doanh nghiệp lớn không chỉ làm việc tại một cơ sở mà ở nhiều cơ sở, nhiều chi nhánh và đại lý ở khắp trong và ngoài nước, tuy vậy trụ sở chính thì chỉ ở một nơi. Do vậy việc quản lý ngày càng trở nên cực kỳ phức tạp. Vậy yêu cầu đặt ra là làm sao để các nhà quản lý có thể ngồi một chỗ mà vẫn có thể uản lý được mọi hoạt động của cơ quan? Để làm được điều đó bắt buộc người quản lý phải dựa vào công nghệ tin học, một HTTT hiện đại sẽ là phương pháp hữu hiệu nhất trong trường hợp này. 2.2.2. Yêu cầu của lãnh đạo Những yêu cầu mới của nhà quản lý cũng có thể dẫn đến sự cần thiết phát triển một HTTT mới. Người lãnh đạo trong cơ quan thì luôn cần các công cụ hỗ trợ cho hoạt động quản lý của mình. Với một HTTT có tính chuyên nghiệp và hiệu quả sẽ là một công cụ trợ giúp đắc lực cho các nhà lãnh đạo. Các quyết định của nhà lãnh đạo liên quan trực tiếp đến sự thành công hay thất bại của cơ quan. Để có được các quyết định đúng đắn thì nhf lãnh đạo cần những căn cứ xác đáng, các nguồn thông tin nội bộ hay bên ngoài đầy đủ và chính xác. Nếu có được một HTTT quản lý tốt thì việc thu thập thông tin sẽ trở nên đơn giản hơn nhiều. 2.2.3. Yêu cầu của công nghệ Áp dụng công nghệ tiên tiến vào trong quản lý không chỉ của riêng cơ quan, doanh nghiệp nào mà là một nhu cầu bắt buộc chung của xã hội. Trên thực tế, công nghệ tiên tiến hiện đại cũng la một lợi thế thương mại của các công ty. Đặc biệt trong những năm gần đây, lợi thế thương mại này được cạnh tranh một cách gay gắt và trở thành cuộc chạy đua công nghệ trong các doanh nghiệp. Sự thành, bại của các doanh nghiệp cũng phụ thuộc cơ bản vào việc doanh nghiệp đó có áp dụng công nghệ tiên tiến nhất hay không? Nói đến việc áp dụng công nghệ mới thì chúng ta không thể chỉ nói đến công nghê trong sản xuất ma phải áp dụng cả trong công tác quản lý. Việc xuất hiện các công nghệ mới cũng có thể dẫn đến việc một tổ chức phải xem lại những thiết bị hiện có trong tổ chức của mình. Khi các hệ quản trị cơ sở dữ liệu ra đời nhiều tổ chức phải rà soát lại HTTT của mình để quyết định những gì họ sẽ phải cài đặt, phải thay đổi khi muốn sử dụng những công nghệ mới này. Tuy nhiên sự thay đổi như vậy không thể thực hiện một cách nhanh chóng được, nó sẽ làm sáo trộn hệ thống quản lý cũng như sản xuất của tổ chức. Muốn vậy ta có thể áp dụng từ từ hệ thống mới để người sử dụng có thể làm quen với sự thay đổi và những chức năng hiện đại hơn. Cũng có những HTTT được phát triển chỉ vì người quản lý muốn mở rộng quyền lực của mình bởi vì ông ta biết rằng thông tin là một phương tiện có thể thực hiện điều đó. 2.2.4. Sự thay đổi về sách lược chính trị Một nguyên nhân rất quan trọng buộc các tổ chức phải thay đổi HTTT cũ đó là các chính sách của nhà nước. Các chính sách được đưa ra mang tính cưỡng chế thi hành và không có sự lựa chọn. Chính vì vậy các tổ chức không thể không thay đổi, phát triển HTTT của mình. Hiện nay nhà nước đang có chủ trương xây dựng “chính phủ điện tử” nên việc tin học hoá công tác quản lý của các tổ chức là vô cùng cần thiết. Tuy nhiên việc người ta nhận ra yêu cầu phát triển HTTT rõ rang là chưa đủ để bắt đầu sự phát triển này. Trong phần lớn các tổ chức, có các cơ chế chính thức đang tồn tại, để xác định liệu một nghiên cứu phát triển về HTTT có nên được thực hiện hay không. Vấn đề là một yêu cầu đơn giản gửi tới từ một bộ phận hoặc một phòng ban đến lãnh đạo các bộ phận tin học của một tổ chức, những người này chịu trách nhiệm quyết định yêu cầu có thể chấp nhận được không? Bởi vì tình trạng như vậy có thể được xem như là để ngỏ, nhiều tổ chức đặt ra một hội đồng tin học được ccấu thành từ người chịu trách nhiệm về tin học cùng với những người chịu trách nhiệm về các chức năng chính của tổ chức. Cách thức này đảm bảo mọi khía cạnh đều được xem xét khi một quyết định được đưa ra. Quyết định của hội đồng hoặc của người chịu trách nhiệm về tin học trong một số trường hợp, có thể không bắt buộc phải dẫn tới việc cài đặt một hệ thống mới, nó chỉ mới khởi động một dự án phát triển. Suốt quá trình của dự án, người ta phải xem lại quyết định này có nghĩa là phải xác định xem sẽ tiếp tục dự án hay kết thúc nó. 2.3. Mục đích xây dựng một HTTT Một HTTT tốt luôn là công cụ hỗ trợ đắc lực trong quản lý và sản xuất. Đó chính là lý do và mục tiêu duy nhất để xây dựng và phát triển một hệ thống. Vậy có những tiêu chuẩn nào có thể đánh giá một hệ thống là tốt? Ta có thể căn cứ vào sự thuận tiện của hệ thống, tính than thiện của nó…nhưng quan trọng nhất vẫn là những gì mà nó cung cấp. Thông tin đầu ra là một hệ thống cung cấp phải đảm bảo thoả mãn được yêu cầu của người sử dụng. Tiêu chuẩn để đánh giá thông tin là: Độ tin cậy thể hiện các mặt về tính xác thực và độ chính xác. Thông tin ít độ tin cậy sẽ gây cho tổ chức những hậu quả tồi tệ. Chẳng hạn hệ thống lập hoá đơn bán hàng có nhiều sai sót, nhiều khách hàng kêu ca về tiền phải trả ghi cao hơn giá trị hàng đã thực mua sẽ dẫn đến hình ảnh xấu về cửa hàng, lượng khách hàng sẽ giảm và doanh số bán sẽ giảm xuống. Nếu số tiền ghi trên hoá đơn thấp hơn số tiền phải trả thì cửa hàng sẽ bị thất thu. Tính đầy đủ của thông tin thể hiện sự bao quát các vấn đề đáp ứng yêu cầu của nhà quản lý. Nhà quản lý sử dụng một thông tin không đầy đủ có thể dẫn đến các quyết định và hành động không đáp ứng được với đòi hỏi của tình hình thực tế. Ví dụ một nhà sản xuất ghế tựa yêu cầu báo cáo về số lượng ghế làm ra mỗi tuần. Để so sánh, báo cáo cũng có nêu ra số lượng ghế làm ra mõi tuần trước đó và của cùng kì năm trước. Ông chủ thấy số lượng ghế là ra tăng đều và có thể sẽ cho rằng tình hình sản xuất là tốt đẹp. Tuy nhiên trong thực tế có thể hoàn toàn khác, HTTT chỉ cung cấp số lượng ghế sản xuất mà không phản ánh về năng suất. Một sự không đầy đủ của HTTT như vậy sẽ gây thiệt hại cho doanh nghiệp. Tính thích hợp và dễ hiểu Nhiều nhà quản lý không muốn sử dụng một số loại báo cáo mặc dù chúng liên quan tới các hoạt đọng thuộc trách nhiệm của ông ấy. Nguyên nhân chủ yếu là do chúng chưa thích hợp và khó hiểu. Có thể là có quá nhiều thông tin chưa thích ứng, thiếu sự sang sửa, sử dụng quá nhiều từ viết tắt hoặc đa nghĩa hoặc bố trí chưa hợp lý của các trường thông tin. Điều đó dẫn đến hoặc là tốn phí cho việc tạo ra nhưng thông tin không dùng hoặc là ra quyết định sai và thiếu thông tin cần thiết. Tính được bảo vệ thông tin là một nguồn lực quý báu của một tổ chức cũng như vốn và nguyên vật liệu. Thật hiếm có doanh nghiệp nào mà bất kỳ ai cũng có thể tiếp cận được tới vốn hoặc nguyên liệu, và cũng phải làm như vậy đối với thông tin. Thông tin phải được bảo vệ và chỉ những người được quyền mới được phép tiếp cận tới thông tin. Sự thiếu an toàn về thông tin cũng có thể gây ra những thiệt hại lớn cho tổ chức. Tính kịp thời thông tin có thể là tin cậy, dễ hiểu và thích ứng và được bảo vệ an toàn nhưng vẫn không có ích khi nó không được gửi tới người sử dụng vào lúc cần thiết. Một công đoàn có thể biểu tình nếu việc phiếu trả lương phát chậm nhiều lần, một cửa rút tiền tự động có thời gian trả lời tới 5 phút thì sẽ mất khách hàng rất nhanh. Làm thế nào để một hệ thống thông tin hoạt động tốt có hiệu qủ cao là một trong những cong việc của bất kì một nhà quản lý hiện đại nào. Để giải quyết vấn đề đó cần phải xem xét cơ sở kỹ thuật cho các hệ thống thông tin, phương pháp phân tích thiết kế và cài đặt hệ thống thông tin. Trên đây là những tiêu chuẩn để đánh giá một hệ thống thông tin trong doanh nghiệp nói chung, nhưng tuỳ từng doanh nghiệp áp dụng hệ thống thông tin mà nó sẽ có thêm những tiêu chuẩn riêng khác nhau. Riêng đối với Công ty Bảo hiểm Dầu khí – chi nhánh KV Tây Bắc thì đòi hỏi một hệ thống thông tin tốt là phải đáp ứng được các yêu cầu sau: Luôn cập nhật thông tin kịp thời, cho phép đưa ra báo cáo chính xác tại mọi thời điểm. Phần mềm phải có giao diện đẹp, hài hoà và thân thiện. Phần mầm phải có tính dễ sử dụng và tính bảo mật cao. 2.4. Phương pháp phát triển một HTTT Mục đích của việc xây dựng, phát triển HTTT là có được một sản phẩm đáp ứng nhu cầu của người sử dụng, hoà nhập vào các hoạt đọng của tổ chức, chính xác về mặt kỹ thuật, tuân thủ các giới hạn về tài chính và thời gian định trước. Không nhất thiết phải theo đuổi một phương pháp để phát triển một HTTT, tuy nhiên nếu không có phương pháp ta có nguy cơ không đạt được những mục tiêu đã đặt trước. Một HTTT là một đối tượng phức tạp, vận đọng trong một môi trường rất phức tạp. Để thực sự làm chủ được nó, cần có một phương pháp để tiến hành. Sau đây là các công đoạn xây dựng, phát triển một HTTT. 2.4.1. Giai đoạn đánh giá yêu cầu Một dự án phát triển hệ thống không tự động tiến hành ngay sau khi có bản yêu cầu vì loại hình dự án này đòi hỏi đầu tư không chỉ tiền bạc, thời gian mà còn cả nguồn nhân lực và chất xám. Do đó việc quyết định vấn đề này phải được thực hiện sau khi phân tích cho phép xác định cư hội và khả năng thực thi. Sự phân tích này được đánh giá hay thẩm định yêu cầu hay còn gọi là nghiên cứu khả thi và cơ hội. Đánh giá đúng yêu cầu là yếu tố quyết định cho sự thành công của một dự án. Chỉ cần một sai lầm nhỏ cũng có thể gây ra hao tổn tiền bạc, nhân lực hay đẩy lùi tiến trình thực hiện dự án, thậm chí có thể phá hỏng dự án. Đánh giá yêu cầu được bắt đầu từ việc nêu vấn đề, ước đoán độ lớn của dự án và những thay đổi có thể, đánh giá tác động cuả những thay đổi và tính khả thi của dự án, những gợi ý hỗ trợ cho người ra quyết định. Giai đoạn này được tiến hành trong thời gian tương đối ngắn để tiết kiệm chi phí về thời gian và tiền của. Giai đoạn này bao gồm các công việc cụ thể như sau: Lập kế hoạch: Gồm các công việc như làm quen với hệ thống đang xét, xác đinh thông tin cần thu thập cũng như nguồn và phương pháp thu thập. Làm rõ yêu cầu: Giúp cho phân tích viên hiểu rõ yêu cầu của khách hàng, xác định chính xác đối tượng yêu cầu, thu thập những yếu tố cơ bản của môi trường hệ thống và định dạng khung cảnh nghiên cứu. Đánh giá khả thi: Tìm xem có những yếu tố nào ngăn cản sự thành công của dự án, đánh giá khả thi về tổ chức, về tài chính, về thời hạn và kỹ thuật. Chuẩn bị và trình bày báo cáo đánh giá yêu cầu. 2.4.2. Giai đoạn phân tích chi tiết Đây là giai đoạn giúp cho cán bộ phân tích hiểu sâu sắc và toàn vẹn về hệ thống thông tin đàn tồn tại – nghĩa là xác định được những vấn đề chính cũng như các yêu cầu nảy sinh của chúng, xác định được các công việc phải làm, các công cụ được sử dụng cũng như mục tiêu cần đạt được của hệ thống mới. Các công việc cần thực hiện trong giai đọcn này bao gồm: Lập kế hoạch phân tích chi tiết. Nghiên cứu môi trường của hệ thống thực tại. Nghiên cứu hệ thống thực tại. Chuẩn đoán và xác định các yếu tố giải pháp. Đánh giá lại tính khả thi. Sửa đổi đề xuất của dự án. Chuẩn bị và trình bày báo cáo phân tích chi tiết. Để có thể nghiên cứu chính xác được môi trường của hệ thống cũ. Các phương pháp thu thập thông tin gồm: + Phỏng vấn: Đây là công cụ đắc lực, ta có thể thu được những nội dung cơ bản khái quát về hệ thống mà tài liệu không thể có được hay gặp được những người có trách nhiệm, nắm được mục tiêu của tổ chức. + Sử dụng phiếu điều tra: Phương pháp này sử dụng khi phải lấy thông tin từ một số lượng lớn các đối tượng và trên phạm vi điạ lý rộng lớn. Nhưng để vận dụng phương pháp này thì người gửi thường phải là những người cấp trên của các đối tượng nhận phiếu. + Quan sát: Đây là phương pháp khó khăn và tốn thời gian vì người bị quan sát có thể hoạt động không giống thực tế mà người sử dụng có vai trò rất quan trọng khi tham gia vào đội ngũ phân tích. Sau bước thu thập thông tin, dữ liệu được tập chung và được chuẩn bị cho việc phân tích. Nhưng trước khi phân tích những dữ liệu này nhất thiết phải mã hoá. Mã hoá được xem là việc xây dựng một tập hợp những hàm thức mang tính quy ước và gán cho tập hợp này một ý bằng cách cho liên hệ với tập hợp những đối tượng cần biểu diễn. Hay nói một cách khác, việc mã hoá thông tin là thay thế thông tin ở dạng “tự nhiên” thành một dãy kí hiệu thích ứng với mục tiêu của người sử dụng. Mục tiêu đó là nhận diện nhanh và không nhầm lẫn các đối tượng, mô tả nhanh chóng các đối tượng, tiết kiệm không gian lưu trữ và thời gian xử lý, thực hiện những phép kiểm tra logic hình thức hoặc thể hiện vài đặc tính của đối tượng. Các phương pháp mã hoá cơ bản - Phương pháp mã hoá phân cấp - Phương pháp mã hoá liên tiếp - Phương pháp mã hoá tổng hợp - Phương pháp mã hoá theo seri - Phương pháp mã hoá gợi nhớ - Phương pháp mã hoá ghép nối Cách thức tiến hành mã hoá Xác định tập hợp các đối tượng cần mã hoá Xác định các xử lý cần thực hiện Lựa chọn giải pháp mã hoá + Xác định lựa chọn đẳng cấp các tiêu chuẩn lựa chọn. + Kiểm tra lại những bộ mã hiện hành. + Tham khảo ý kiến của người đã sử dụng. + Kiểm tra độ ổn định của các thuộc tính. + Kiểm tra khả năng thay đổi của các đối tượng. Các công cụ sử dụng trong giai đoạn phân tích chi tiết Để có cái nhìn tổng quát đối với một HTTT, cán bộ phân tích phải tiến hành mô hình hoá hệ thống đó. Có nghĩa là phải biểu diễn hệ thống đó dưới dạng các mô hình, sơ đồ hay hình hoạ nhằm giúp cho tất cả mọi người có thể hiểu một cách tổng quát và nhanh chóng đối với hệ thống. Hiện nay có các công cụ phổ biến để mô hình hoá hệ thống đó là: Sơ đồ luồng thông tin (Information Flow Diagram - IFD), sơ đồ luông dữ liệu (Data Flow Diagram). Sơ đồ luông thông tin (IFD) Tin học hoá hoàn toàn Giao tác người - máy Thủ công Xử lý Kho lưu trữ dữ liệu Tin học hoá Thủ công - Điều khiển - Dòng thông tin Tài liệu Các phích vật lý Phích luồng thông tin Phích kho chứa dữ liệu Phích chứa xử lý Sơ đồ luông dữ liệu (DFD) DFD dùng để mô tả chính HTTT nhưng trên góc độ trừu tượng. Trên sơ đồ chỉ bao gồm các luông dữ liệu, các xử lý, các lưu trữ dữ liệu, nguồn và đích nhưng không hề quan tâm tới nơi, thời điểm và đối tượng chịu trách nhiệm xử lý. Sơ đồ IFD chỉ đơn thuần mô tả hệ thống làm gì? và để làm gì? Tên người/bộ phận phát nhận thông tin Các kí pháp dùng cho DFD Nguồn hoặc đích Tên dòng dữ liệu - Dòng dữ liệu Tên tiến trình xử lý - Tiến trình xử lý Tệp dữ liệu - Kho dữ liệu Các mức của DFD Sơ đồ ngữ cảnh (Context diagram) thể hiện nội dung tổng quát nhất của hệ thống thông tin. Trong sơ đồ này có thể bỏ qua các xử lý cập nhật, các kho dữ liệu. Sơ đồ ngữ cảnh hay còn gọi là sơ đồ mức 0. Sơ đồ phân rã: nhằm mô tả chi tiết hơn nội dung của hệ thống. Bắt đầu từ sơ đồ ngữ cảnh, sẽ phân rã thành sơ đồ mức 0, mức 1, 2… Các phích logic Phích luồng dữ liệu Phích phần tử thông tin Phích kho dữ liệu Phích tệp dữ liệu 2.4.3. Thiết kế logic Mục đích của công đoạn này là xác định một cách chi tiết và chính xác những gì hệ thống mới phải làm để đạt được những mục tiêu đã thiết lập từ giai đoạn trước. Sản phẩm cuối cùng của giai đoạn này là các sơ đồ luồng dữ liệu DFD, các sơ đồ cấu trúc dữ liệu DSD, các sơ đồ phân tích và tra cứu, các phích logic của từ điển hệ thống. Các công việc chính của giai đoạn này gồm: Thiết kế cơ sở dữ liệu Thiết kế xử lý Thiết kế các dòng vào Hoàn chỉnh tài liệu logic Hợp thức hoá mô hình logic Thiết kế cơ sở dữ liệu là công việc rất khó khăn và phức tạp, bởi phân tích viên sẽ phải gặp gỡ những người sử dụng và hỏi họ danh sách dữ liệu mà họ cần. Việc hỏi han này thường không đạt hiệu quả cao và sẽ dễ dàng làm cho hệ thống có những phần không đạt yêu cầu. Để khắc phục tình trạng này, phân tích viên bắt buộc phải phân tích kĩ lưỡng cơ sở dữ liệu của hệ thống, thậm chí có thể phải làm việc đơn độc và sẽ tuỳ từng trường hợp mà có những phương pháp thu thập thích hợp. Tuy nhiên phân tích viên có thể áp dụng một trong những phương pháp sau: Thiết kế dữ liệu từ các thông tin đầu ra: đây là phương pháp cổ điển và cơ bản của việc thiết kế cơ sở dữ liệu.Phương pháp này dựa trên các văn bản hay báo cáo đầu ra để từ đó xác định các trường dữ liệu cần thiết. Vấn đề quan trọng nhất của phương pháp này là áp dụng các chuẩn hoá trong quá trình lọc dữ liệu. Các mức chuẩn hoá như sau: Chuẩn hoá mức 1: mỗi danh sách không được phép chứa những thuộc tính lặp. Nếu có các thuộc tính lặp thì phải tách các thuộc tính lặp đó thành các danh sách con, có một ý nghĩa dưới góc độ quản lý đồng thời gắn tên và thuộc tính định danh riêng cho nó. Chuẩn hoá mức 2: Trong một danh sách mỗi thuộc tính phải phụ thuộc hàm vào toàn bộ khóa chứ không chỉ phụ thuộc vào một phần của khoá. Nếu có sự phụ thuộc như vậy thì phải tách những thuộc tính đó thành một danh sách con mới. Chuẩn hoá mức 3: Trong một danh sách không được phép có sự phụ thuộc bắc cầu giữa các thuộc tính. Phải tách chúng thành các thuộc tính riêng rẽ, gán tên và xác định khóa cho chúng. Thiết kế cơ sở dữ liệu bằng phương pháp mô hình hoá: Đây là phương pháp dựa trên sự thể hiện giữa các thực thể với nhau thông qua các liên kết. Sự thể hiện này được biểu diễn trên mô hình quan hệ thực thể. Mối quan hệ giữa các thực thể với nhau có thể dưới dạng một - một (1@1), một - nhiều (1@N), nhiều - nhiều (N@N). 2.4.4. Đề xuất các phương án của giải pháp Cho tới giai đoạn này cán bộ tin học đã có thể xác định được những xử lý, cơ sở dữ liệu cần có của hệ thống và nhiệm vụ cần đạt được của hệ thống mới. Tuy nhiên họ vẫn chưa biết được cách thức xử lý nào được dùng là hợp lý nhất, phương tiện nào thích hợp, có tính khả thi nhất và môi trường của HTTT là như thế nào? Đây cũng chính là mục đích mà cán bộ tin học cần đạt được trong giai đoạn này. Cụ thể họ sẽ phải làm những công việc như sau: Xác định các rang buộc tin học và tổ chức. Xây dựng các phương án của giải pháp. Đánh giá các phương án của giải pháp. Chuẩn bị và trình bày báo cáo. Công việc quan trọng nhất của giai đoạn này là đánh giá phương án của giải pháp. Bởi thực chất đó là quá trình phân tích, đánh giá chi phí và lợi ích của phương pháp. Kết quả của việc đánh giá này sẽ quyết định dự án có được tiếp tục triển khai nữa hay không, hay phải hay đổi theo phương pháp thực hiện khác. Nếu như việc đánh gía bị sai lệch thì sẽ gây hao tổn rất lớn và ảnh hưởng mạnh tới kết quả về sau của dự án. 2.4.5. Thiết kế vật lý ngoài Thực chất của giai đoạn thiết kế vật lý ngoài là mô tả chi tiết phương án của giải pháp đã được lựa chọn ở giai đoạn trước. Đó là những mô tả về giao diện, về các thao tác người sử dụng sẽ cần sử dụng đến. Thiết kế cách thức tiếp cận hệ thống… Kết quả của giai đoạn thiết kế vật lý ngoài sẽ tác đọng đén việc dự án có được người tiêu dùng chọn lựa và áp dụng lâu dài hay không? Bởi vì đối với người sử dụng giao diện thân thiện, thao tác dễ dàng, dễ hiểu là một tiêu chuẩn đánh giá rất quan trọng. Cụ thể phân tích viên sẽ phải thực hiện các công việc như sau: Lập kế hoạch thiết kế vật lý ngoài. Thiết kế chi tiết các giao diện vào ra. Thiết kế cách thức tương tác với phần tin học hoá. Thiết kế các thủ tục thủ công. Chuẩn bị và trình bày báo cáo. 2.4.6. Triển khai kỹ thuật hệ thống Triển khai kỹ thuật hệ thống thông tin là thực hiện việc lựa chọn công cụ phát triển hệ thống, tổ chức vật lý của cơ sở dữ liệu, cách thức truy nhập tới các bản ghi của các tệp và những chương trình máy tính khác nhau cấu thành nên hệ thống. Mục tiêu chính của giai đoạn này là xây dựng một hệ thống hoạt đọng tốt. Những công việc chính của giai đoạn này gồm: Lập kế hoạch triển khai. Thiết kế vật lý trong. Lập trình. Thử nghiệm. Hoàn thiện hệ thống các tài liệu Đào tạo người sử dụng Các khái niệm cần chú ý trong giai đoạn này - Sự kiện (Evenement): là một việc thực thi đến nó là khởi sinh việc thực hiện cuả một hoặc nhiều xử lý nào đó. Có những sự kiện nằm ngay trong cơ chế của tổ chức hoặc nằm ngoài tổ chức. - Công việc (Operation): là một dãy xử lý có chung một sự kiện khởi sinh. - Tiến trình (Process): là một dãy các công việc mà các xử lý bên trong của nó nằm trong cùng một lĩnh vực nghiệp vụ. Nếu tiến trình quá lớn có thể chia cắt thành những file nhỏ hơn. - Nhiệm vụ: là một xử lý được xác định thêm các yếu tố về tổ chức: Ai? Ở đâu? Khi nào thực hiện nó? - Pha xử lý: Là tập hợp các nhiệm vụ có tính đến các yếu tố tổ chức và sự thực hiện chúng, không phụ thuộc vào sự kiện nào khác mà chỉ phụ thuộc vào sự kiện khởi sinh ban đầu. - Module xử lý: Là một xử lý cập nhật hoặc tra cứu bên trong của một pha và thao tác với số lượng tương đối ít dữ liệu. Đây là cách chia nhỏ các xử lý. Công việc Tiến trình 1 Tiến trình 2 Tiến trình 3 Pha 1 Pha 2 Pha 3 Mô hình tổng quát thiết kế vật lý trong đối với các xử lý Lập trình là công việc quan trọng nhất trong giai đoạn này, đây là công đoạn mà lập trình viên đưa tất cả những thiết kế từ đầu đến nay vận dụng vào chương trình và trực tiếp xây dựng chương trình. Công đoạn này đòi hỏi lập trình viên phải có một trình độ hiểu biết cao về ngôn ngữ lập trình được áp dụng cũng như các công cụ khác được sử dụng kèm theo. 2.4.7. Cài đặt, bảo trì và khai thác hệ thống Đây là giai đoạn cuối cùng trong toàn bộ quá trình xây dựng HTTT. Mục tiêu của giai đoạn này là tích hợp hệ thống được phát triển vào các hoạt động của tổ chức một cách ít va vấp nhất và đáp ứng những thay đổi có thể xảy ra trong suốt quá trình sử dụng. Hai nhiệm vụ chính của giai đoạn này là chuyển đổi về mặt kỹ thuật và chuyển đổi về mặt con người. Việc cài đặt hệ thống mới có thể kéo theo một sự thay đổi lớn đối với tổ chức. Để là giảm sự thay đổi đó ta có thể áp dụng một trong các cách cài đặt hệ thống như sau: Cài đặt trực tiếp Cài đặt song song Cài đặt thí điểm cục bộ Chuyển đổi theo giai đoạn 2.5. Giới thiệu về quản trị cơ sở dữ liệu Microsoft Access và ngôn ngữ lập trình Visual Basic 6.0 2.5.1. Hệ quản trị cơ sở dữ liệu Microsoft Access Những hệ quản trị cơ sở dữ liệu đang được dùng nhiều nhất ở nước ta và trên thế giới hiện nay là Microsoft Access, Microsoft Foxpro, Visual Foxpro và Oracle. Theo báo cáo PC World vào năm 1999 thì Microsoft Access đã giành được phần chia lớn nhất trên thị trường, vì hệ quản trị cơ sở dữ liệu Microsoft Access rất phù hợp cho những cơ sở dữ liệu của các doanh nghiệp có quy mô vừa và nhỏ. Access hoạt động trong môi trường Windows, Windows là một hệ điều hành với giao diện đồ hoạ, nghĩa là những đối tượng mà người dùng máy tính có thể chọn lựa không những có tên gọi bằng lời mà nhiều khi còn được thể hiện trên màn hình bằng những bức tranh nhỏ gọn và hình tượng. 2.5.2. Giới thiệu về Visual Basic 2.5.2.1. Lý do lựa chọn Visual Basic 6.0 Công cụ sử dụng để lập trình là hệ quản trị cơ sở dữ liệu Access 2003 và ngôn ngữ lập trình Visual Basic 6.0. Hệ quản trị cơ sở dữ liệu Microsoft Access là một trong những hệ quản trị cơ sở dữ liệu đang được dùng rất phổ biến ở Việt Nam cũng như trên thế giới. Access là một trong những bộ chương trình quan trọng nhất thuộc tổ hợp chương trình Microsoft Office Professional do hãng phần mềm Microsoft Cooperation sản xuất. Phiên bản đầu tiên của Access ra đời vào năm 1989. Từ đó đến nay, Access đã không ngừng cải tiến và đã có nhiều phiên bản. Phiên bản mới nhất là Access 2003 trong bộ Microsoft Office 2003. Một ứng dụng Access cũng được tạo nên từ các đối tượng như một CSDL, tức là gồm các bảng, query, form, report, macro…Các đối tượng của một ứng dụng được lưu trữ trong một hay nhiều CSDL. Access cung cấp một bộ công cụ Form Designer và Form Wizard tiện dùng trong thiết kế giao diện. Bộ công cụ Report Designer và Report Wizard tiện dùng trong thiết kế báo cáo của ứng dụng. Visual Basic là ngôn ngữ lập trình được tích hợp trong Microsoft Access. Visual Basic giúp cho việc xử lý dữ liệu trong Access linh hoạt hơn. - VB giúp CSDL dễ bảo trì hơn: nếu di chuyển một form hay một report từ CSDL này sang CSDL khác thì các thủ tục gắn vào form hay report cũng sẽ di chuyển theo. - Tạo các hàm: VB có thể tạo ra các hàm theo ý mình để tính một giá trị theo những công thức hay quy trình phức tạp. Sau khi đã tạo các hàm thì chỉ việc viết tên hàm trong các biểu thức chứ không phải hướng dẫn cách tính gía trị của hàm nữa - Báo lỗi hay xử lý lỗi: VB có thể giúp phát hiện của người dùng, hiện những thông báo dễ hiểu (bằng tiếng việt) và đôi khi có thể tự động sửa lỗi. - Tạo và điều khiển các đối tượng: VB cho phép điều khiển tất cả các đối tượng trong CSDL. - Xử lý từng bản ghi: có thể dùng VB để lần lượt xử lý từng bản ghi trong một tập hợp nào đó. - Truyền các tham số đến các thủ tục: VB cho phép truyền các tham số tới các thủ tục trong lúc đang thực hiện và có thể dùng các biến làm tham số. Điều này làm cho việc thực hiện các thủ tục linh hoạt hơn nhiều. Visual Basic 6.0 có rất nhiều tính năng mới. Các điều khiển mới cho phép ta viết các chương trình ứng dụng kết hợp giao diện, cách xử lý, các tính năng của Microsoft Office và trình duyệt Web Internet Explorer. Không nhất thiết phải có một ví dụ minh hoạ của điều khiển trên biểu mẫu, Visual Basic 6.0 cho phép lập trình thêm các điều khiển vào đề án tự động và có thể tạo ra các điều khiển ActiveX hiệu chỉnh. Chúng ta cũng có thể viết các ứng dụng phía máy chủ dùng HTML động nhúng kết với các thư viện liên kết động của Internet Information Server. Các cải tiến cho phép làm việc với các ứng dụng truy cập dữ liệu ở tầm cỡ vĩ mô liên quan đến hàng trăm, hàng nghìn người sử dụng qua mạng hay qua Internet. Visual Basic 6.0 giúp việc tạo các lớp và điều khiển ActiveX phong phú hơn. Có thể lưu dữ liệu của các lớp tự tạo từ session này sang session khác thông qua túi thuộc tính (Property Bag). Các kiểu dữ liệu này hoạt động tương tự như các đối tượng dữ liệu ADO, nhưng chúng đáp ứng yêu cầu khách hàng nhiều hơn. CHƯƠNG III: PHÂN TÍCH VÀ THIẾT KẾ CHƯƠNG TRÌNH QUẢN LÝ HỢP ĐỒNG BẢO HIỂM 3.1. Tìm hiểu chung về nghiệp vụ và sản phẩm bảo hiểm 3.1.1. Quy trình khai thác hợp đồng bảo hiểm của nghiệp vụ viên (Cán bộ khai thác) Nội dung các bước khai thác a> Tiếp thị, nhận YCBH từ khách hàng Cán bộ khai thác có nhiệm vụ thường xuyên tiếp xúc với khách hàng, gửi hoặc trao đổi các thông tin về các sản phẩm của BHDK nhằm giới thiệu các nghiệp vụ bảo hiểm và đáp ứng nhu cầu của khách hàng. Kịp thời nắm bắt những thay đổi và biến động trong hoạt động kinh doanh của khách hàng để tư vấn, giới thiệu sản phẩm bảo hiểm hoặc có thay đổi phù hợp. Cán bộ khai thác chủ động khai thác nguồn tin từ khách hàng (hoặc qua các cơ quan quản lý, đại lý, cộng tác viên, môi giới, cơ quan thông tin đại chúng) thông báo các vấn đề liên quan đến tài sản, hàng hoá cần được bảo hiểm. Xử lý ban đầu khi cán bộ khai thác nhận được thông tin từ khách hàng: Tìm hiểu thêm các thông tin về nguồn vốn, khả năng tài chính, khả năng tham gia bảo hiểm của khách hàng… và có trách nhiệm hướng dẫn khách hàng khai chi tiết các thông tin cần thiết theo đúng mẫu: Bản câu hỏi đánh gía rủi ro. BHDK sẽ cung cấp Giấy yêu cầu bảo hiểm, bản câu hỏi đánh giá ruủi ro và các tài liệu khác theo yêu cầu của khách hàng. Khuyến cáo với khách hàng: Hợp đồng bảo hiểm sẽ không có gía trị nếu khách hàng cung cấp hoặc kê khai sai hoặc không khai báo những chi tiết quan trọng có liên quan đến tài sản, hàng hoá yêu cầu bảo hiểm.  b> Đánh giá rủi ro Thông qua các số liệu thống kê và thực tiễn hoạt động của khách hàng, cán bộ khai thác tham mưu cho lãnh đạo về chính sách khách hàng, về công tác quản lý rủi ro và khả năng triển khai dịch vụ. Kết hợp với bộ phận bồi thường để tính được hiệu quả bảo hiểm đối với từng khách hàng, theo từng năm nghiệp kịp thời, đề xuất ý kiến điều chỉnh tỷ lệ phí và các điều kiện, điều khoản bảo hiểm cho thích hợp. Căn cứ vào thông tin được cung cấp, cán bộ khai thác tự khai thác tự đánh giá rủi roc ho khách hàng. Sử dụng bản đánh giá rủi ro theo mẫu. Cán bộ khai thác hoặc giám định viên đánh giá rủi ro trên cơ sở tiếp xúc trực tiếp với đối tượng bảo hiểm và các thông tin được cung cấp. Những trường hợp đặc biệt (yêu cầu kĩ thuật chuyên môn cao, khả năng rủi ro cao, giá trị bảo hiểm lớn) cần có giám định viên đánh rủi ro của cơ quan chuyên môn khác hoặc của cơ quan chuyên môn khác hoặc tổ chức giám định nước ngoài. c> Tiến hành đàm phán, chào phí Xử lý trong phân cấp Trên cơ sở các thông tin khách hàng cung cấp, báo cáo đánh giá ruủi ro, các số liệu thống kê và các chính sách khách hàng của Công ty, P.KD/CN/VPĐD xác định tỷ lệ phí bảo hiểm phù hợp với đối tượng bảo hiểm và các quy định của Công ty. Xử lý trên phân cấp Trường hợp dịch vụ lớn, vượt quá trách nhiệm được phân cấp theo nghiệp vụ đối với CN/VPĐD, CN/VPĐD phải có công văn thông báo về trụ sở chính của Công ty xin ý kiến chỉ đạo. Nội dung của Công văn do lãnh đạo chi nhánh kí gồm những điểm chính về: số liệu khách hàng, ý kiến phân tích, đề xuất hướng giải quyết nhằm đáp ứng không chỉ nhu cầu của khách hàng mà còn đảm bảo hoạt động kinh doanh có hiệu quả của Công ty. Phòng KD/CN chuyển hò sơ khai thác và công văn với nội dung trên về phòng NVKD của Công ty để xem xét và quyết định phí, điều kiện bảo hiểm. Trong trường hợp này, các bước sẽ được tiến hành theo trình tự (I), (II), (III) sơ đồ hướng dẫn khai thác. Một số trường hợp cần phải mời thầu để thu xếp được phí, việc lập hồ sơ mời thầu, xét thầu, lập hồ sơ tham dự thầu tuan thủ theo Quy trình lập hồ sơ mời thầu và xét thầu và quy trình lập hồ sơ tham dự thầu. Phí bảo hiểm và điều kiện bảo hiểm đã chào cho khách hàng nhưng chưa được chấp nhận, tuỳ từng trường hợp, lãnh đạo P.KD/CN hoặc lãnh đạo Công ty sẽ có cuộc gặp gỡ để trao đổi và tính toán lại phương án chào phí.Trong quá trình đàm phán, các yếu tố liên quan tới những quy tắc bảo hiểm, điều kiện, điều khoản, phí bảo hiểm, hồ sơ số lliệu về khách hàng, chính sách khách hàng và phí của các nhà tái bảo hiểm hàng đầu sẽ được lãnh đạo Công ty xem xét để giải quyết định mức phí phù hợp, đáp ứng được nhu cầu bảo hiểm của khách hàng và chính sách phát triển kinh doanh của Công ty. d> Chuẩn bị Đơn/ Hợp đồng/ GCN bảo hiểm (nếu có) Sau khi nhận được thông báo đồng ý tham gia bảo hiểm của khách hàng, CB khai thác chuẩn bị Đơn/ Hợp đồng/ GCN bảo hiểm. Lấy số Đơn/ Hợp đồng/ GCN bảo hiểm Trước khi cấp Đơn/ Hợp đồng/ GCN bảo hiểm, phải tiến hành lấy số Đơn/ Hợp đồng/ GCN bảo hiểm theo quy định Mã đơn bảo hiểm QĐ.03. Số Đơn/ Hợp đồng/ GCN bảo hiểm phải được ghi vào sổ cập nhật chi tiết bảo hiểm của Công ty/ CN/ VPĐD.  Cấp Đơn/ Hợp đồng/ GCN bảo hiểm Tiến hành cấp Đơn/ Hợp đồng/ GCN bảo hiểm dựa trên những thông tin đã được cung cấp, áp dụng chung cho nghiệp vụ như sau: Kiểm tra các thông tin, chứng từ, GYC bảo hiểm, phê duyệt của lãnh đạo Công ty (nếu có). Cấp Đơn/ Hợp đồng/ GCN bảo hiểm theo mẫu Tính phí bảo hiểm, thông báo thu phí, sửa đổi bổ sung và/hoặc huỷ đơn bảo hiểm. Chú ý khi cấp Đơn theo Hợp đồng bảo hiểm bao/Hợp đồng bảo hiểm nguyên tắc: Phí của Hợp đồng bao/ Hợp đồng nguyên tắc có thể xem xét giảm so với đơn bảo hiểm cấp lẻ, do rủi ro được phân tán tốt hơn. Hợp đồng bao/ Hợp đồng nguyên tắc được lấy số và theo dõi riêng. Sauk hi dự thảo hợp đồng cần lấy ý kiến khách hàng trước khi trình lãnh đạo ký. Nếu không có yêu cầu gì đặc biệt, Hợp đồng bao/ Hợp đồng nguyên tắc được lập thành 4 bản có giá trị pháp lý như nhau. Sau khi ký kết, Hợp đồng bao/ Hợp đồng nguyên tắc được phát hành và có hiệu lực. Trên cơ sở hiệu lực của hợp đồng này, từng chuyến hàng sẽ được cấp Đơn bảo hiểm/ GCN bảo hiểm theo thông báo hoặc yêu cầu của khách hàng. e> Ký duyệt Đơn/ Hợp đồng / GCN bảo hiểm Trình lãnh đạo P.KD/CN ký Đơn /Hợp đồng / GCN bảo hiểm. Đối với các trường hợp dịch vụ bảo hiểm trên phân cấp, BGĐ ký đơn, P.KD/CN phải chuyển dự thảo Đơn/ Hợp đồng đến P. NVKD và/hoặc P.KH, P. TBH, KT có ý kiến trước khi BGĐ ký. f> Đóng dấu, chuyển Đơn/ Hợp đồng/ GCN bảo hiểm, lưu hồ sơ Đơn /Hợp đồng / GCN bảo hiểm được văn thư đóng dấu chuyển cho khách hàng. Lưu tại P.KD/ CN/ VPĐD 01 bản gốc: Đơn /Hợp đồng / GCN bảo hiểm và các tài liệu có liên quan phải được đính kèm nhau và được lưu trong các cặp tài liệu theo thứ tự thời gian và theo năm nghiệp vụ. Đơn /Hợp đồng / GCN bảo hiểm được luân chuyển như sau: Chuyển 01 bản copy cho P.TC-KT/bộ phận KT để theo dõi việc thanh toán phí bảo hiểm, thanh toán hoa hồng bảo hiểm và làm cơ sở xét giải quyết bồi thường nếu có phát sinh, 01 bản copy cho phòng kế hoạch/ bộ phận thống kê để phục vụ cho công tác báo cáo thống kê nghiệp vụ, công tác tính toán hiệu quả kinh tế và phương án giữ lại. 01 bản copy cho phòng TBH để thu xếp tái bảo hiểm, 01 bản copy cho phòng NVKD để phục vụ công tác quản lý. Chuyển cho khách hàng 02 bản gốc. g> Quản lý Đơn /Hợp đồng / GCN bảo hiểm Lưu sổ thống kê: Đơn /Hợp đồng / GCN bảo hiểm phải được vào sổ thống kê cửa Phòng KD/CN và sổ thống kê của Công ty. Theo dõi việc thu phí, thanh toán hoa hồng: thời hạn thu phí bảo hiểm được quy định trong hợp đồng bảo hiểm/ thông báo thu phí bảo hiểm. Nếu CB khai thác thu phí bằng tiền mặt thì phải nộp tiền vào quỹ trong vòng 24h sau khi thu. Hết thời hạn thoả thuận mà khách hàng vẫn chưa nộp phí bảo hiểm thì cần đôn đốc khách hàng nộp phí (qua điện thoại, fax, điện tín, công văn). Qúa thời hạn thu phí bảo hiểm 01 tháng mà khách hàng vẫn chưa nộp, cần báo cáo lãnh đạo Công ty, Phòng/ bộ phận TCKT để có biện pháp giải quyết. Giải quyết các yêu cầu phát sinh của khách hàng liên quan đến đơn/ quy tắc/ điều kiện/ điều khoản bảo hiểm đã cấp: trong quá trình thực hiện hợp đồng nếu có bất cứ thay đổi nào từ phía Công ty hoặc khách hàng thì cán bộ khai thác có trách nhiệm trao đổi với khách hàng, lập thành văn bản nội dung thay đổi, báo cáo lãnh đạo và thông báo tới các bộ phận liên quan. Các thay đổi có ảnh hưởng đến rủi ro được bảo hiểm cần trao đổi với phòng TBH trước khi chấp nhận bảo hiểm, nếu cần sẽ phải tính thêm phí. Bản sửa đổi bổ xung cho các thay đổi này được lưu cùng các tài liệu đã có. Theo dõi tái tục. Đối với các dự án lớn Công ty quản lý, khi kết thúc thời hạn bảo hiểm phải có báo cáo tổng kết về các dịch vụ bảo hiểm. 3.1.2. Mô tả thuộc tính, đối tượng các dịch vụ của BHDKVN (gọi chung là Công ty) 3.1.2.1. Mô tả Hợp đồng bảo hiểm và dịch vụ bảo hiểm của BHDKVN Một hợp đồng bảo hiểm của Công ty chỉ chứa một loại hình dịch vụ bảo hiểm. Dịch vụ của Công ty được mô tả theo các thuộc tính sau: Loại hình dịch vụ: Bảo hiểm hàng hoá, bảo hiểm tàu, bảo hiểm xe cơ giói… Mã hiệu dịch vụ:… Thời hạn bảo hiểm: 1chuyến (vài ngày đến 01 tháng), 01 năm… Số tiền bảo hiểm: là mức trách nhiệm mà khách hàng muốn bảo hiểm cho sản phẩm (dịch vụ) của mình. Phí bảo hiểm:là khoản tiền mà khách hàng phải đóng theo một thời hạn nhất định phụ thuộc vào tỷ lệ phí. Thời hạn đóng phí: + Đóng một lần duy nhất + Đóng theo chu kì: tháng, quý… Phương thức đóng phí: + Tiền mặt + Chuyển khoản Tỷ lệ phí phụ thuộc vào: + Loại dịch vụ mà khách hàng yêu cầu bảo hiểm. + Tỷ lệ phí mà khách hàng chấp nhận được. + Bảo hiểm lần đầu hay tái bảo hiểm. Tổ chức (khách hàng) tham gia đóng bảo hiểm. Thanh toán bảo hiểm: Chỉ thanh toán khi có sự kiện bảo hiểm xảy ra. 3.1.2.2. Mô tả biểu phí Biểu phí của BHDKVN được mô tả theo các thuộc tính dưới đây Loại hình bảo hiểm: Bảo hiểm hàng hoá, bảo hiểm xe, bảo hiểm tàu… Tần xuất đóng bảo hiểm: Một lần hay định kỳ Theo thời gian bảo hiểm: + Đến 03 tháng: 30% phí cả năm + Trên 03 tháng đến 06 tháng: 60% phí cả năm + Trên 06 tháng đến 09 tháng: 90% phí cả năm + Trên 09 tháng: 100% phí cả năm Tỷ lệ phí = phí * % tỷ lệ 1.3.2.3. Tỷ lệ hoa hồng chi trả trực tiếp cho cán bộ khai thác Loại nghiệp vụ bảo hiểm Mức chi phí tối đa được hưởng 1. Bảo hiểm con người, thiệt hai KD, BH TNDS chủ xe máy 5% 2. Bảo hiểm tài sản và thiệt hại, BHXDLĐ, BH xe cơ giới, BH cháy nổ, BH tín dụng và rủi ro tài chính, BH trách nhiệm chung 11% 3. Các loại BH khác còn lại 14% Tỷ lệ này do công ty quy định, mục đích của bảng tỷ lệ này là dùng để tính hoa hồng cho các cán bộ khai thác dựa vào Hợp đồng bảo hiểm mà họ đang theo dõi. Mỗi hợp đồng bảo hiểm mà cán bộ khai thác theo dõi khi đến kỳ thu phí thì cán bộ sẽ thu phí của hợp đồng. Sau đó dựa vào số phí đã thu đó để tính hoa hồng của hợp đồng đó theo công thức; Số hoa hồng = Số phí * Tỷ lệ hoa hồng Đặc điểm của bảng tỷ lệ hoa hồng chi trả trực tiếp phụ thuộc vào: Loại ngghiệp vụ bảo hiểm Tần suất đóng bảo hiểm Năm hợp đồng thứ mấy 3.2. Xây dựng hệ thống quản lý hợp đồng bảo hiểm tại chi nhánh BHDK-KV Tây Bắc 3.2.1. Khảo sát và phân tích 3.2.1.1. Thực trạng và các vấn đề xem xét Qua nghiên cứu nghiệp vụ, hợp đồng bảo hiểm chứa rất nhiều thuộc tính về sản phẩm bảo hiểm và khách hàng. Việc quản lý các dữ liệu của hợp đồng là rất phức tạp. Từ trước đến nay việc quản lý hợp đồng bảo hiểm tại chi nhánh BHDK-KV Tây Bắc được tiến hành một cách thủ công ở tất cả các khâu, do vậy còn tồn tại rất nhiều vấn đề, đó là: Do việc lưu trữ hợp đồng một cách thủ công nên không có cách nào nhanh chóng để lọc được các hợp đồng đến ngày thu phí. Việc quản lý tình hình hợp đồng đến ngày đáo hạn cũng rất khó khăn. Việc tính hoa hồng, tính phí được diễn thủ công nên tốn nhiều thời gian. Đồng thời đến cuối tháng muốn lập báo cáo tổng hợp về số hoa hồng, số phí đã tính trong tháng thì phải mất thời gian tập hợp số liệu của các cán bộ riêng lẻ. Việc quản lý thủ công thì gây khó khăn trong việc lọc các hợp đồng cần thu phí để có kế hoạch thu phí phù hợp. Quản lý thông tin về các khách hàng tham gia bảo hiểm cũng rất khó khăn. Do vậy không có biện pháp nào để chăm sóc khách hàng kịp thời. Đồng thời có thể dựa vào khách hàng để tìm kiếm thêm các hợp đồng bảo hiểm khác. Thông tin mới nhất về các dịch vụ (sản phẩm) của BHDK được cập nhật chậm. Lý do là việc cung cấp thông tin giữa BHDK với các đại lý chỉ được thực hiện bằng văn bản. Các báo cáo của chi nhánh gửi về tổng công ty rất chậm. Hơn nữa tại tổng công ty không biết được tình hình khai thác hợp đồng tại các chi nhánh ra sao. Thông tin cụ thể về các hợp đồng của các chi nhánh cũng không biết. Do vậy ảnh hưởng đến các quyết định kịp thời nhằm phát triển hệ thống quản lý hợp đồng . 3.2.1.2. Những yêu cầu đặt ra cho bài toán quản lý hợp đồng Để có thể quản lý chặt chẽ các Hợp đồng bảo hiểm tại chi nhánh BHKD-KV Tây Bắc cũng như các đại lý trung gian, yêu cầu đặt ra đối với phần mềm tương lai phải có tối thiểu những chức năng sau: Có đủ các tiêu chí liên quan đến tình hình hợp đồng như: Mã khách hàng, tên khách hàng, địa chỉ, điện thoại, mã cán bộ khai thác, loại hợp đồng, định kì nộp phí, phí bảo hiểm, hoa hồng cho từng hợp đồng. Thể hiện được danh sách hợp đồng theo ngày/tháng, theo loại sản phẩm, theo từng cán bộ khai thác. Khi cần có thể chiết xuất thông tin theo yêu cầu từ cơ sở dữ liệu có sẵn. Số liệu ở các bảng có thể kết hợp với nhau. Ví dụ khi đang ở form hợp đồng, ta có thể nhấp dúp vào trường khách ở trên text box để biết thông tin chi tiết về khách hàng: Mã khách hàng, tên khách hàng, địa chỉ, điện thoại, mã số thuế… Có thể cập nhật thông tin hàng tháng về tình hình hoa hồng, và doanh thu phí. Trong bảng thống kê chi tiết về hợp đồng có thể cộng tổng theo cán bộ khai thác, theo loại hợp đồng, theo định kỳ đóng phí… 3.2.2. Phân tích hệ thống quản lý hợp đồng Bảo hiểm tại BHDK-chi nhánh KV Tây Bắc 3.2.2.1. Sơ đồ luồng thông tin IFD (Information Flow Diagram) hệ thống thông tin quản lý hợp đồng bảo hiểm Sơ đồ luồng thông tin dùng để mô tả hệ thống thông tin theo cách thức động, tức là mô tả sự di chuyển của dữ liệu, việc xử lý, việc lưu trữ bằng các sơ đồ. Các ký pháp của sơ đồ luồng thông tin như sau: Tin học hoá hoàn toàn Giao tác người - máy Thủ công Xử lý Kho lưu trữ dữ liệu Tin học hoá Thủ công - Dòng thông tin Hình 3.1. Sơ đồ luồng thông tin hệ thống thông tin quản lý HĐ bảo hiểm 3.2.2.2. Sơ đồ luồng dữ liệu DFD (Data Flow Diagram) hệ thống thông tin quản lý hợp đồng Sơ đồ luồng dữ liệu dùng để mô tả hệ thống thông tin như sơ đồ luồng thông tin nhưng trên góc độ trừu tượng. Trên sơ đồ chỉ bao gồm các luồng dữ liệu, các xử lý, các lưu trữ dữ liệu, nguồn và đích nhưng không hề phản ánh thời điểm và đối tượng chịu trách nhiệm xử lý. Sơ đồ luồng dữ liệu chỉ mô tả đơn thuần hệ thống thông tin làm gì và để làm gì. Ký pháp dùng cho sơ đồ luồng dữ liệu: Ngôn ngữ sơ đồ luồng dữ liệu DFD sử dụng 4 loại ký pháp cơ bản: thực thể, tiến trình, kho dữ liệu và dòng dữ liệu. Tên người/bộ phận phát nhận thông tin Các kí pháp dùng cho DFD Nguồn hoặc đích Tên dòng dữ liệu - Dòng dữ liệu Tên tiến trình xử lý - Tiến trình xử lý Tệp dữ liệu - Kho dữ liệu Thiết kế các sơ đồ luồng dữ liệu hệ thống thông tin quản lý HĐ BH Hình 3.2. Sơ đồ ngữ cảnh hệ thống thông tin quản lý hợp đồng bảo hiểm Hình 3.3. Sơ đồ DFD mức 0 hệ thống thông tin quản lý hợp đồng bảo hiểm 3.2.3. Thiết kế cơ sở dữ liệu trên Microsoft Access 2003 3.2.3.1. Bảng CanBo Bảng cán bộ chứa thông tin của các cán bộ khai thác. Các cán bộ này thể hiện đang làm khai thác hoặc đã nghỉ. STT FIELD NAME DATA TYPE FIELD SIZE DESCRIPTION 1 MaCanBo Text 10 Mã cán bộ 2 TenCanBo Text 50 Mã cán bộ 3 ChucVu Text 50 Chức vụ 4 NgaySinh Date/Time Short Date Ngày sinh 5 GioiTinh Text 50 Giới tính 6 DiaChiThuongTru Memo Địa chỉ thường trú 7 NgayVaoLam Date/Time Short Date Ngày vào làm 8 NgayNghi Date/Time Short Date Ngày nghỉ 9 SoDienThoai Text 50 Số điện thoại 10 MaCBQL Text 10 Mã cán bộ quản lý 11 MatKhau Text 50 Mật khẩu Trường MaCanBo là khoá chính của bảng. Bảng này dùng để quản lý cán bộ. Mỗi cán bộ sẽ có một người quản lý (thể hiện ở trường MaCBQL). 3.2.3.3. Bảng HoaHong STT FIELD NAME DATA TYPE FIELD SIZE DESCRIPTION 1 MaHopDong Text 50 Mã hợp đồng 2 MaHoaHong AutoNumber Long Integer Mã hoa hồng 3 MaCanBo Text 50 Mã cán bộ 4 PhuongThuc Text 50 Phương thức 5 ThoiHanBD Date/Time Short Date Thời hạn bắt đầu 6 ThoiHanKT Date/Time Short Date Thời hạn kết thúc 7 TyLeHH Number Single Tỷ lệ hoa hồng 8 MaDichVu Text 50 Mã dịch vụ Bảng này lưu thông tin tỷ lệ hoa hồng của các dịch vụ bảo hiểm . Nó là bảng cố định, được nhập độc lập với hợp đồng. Trường MaHoaHong là khoá chính của bảng, nó tự động cập nhật. Trường MaDichVu là khoá ngoại lai dùng để tham chiếu đến bảng DichVu. Dựa vào hai trường ThoiHanBD và ThoiHanKT để ta theo dõi hợp đồng nào đang được triển khai và hợp đồng nào đã kết thúc. 3.2.3.2. Bảng DichVu Bảng này chứa thông tin về mã, tên các dịch vụ (sản phẩm) bảo hiểm dùng trong các hợp đồng bảo hiểm. Trong đó trường MaDichVu là khóa chính. STT FIELD NAME DATA TYPE FIELD SIZE DESCRIPTION 1 MaDichVu Text 10 Mã dịch vụ 2 TenDichVu Text 50 Tên dịch vụ 3 GhiChu Text 50 Ghi chú 3.2.3.4. Bảng HopDong Bảng này lưu thông tin về các hợp đồng. Dữ liệu của bảng được lấy từ các bảng danh mục và từ hợp đông bảo hiểm.Bảng này chỉ lưu thông tin chung về hợp đồng và dịch vụ bảo hiểm của hợp đồng. STT FIELD NAME DATA TYPE FIELD SIZE DESCRIPTION 1 MaDichVu Text 10 Mã dịch vụ 2 MaHopDong Text 50 Mã hợp đồng 3 MaKhachHang Text 50 Mã khách hàng 4 GiaTriBH Number Long Integer Giá trị bảo hiểm 5 TylePhiBH Number Long Integer Tỷ lệ phí bảo hiểm 6 ThoiHanBH Number Long Integer Thời hạn bảo hiểm 7 DinhKy Text 50 Định kỳ 8 HinhThucTT Text 50 Hình thức thanh toán 9 HinhThucBT Text 50 Hình thức bồi thường 10 NgayPhatHanh Date/Time Short Date Ngày phát hành 11 NgayHieuLuc Date/Time Short Date Ngày hiệu lực 12 NgayDaoHan Date/Time Short Date Ngày đáo hạn 13 NgayHuy Date/Time Short Date Ngày huỷ 14 ThuPhi Yes/No True/False Thu phí 15 MaCB Text 10 Mã cán bộ Bảng này có khoá chính là trường MaHopDong. Trong bảng hợp đồng có trường ThuPhi để xác định xem hợp đồng này còn bao nhiêu tiền mà khách hàng còn nợ (có thể là chưa thu hoặc đã thu nhưng chưa thu hết). Trường MaDichVu là khoá ngoại lai dùng để truy xuất đến bảng DichVu để lâý dịch vụ bảo hiểm cho hợp đồng. Mỗi hợp đồng chỉ chứa một loại hình dịch vụ. 3.2.3.5. Bảng KhachHang Bảng khách hàng chứa các thông tin của khách hàng đã từng hoặc đang tham gia bảo hiểm. Thông tin của khách hàng được lấy từ giấy yêu cầu bảo hiểm hoặc từ hợp đồng bảo hiểm. Trường MaKhachHang là khoá chính của bảng này. STT FIELD NAME DATA TYPE FIELD SIZE DESCRIPTION 1 MaKhachHang Text 10 Mã khách hàng 2 TenKhachHang Text 50 Tên khách hàng 3 TenCBDaiDien Text 25 Tên cán bộ đại diện 4 ChucVu Text 20 Chức vụ 5 DiaChi Text 50 Địa chỉ 6 DienThoai Text 12 Điện thoại 7 Fax Text 10 Fax 8 MaSoThue Text 30 Mã số thuế 9 TaiKhoan Text 50 Tài khoản 3.2.3.7. Bảng ThuPhi Bảng này lưu lại thông tin về các lần thu phí của hợp đồng. Bảng này lấy trường SoBienLai làm khoá chính. Trường MaHopDong là khoá ngoại lai dùng để truy xuất đến bảng HopDong. Một hợp đồng sẽ được thu phí một hoặc nhiều lần theo định kì thu phí. Do vậy bảng này sẽ chứa các lần thu phí hoặc chỉ chứa thu phí lần đầu đối với hợp đồng thu phí một lần. STT FIELD NAME DATA TYPE FIELD SIZE DESCRIPTION 1 SoBienLai Text 50 Số biên lai 2 MaHopDong Text 50 Mã hợp đồng 3 NgayThu Date/Time Short Date Ngày thu 4 CachThuc Text 50 Cách thức 5 SoTien Currency General Number Số tiền 3.2.3.8. Bảng DieuKhoan Bảng này chứa thông tin về các điều khoản đi kèm theo hợp đồng. Mỗi loại hợp đồng có một số điều khoan di kèm. STT FIELD NAME DATA TYPE FIELD SIZE DESCRIPTION 1 MaDieuKhoan Text 50 Mã điều khoản 2 MaHopDong Text 50 Mã hợp đồng 3 TenDieuKhoan Text 50 Tên điều khoản 4 NoiDung Text 50 Nội dung Trường MaDieuKhoan là khoá chính. Nó được dùng để lập hợp đồng. MaHopDong là khoá ngoại lai dùng để truy xuất đến bảng HopDong. SƠ ĐỒ MỐI QUAN HỆ GIỮA CÁC BẢNG 3.2.4. Thiết kế giao diện * Một số form giao diện chính của chương trình Danh sách cán bộ Form điều khoản hợp đồng Form hoa hồng Danh mục hợp đồng Cập nhật khách hàng * Một số báo cáo MỤC LỤC