(Tiểu luận) đề tài xây dựng hệ thống quản lý tiền mặt của ngân hàng vib

Ở dự án này nhóm thực hiện xử lý, phát triển hệ thống quản lý tiền mặt bao gồm dòng tiền mặt giữ ở các phòng giao dịch, chi nhánh, hội sở; điều chuyển quỹ giữa Vault – Teller/Teller - Te

TỔNG QUAN DỰ ÁN

Gi i thi ớ ệu dự án

Dự án là dự án con của dự án “Quản lý quỹ tiền mặt của ngân hàng VIB” Được bàn giao nhóm MATH chịu trách nhiệm triển khai

Dự án là một module quản lý tiền mặt được triển khai và tích hợp vào hệ thống core của ngân hàng VIB (Core Extra) Hệ thống ghi nhận các biến động tiền mặt trong ngày, bao gồm việc quản lý dòng tiền tại các phòng giao dịch, chi nhánh và hội sở Nhóm thực hiện dự án sẽ xử lý và phát triển các chức năng như điều chuyển quỹ giữa Vault và Teller, giữa các Teller, cũng như giữa kho và ngoài kho (Vault-Safe) Ngoài ra, dự án còn bao gồm việc nộp và rút tiền từ các tổ chức tín dụng khác, cân tiền trong ngày và hạch toán thừa thiếu quỹ của Teller và Vault.

Mục tiêu của dự án là đảm bảo tiến độ và hoàn thành đúng thời hạn Mỗi giai đoạn cần được thực hiện với chất lượng cao để không ảnh hưởng đến các giai đoạn khác Nhóm sẽ chia nhỏ từng giai đoạn để quản lý rủi ro hiệu quả, nhằm giảm thiểu gián đoạn Cuối cùng, dự án cần hoàn thành trong phạm vi kinh phí dự toán hoặc có thể chấp nhận được nếu có vượt quá.

Hệ thống được thiết kế với giao diện thân thiện, đảm bảo các chức năng đáp ứng yêu cầu và phù hợp trong quá trình sử dụng Ngoài ra, hệ thống cũng dễ dàng tích hợp với core system hiện có của VIB.

Hiểu rõ đặc điểm và năng lực của từng thành viên trong đội ngũ để phân công công việc hợp lý Tạo dựng một môi trường làm việc gắn kết và khuyến khích sự chia sẻ giữa các thành viên.

Dự đoán và đánh giá chính xác các rủi ro tiềm ẩn trong dự án là rất quan trọng Việc đưa ra các giải pháp hiệu quả để khắc phục, giải quyết và ngăn chặn những rủi ro này sẽ giúp quá trình thực hiện và vận hành dự án sau khi xây dựng diễn ra thuận lợi hơn.

Ph m vi d ạ ự án

Nhóm dự án xác định yêu cầu bên phía VIB gồm yêu cầu nghiệp vụ và yêu cầu về kỹ thuật

Yêu cầu nghiệp vụ bao gồm yêu cầu chức năng và yêu cầu phi chức năng

Yêu cầu kỹ thuật bao gồm: yêu cầu về kiến trúc hệ thống, quản lý phiên, xử lý thông báo lỗi, bảo mật, nền tảng

Tích hợp với hệ thống quản trị user sẵn có: theo vùng, chi nhánh, phòng ban chức năng, module, role, menu, function thông qua API theo chuẩn Rest

Phân quyền mức ứng dụng cho phép hệ thống quản lý quyền truy cập của người dùng hoặc nhóm người dùng đến các chức năng cụ thể, bao gồm màn hình, tab và các tính năng riêng biệt Điều này giúp đảm bảo rằng người dùng chỉ có thể truy cập vào những phần mềm và chức năng mà họ được phép, nâng cao tính bảo mật và hiệu quả trong quản lý hệ thống.

View, Edit, Transaction, Verify ) và phân quyền dữ liệu theo cây phân cấp tổ chức

Limit management: cho phép cài đặt hạn mức theo Branch, Ccy, DR/CR

Teller thực hiện giao dịch theo thứ tự ưu tiên khi cài đặt limit

Cảnh báo vượt hạn mức tồn quỹ cuối ngày của chi nhánh

Hệ thống cho phép quản lý hạn mức:

- Hạn mức tiền mặt tồn quỹ theo chi nhánh/PGD/Teller theo từng loại tiền

- Hạn mức giao dịch cho từng loại giao dịch (theo trancode) theo User

Branch cash transfer : có mapping của 2 bút toán tiếp quỹ nhận quỹ tại 2 chi - nhánh thực hiện giao dịch

Có list bút toán nhận quỹ chưa xử lý cần accept/reject tại chi nhánh được tiếp quỹ

- Khi điều chuyển quỹ liên chi nhánh:

+ Chi nhánh điều chuyển thực hiện giao dịch, hệ thống đẩy bút toán vào CBS, CBS trả về số Ref

Hệ thống cập nhật số Ref (tiếp quỹ) vào giao dịch

Chi nhánh nhận quỹ thực hiện giao dịch và gửi thông tin vào hệ thống CBS Hệ thống CBS sẽ trả về số tham chiếu (ref) cho giao dịch đó Số tham chiếu nhận quỹ sẽ được ghi nhận vào giao dịch tương ứng.

Các giao dịch tiếp quỹ và nhận quỹ được thiết lập dựa trên một bản ghi chứa thông tin quan trọng như Mã GD, Chi nhánh tiếp quỹ, Chi nhánh nhận quỹ, Tổng tiền, Bút toán xuất quỹ và Bút toán nhận quỹ Những giao dịch này có các trạng thái rõ ràng, giúp quản lý và theo dõi hiệu quả quá trình chuyển tiền.

1 INP: Sau khi Vault nhập giao dịch

2 APP.SUSS: Sau khi Supervisor phê duyệt và Core trả về kết quả thành công

3 APP.FAIL: Sau khi Supervisor phê duyệt và Core trả về kết quả không thành không hoặc timeout

4 ACC.SUSS: Sau khi đơn vị nhận quỹ accept giao dịch, hach toán vào Core thành công

5 ACC.FAIL: Sau khi đơn vị nhận quỹ accept giao dịch, hach toán vào Core không thành công hoặc timeout

6 REJ: Sau khi đơn vị nhận quỹ

4 reject giao dịch (do sai số tiền

Hệ thống có chức năng liệt kê các giao dịch tiếp quỹ chờ accept/reject (là các giao dịch có trạng thái APP.SUSS)

Màn hình hạch toán nộp, rút tiền với tổ chức tín dụng khác

Hệ thống có chức năng Nộp/Rút tiền với các tổ chức tín dụng khác với các thông tin mà VIB yêu cầu

Teller cash transfer: chuyển/nhận tiền giữa các Teller/Teller , Teller/Vault

Hệ thống cho phép Teller thực hiện giao dịch tiếp quỹ và hoàn quỹ với Teller và Vault Sau khi nhập giao dịch, cần có sự kiểm soát và phê duyệt để xác nhận Đối với các giao dịch giữa các Teller, hệ thống cho phép khai báo hạn mức điều chuyển không cần phê duyệt của supervisor, giúp Teller có thể chủ động phê duyệt giao dịch cho các số tiền nhỏ.

Teller overage / shortage : Kê thừa thiếu quỹ cuối ngày

Cuối ngày, nhân viên giao dịch và kho quỹ sẽ nhập chi tiết số lượng và mệnh giá từng loại tiền Hệ thống sẽ tự động so sánh với số tiền đã được ghi nhận và xuất ra bảng kê thể hiện tình trạng thừa hoặc thiếu theo từng loại tiền.

Teller denom balancing: Cân tiền thực tế trong ngày,cuối ngày

Hệ thống kiểm soát cân tiền cho Teller/Vault/Safe cho phép người dùng nhập chi tiết số lượng tờ theo mệnh giá Hệ thống sẽ so sánh với số tiền đã được ghi nhận và thông báo số chênh lệch theo từng loại tiền.

Các giao dịch bị từ chối sẽ được được Hệ thống cho phép người nhập giao dịch điều chỉnh các giao dịch của

5 phép chỉnh sửa để process tiếp họ bị từ chối

Hệ thống cho phép Retry khi duyệt GD lỗi: chưa được xử lý tại CBS hoặc chưa được cập nhật trạng thái trên hệ thống khởi tạo

Hệ thống cho phép khai báo tham số: Số lần Retry/Tần suất Retry đối với các chức năng phê duyệt

1.2 Yêu cầu phi chức năng

1.2.1 Khả năng sẵn sàng của hệ thống

Khả năng sẵn sàng của hệ thống: 24/7 Hệ thống có khả năng giao dịch

Thời gian thực hiện GD:

Hệ thống đảm bảo thời gian thực hiện giao dịch (không tính thời gian phản hồi từ các hệ thống tích hợp):

Thời gian trích xuất dữ liệu:

- Thời gian sinh báo báo ngày không quá

- Thời gian sinh báo cáo tháng không quá

1.2.2 Ngôn ngữ hỗ trợ: Anh/Việt Đáp ứng

1.2.3 Lưu trữ dữ liệu: lưu trữ trong vòng 20 năm Đáp ứng

Giao diện người dùng: Giao diện bố cục hợp lý, khoa học, thân thiện, màu sắc theo chuẩn VIB Đáp ứng

1.2.5 Đào tạo và bàn giao

Cung cấp các tài liệu liên quan sau khi triển khai (TCP, BRD, SRS, user manual, test case, data dictionary, detail design

….) Các tài liệu phân tích thiết kế, tài liệu kỹ thuật phải hoàn toàn tương đồng với hiện trạng của ứng dụng khi đã golive, bàn giao cài đặt

After implementation, provide essential documentation including the Functional Specification Document (FSD), Business Requirements Document (BRD), user manual, test cases, data dictionary, and detailed design Additionally, conduct training for end users to ensure they can effectively operate and utilize the features provided.

Source code: Bàn giao toàn bộ phiên bản final source code liên quan đến hệ thống

Bàn giao toàn bộ mã nguồn chương trình bản final (bao gồm tầng APP/DB và các thành phần khác nếu có)

Khả năng mở rộng của hệ thống: VIB dễ dàng chỉnh sửa, customize màn hình, báo cáo

Phát triển phần mềm theo tiêu chuẩn CoreX của VIB

2.1 Yêu cầu về kiến trúc tổng quan/ Phát triển

Chúng tôi cung cấp thiết kế kiến trúc hệ thống bao gồm mô hình kết nối, công nghệ sử dụng, giao thức kết nối và yêu cầu hạ tầng cần thiết để cài đặt và vận hành hiệu quả.

Cung cấp sơ đồ triển khai về mặt vật lý:

- Yêu cầu về máy chủ, lưu trữ, phần cứng cần thiết để triển khai cho môi trường

- Hệ điều hành, phần mềm yêu cầu cho Đáp ứng

Trong vòng 5 năm tới, khả năng tăng trưởng dữ liệu dự kiến sẽ đạt mức ấn tượng, nhờ vào các phương pháp tính toán và đo lường tiên tiến Để hỗ trợ quá trình này, đề nghị cung cấp tài liệu thiết kế dữ liệu chi tiết, giúp tối ưu hóa việc thu thập và phân tích thông tin.

- Tài liệu phân tích thiết kế cơ sở dữ liệu

- Luồng dữ liệu và mô hình tích hợp

- Mô hình dữ liệu Logical và Physical Đáp ứng

Hỗ trợ các giao thức

- Message Queue (Active MQ, JMS)

- Web service SOAP/ REST over

2.2 Yêu cầu quản lý phiên

Hệ thống phải có cơ chế quản lý phiên thông qua Session Token

Session Token được sinh ra là ngẫu nhiên

Session phải hết hạn sau khoảng thời gian người dùng không tương tác với hệ thống

Session thiết lập trong trong tham số cấu hình hệ thống mỗi 10 phút người dùng không tương tác hệ thống

2.3 Yêu cầu xử lý thông báo lỗi Ứng dụng phải có cơ chế xử lý tất cả các thông báo lỗi, ngoại lệ trả về

Mã lỗi được thiết lập theo tài liệu thiết kế từng chức năng

Các ứng dụng không nên hiển thị thông báo lỗi hệ thống cho người dùng, đặc biệt là những thông báo liên quan đến cấu hình Thay vào đó, ứng dụng cần xây dựng một trang báo lỗi hoặc thông điệp lỗi chung cho các sự cố và ngoại lệ, tránh cung cấp thông tin chi tiết về lỗi Thông báo lỗi chi tiết chỉ nên được gửi cho quản trị viên hệ thống để đảm bảo tính bảo mật và trải nghiệm người dùng tốt hơn.

2.4 Khả năng chỉnh sửa, nâng cấp

Hệ thống được thiết kế theo hưởng mở, có khả năng tích hợp, mở rộng trong tương lai

Hệ thống có khả năng mở rộng nếu VIB kết nối thêm các kênh khác VIB dễ dàng chỉnh sửa, customize màn hình, báo cáo

Tương thích với nhiều loại trình duyệt web:

- Chrome, Firefox, MS Edge: Bất kỳ phiên bản nào được phát hành trong sáu tháng gần nhất Đáp ứng

Hỗ trợ ký tự Unicode (UTF 8) Đáp ứng

Hệ thống hỗ trợ Responsive Web cho phép tương thích trên nhiều thiết bị như máy tính, máy tính bảng Đáp ứng

1.2.1.2 Đội ngũ và phân công dự án

- Sơ đồ quản lý nhân sự của dự án

Hình 1.2.1.2.1 Sơ đồ quản lý nhân sự dự án

- Giới thiệu đội ngũ dự án:

Nguyễn Thị Minh – Chịu trách nhiệm dự án

Email minhnt71@fpt.com.vn Địa chỉ B16 - Đống Đa Hà Nội-

Kinh nghiệm 1 năm kinh nghiệm

Bùi Thị Hằng – Chuyên viên phân tích nghiệp vụ

10 Địa chỉ 46 Phạm Ngọc Thạch – Đống Đa - Hà Nội Kinh nghiệm 1 năm kinh nghiệm

Nguyễn Thị Thu Thúy - Chuyên viên kiểm thử

Email thuyntt179@fpt.com.vn Địa chỉ 12 Chùa Bộc– Đống Đa - Hà Nội Kinh nghiệm 1 năm kinh nghiệm

Phạm Đức An Chuyên viên kiểm thử-

Email anpd4@fpt.com.vn Địa chỉ Số 5 ngõ 138 Tân Triều - Thanh Trì - Hà Nội Kinh nghiệm 1 năm kinh nghiệm

Nguyễn Trung Đức – Chuyên viên lập trình

Email duc.nguyentrung@fssc.com.vn Địa chỉ 51 Tam Khương Đống Đa Hà Nội- -

Kinh nghiệm 1 năm kinh nghiệm

- WBS - Cấu trúc phân rã công việc trong dự án phát triển hệ thống quản lý tiền mặt ngân hàng VIB

Hình 1.2.1.2.2 Sơ đồ phân rã toàn bộ công việc dự án phát triển hệ thống quản lý tiền mặt ngân hàng VIB

1.2.2 Giám sát và kiểm soát

- Biên bản các cuộc họp của dự án được lưu lại

- Tài liệu về yêu cầu, đặc tả chức năng hệ thống (FSD), được phê duyệt, chấp thuận giữa 2 bên, được lưu lại

Trong quá trình triển khai dự án, nếu phát sinh vấn đề hoặc có yêu cầu thay đổi, nhóm dự án sẽ xem xét xem các thay đổi này có vượt quá phạm vi đã định hay không Nếu không, hai bên sẽ hợp tác để xác nhận những thay đổi này, và tài liệu yêu cầu thay đổi sẽ được ghi chép và lưu trữ Tùy thuộc vào mức độ thay đổi và ảnh hưởng của yêu cầu, sẽ quyết định có tổ chức cuộc họp hay chỉ cần gửi email xác nhận.

Quá trình họp bao gồm việc xác định phạm vi dự án, nghiệm thu dự án và bàn giao hệ thống Để đảm bảo thành công, cần có đầy đủ các nhân sự chịu trách nhiệm triển khai dự án từ cả hai bên.

- Các tài liệu dev, test, hướng dẫn sử dụng user sẽ được bàn giao cuối dự án

- Công cụ phát triển dự án:

+ Công cụ lập trình: Laptop cá nhân (Visual studio, SQL server, git hub, )

+ Công cụ hỗ trợ: Microsoft Office, draw.io, Jira, Bizagi Modeler, Instagantt, Discord,

+ Công cụ quản lý: MS Excel, Skype Business, dropbox, drive,

Các bên liên quan/ Đối tác

Bên đưa ra yêu cầu: Ngân hàng Thương mại cổ phần Quốc tế Việt Nam VIB Bên nhóm dự án thực hiện: Nhóm dự án MATH.

Hình th ức đầu tư củ a d án 12 ự CHƯƠNG 2: TRIỂN KHAI DỰ ÁN

Dự án được thực hiện với nguồn vốn đầu tư từ Ngân hàng Thương mại cổ phần Quốc tế Việt Nam (VIB) và sẽ được giải ngân theo từng giai đoạn cụ thể.

Dự án xác định dự kiến số tiền để hoàn thành dự án là 900 triệu VNĐ

Dự án nhận thanh toán qua 2 giai đoạn:

- Giai đoạn bắt đầu dự án: nhận 40% tổng chi phí dự án

- Giai đoạn hoàn thành và bàn giao dự án: nhận 60% chi phí còn lại

STT Ngày Giá trị vốn Nhà đầu tư Người nhận quyết

1 7/2/2022 360.000.000đ Ngân hàng VIB Nguyễn Thị Minh

2 6/4/2022 540.000.000đ Ngân hàng VIB Nguyễn Thị Minh

CHƯƠNG 2: TRIỂN KHAI DỰ ÁN

Thi t k h ế ế ệ thống

2.1.1.1 Quy trình ti p qu liên chi nhánh ế ỹ

Bước 1: Teller tại chi nhánh tiếp quỹ được cấp quyền thực hiện tạo giao dịch mới Giao dịch ở trạng thái - N-New.

Bước 2: Teller hoàn thành nhập thông tin trên giao diện hệ thống

- Nếu hạn mức không vượt quá quyền của Teller thì hệ thống cho phép Teller thực hiện xác nhận giao dịch

Giao dịch ở trạng thái A – Approve

Nếu hạn mức giao dịch vượt quá quyền hạn của Teller, hệ thống chỉ cho phép Vault có hạn mức cao hơn thực hiện xác nhận hoặc từ chối giao dịch.

Giao dịch ở trạng thái P – Pending

+ Nếu xác nhận giao dịch

Giao dịch ở trạng thái A - Approve

+ Nếu từ chối giao dịch

Giao dịch ở trạng thái R - Reject

Nhập thông tin lý do hủy giao dịch Đẩy giao dịch lại bước 1

Bước 3: Supervisor tại chi nhánh tiếp quỹ thực hiện duyệt lệnh chuyển tiền

Trạng thái chuyển tiền Send Status: Succsess

Trạng thái chuyển tiền Send Status: Failed

- Nếu hết thời gian phê duyệt

Trạng thái chuyển tiền Send Status: Time out

Giao dịch ở trạng thái P:Pending Đẩy lại giao dịch về bước 2

Bước 4: Vault tại chi nhánh tiếp nhận quỹ thực hiện tiếp nhận giao dịch

- Nếu Vault thực hiện xác nhận giao dịch

- Nếu thực hiện hủy giao dịch

- Nếu thực hiện từ chối giao dịch

Vault nhập lý do từ chối giao dịch Đẩy lại giao dịch về bước 3

Bước 5: Supervisor chi nhánh nhận quỹ thực hiện duyệt lệnh nhận quỹ

- Nếu Supervisor xác nhận giao dịch

Trạng thái nhận tiền Receive Status: Success

Hệ thống ghi nhận thông tin giao dịch và lưu thông tin vào DB Hạch toán vào core

Kết thúc giao dịch tiếp quỹ liên chi nhánh

- Nếu thực hiện hủy giao dịch

Trạng thái nhận tiền Receive Status: Failed

- Nếu hết thời gian phê duyệt

Trạng thái nhận tiền Receive Status: Time out

Giao dịch ở trạng thái S-R Đẩy lại giao dịch về bước 4

2.1.1.2 Quy trình điều chuyển quỹ giữa Teller-Teller/ Teler Vault -

Bước 1: Teller/Vault được cấp quyền thực hiện yêu cầu mở giao dịch điều chuyển quỹ Bước 2: Teller/Vault hoàn tất thông tin trên giao diện hệ thống

- Nếu thông tin hợp lệ:

Hệ thống lưu thông tin

Giao dịch ở trạng thái N:New

Hệ thống cảnh báo, hiển thị lỗi, đồng thời không lưu thông tin giao dịch Bước 3:

- Nếu hạn mức giao dịch không vượt quá hạn mức cho phép Teller/Vault thực hiện kiểm duyệt giao dịch

Giao dịch chuyển sang trạng thái P:Pending / V-P

Teller/Vault nhập thông tin lý do từ chối

Giao dịch ở trạng thái R:Reject / V-R Đẩy lại giao dịch về bước 2

- Nếu Nếu hạn mức giao dịch không vượt quá hạn mức cho phép Teller/Vault thực hiện kiểm duyệt giao dịch

Supervisor thực hiện kiểm duyệt giao dịch

+ Nếu đồng ý chấp nhận giao dịch

Giao dịch chuyển sang trạng thái S-A

+ Nếu không chấp nhận giao dịch

Giao dịch chuyển sang trạng thái S-R

Supervisor nhập lý do từ chối giao dịch Đẩy giao dịch về bước 3

Bước 4: Verifier thực hiện xác nhận giao dịch đã thực hiện

Hệ thống lưu lại thông tin giao dịch

2.1.1.3 Quy trình điều chuyển tiền trong kho - ngoài kho

Bước 1: Vault/Safe được cấp quyền thực hiện giao dịch điều chuyển tiền vào và ra

Bước 2: Vault/Safe thực hoàn tất thông tin trên giao diện hệ thống, nhấn nút Save hệ thống tự động kiểm tra các điều kiện

- Nếu thông tin giao dịch hợp lệ:

+ Hệ thống lưu thông tin

+ Hiển thị thông báo thành công

+ Trạng thái giao dịch mới N: New

- Nếu thông tin giao dịch không hợp lệ:

Hệ thống cảnh báo và hiển thị lỗi không lưu trữ thông tin giao dịch Trong bước 3, các giao dịch có trạng thái N:new sẽ được phép tiếp tục kiểm duyệt hoặc hủy bỏ.

+ Nếu muốn kiểm duyệt, nhấn Submit => Trạng thái giao dịch chuyển thành P: Pending

+ Nếu muốn hủy giao dịch, nhấn Cancel => Trạng thái giao dịch chuyển thành

Bước 4: Giao dịch có trạng thái thái Pending, Supervisor thực hiện kiểm duyệt:

Trạng thái giao dịch chuyển thành A;Approve

Trạng thái đẩy giao dịch cập nhật: Sussess

Hệ thống lưu thông tin vào core

Thông báo quá trình lỗi

Trạng thái giao dịch vẫn ở P:Pending

Trạng thái đẩy giao dịch cập nhật là: Fail/Time out

Nhấn lại Approve để đẩy lại giao dịch

- Từ chối duyệt, nhấn Reject Hệ thống chuyển sang giao diện mới, nhập lý do Nhấn Confirm

+ Hủy thành công, trạng thái giao dịch chuyển thành R: Reject

Thông tin được lưu trong hệ thống

- Chuyển lại giao dịch, nhấn Return Hệ thống chuyển sang giao diện mới, nhập lý do Nhấn Confirm

Trạng thái giao dịch sẽ chuyển từ P:Pending sang N: New

+ Chuyển lại giao dịch không thành công:

2.1.1.4 Quy trình n p ti n/rút ti n tộ ề ề ừ các tổ chức tín dụng khác

Bước 1: Vault được cấp quyền thực hiện tạo giao dịch nộp/rút tiền

Bước 2: Vault thực hiện hoàn tất thông tin trên màn hình giao diện

- Khi thực hiện giao dịch gửi tiền (Tran typeosit)

+ Nếu thông tin hợp lệ và Số tiền gửi tương ứng từng loại tiền nhỏ hơn số tiền hiện có của Vault (tiền ngoài kho):

Hệ thống cảnh báo, hiển thị lỗi, đồng thời không lưu thông tin giao dịch

- Khi thực hiện giao dịch rút tiền (Tran type=Withdrawal)

+ Nếu thông tin hợp lệ và Số tiền rút về phân bổ vào Vault nhỏ hơn hạn mức tồn quỹ của Vault:

Hệ thống cảnh báo, hiển thị lỗi, đồng thời không lưu thông tin giao dịch Bước 3: Vault thực hiện xác nhận giao dịch

- Nếu chấp nhận thực hiện submit

Posting Status (Trạng thái đẩy giao dịch sang hệ thống core): Pending

- Nếu từ chối giao dịch

Vault nhập lý do từ chối giao dịch

Bước 4: Supervisor thực hiện kiểm duyệt giao dịch

- Nếu đồng ý xác nhận giao dịch

Posting Status (Trạng thái đẩy giao dịch sang hệ thống core): Success

Lưu thông tin giao dịch, hạch toán tại core

- Nếu từ chối giao dịch

Posting Status (Trạng thái đẩy giao dịch sang hệ thống core): Failed

2.1.1.5 Quy trình cân ti n trong ngày ề

Bước 1: Teller/Vault thực hiện kiêm tra gia dịch trong ngày của các giao dịch thuộc quyền được cấp

(User tại trụ sở chính: được phép chọn chi nhánh cần tìm kiếm trong danh sách;

Hệ thống mặc định – All

User tại các Chi nhánh: Hệ thống lấy thông tin chi nhánh khi user đăng nhập vào chương trình.)

Màn hình hiển thị thông tin tiền ghi nhận tại hệ thống

- Nếu Teller thực hiện chọn loại tiền tệ cần xem thông tin số dư đầu ngày, dòng tiền vào, dòng tiền ra và số dư hiện tại

Thực hiện nhấn “View Balance”

Hệ thống hiển thị thông tin tại thời điểm xem

- Nếu teller thực hiện check cân tiền của từng loại tiền giữa số tiền thực tế tại bàn và

21 số tiền ghi nhận trong hệ thống

Hệ thống kiểm tra số tiền tại trường Total và Total tại bảng kê chi tiết: Nếu lệch nhau sẽ đưa thông báo cho Teller biết

Hệ thống hiện thị kết quả chi tiết trên màn hình

Bước 3: Thực hiện lưu lại thông tin giao dịch cân tiền trong ngày

2.1.1.6 Quy trình h ch toán thạ ừa thiếu qu cỹ ủa Teller/Vault

Bước 1: Vaul/Teller thực hiện gaio dịch hạch toán tiền thừa thiếu quỹ thuộc quyền đươc cấp

Bước 2: Vault/Safe thực hoàn tất thông tin trên giao diện hệ thống, nhấn nút Save hệ thống tự động kiểm tra các điều kiện

- Nếu thông tin giao dịch hợp lệ:

+ Hệ thống lưu thông tin

+ Hiển thị thông báo thành công

+ Trạng thái giao dịch mới N: New

- Nếu thông tin giao dịch không hợp lệ:

Hệ thống cảnh báo hiển thị lỗi mà không lưu trữ thông tin giao dịch Trong bước 3, các giao dịch có trạng thái N:new được phép tiếp tục kiểm duyệt hoặc hủy bỏ.

+ Nếu muốn kiểm duyệt, nhấn Submit => Trạng thái giao dịch chuyển thành P: Pending

+ Nếu muốn hủy giao dịch, nhấn Cancel => Trạng thái giao dịch chuyển thành C: Cancel

Bước 4: Giao dịch có trạng thái thái Pending, Supervisor thực hiện kiểm duyệt:

Trạng thái giao dịch chuyển thành A;Approve

Trạng thái đẩy giao dịch cập nhật: Sussess

Hệ thống lưu thông tin vào core

Trạng thái đẩy giao dịch cập nhật là: Fail/Time out

Nhấn lại Approve để đẩy lại giao dịch

- Từ chối duyệt, nhấn Reject Hệ thống chuyển sang giao diện mới, nhập lý do Nhấn Confirm

Trạng thái giao dịch chuyển thành R: Reject

Thông tin được lưu trong hệ thống

Thông báo quá trình duyệt bị lỗi

- Chuyển lại giao dịch, nhấn Return Hệ thống chuyển sang giao diện mới, nhập lý do Nhấn Confirm

Trạng thái giao dịch sẽ chuyển từ P:Pending sang N: New

+ Chuyển lại giao dịch không thành công:

2.1.2 Sơ đồ luồng cơ bản (Biểu đồ hoạt động)

Hình 2.1.2.1 Biểu đồ Branch Cash Transfer

Hình 2.1.2.2 Biểu đồ Teller Cash Transfer

2.1.3.1 Xây d ng CSDL mự ức khái niệm

Với module quản lý tiền mặt này, các bảng dữ liệu thông tin chung Chi nhánh, Nhân viên, Chức vụ,… sẽ được cung cấp

Nhóm xác định các thực thể còn lại để triển khai thiết kế CSDL:

Xác định mối quan hệ giữa các thực thể:

Thực thể Quan hệ Thực thể

Nhân viên Thuộc Chi nhánh

Nhân viên Thuộc Phòng ban

Nhân viên Có Chức vụ

Nhân viên Kiểm tra Két

Nhân viên Kiểm tra LuongTienTheoMenhGiaTiep

Nhân viên Kiểm tra ChiTietKet

Nhân viên Kiểm tra LuongTienTheoMenhGiaDieu

Nhân viên Tạo giao dịch tại Chi nhánh

Nhân viên Yêu cầu phê duyệt giao dịch với Nhân viên

Nhân viên Từ chối giao dịch của Nhân viên

Nhân viên Chấp nhận giao dịch của Nhân viên

Ngân hàng Điều chuyển tiền đến Ngân hàng

Chi nhánh Điều chuyển tiền đến Chi nhánh

2.1.3.2 Xây d ng CSDL mự ức logic

- NganHang (MaNH, TenNH, DiaChi, SDT)

- ChiNhanh (MaCN,TenCN, DiaChi, SDT, MaNH)

- NhanVien (MaNV, TenNV, GioiTinh, NgaySinh, SoCCCD, DiaChi, SDT, MaCV, MaPB, MaCN)

- Giao dich (MaGiaoDich, LoaiGiaoDich, SoTien, NgayGiaoDich, MaNhanVien, MaCN, MaLoaiTien)

- ChiTietKet (MaChiTietKet, MaMenhGia, SoLuong, MaKet)

- LuongTienTheoMenhGiaTiepQuyLienChiNhanh (MaLTTMGTQLCN, MaCN, MaCN, HanMuc, TongTien, NgayYeuCau, NgayTiep, NgayKetThuc)

- ChiTietLuongTienTheoMenhGiaTiepQuyLienChiNhanh (MaCTLTTMGTQLCN, MaLTTMGTQLCN, MaMenhGia, SoLuong)

- LuongTienTheoMenhGiaTiepQuyLienNH (MaLTTMGTQLNH, MaNH, MaNH, HanMuc, TongTien, NgayYeuCau, NgayTiep, NgayKetThuc)

- ChiTietLuongTienTheoMenhGiaTiepQuyLienNH (MaCTLTTMGTQLNH, MaLTTMGTQLNH, MaMenhGia, SoLuong)

(MaLTTMGDCQGVT, MaNV MaNV, , HanMuc, TongTien, NgayDieuChuyen)

- LuongTienTheoMenhGiaDieuChuyenVaultSafe (MaLTTMGDCVS, MaNV, MaKet, HanMuc, TongTien, NgayDieuChuyen)

- ChiTietLuongTienTheoMenhGiaDieuChuyenVaultSafe (MaCTLTTMGDCVS, MaLTTMGDCVS, MaMenhGia, SoLuong)

(MaLTTMGDCQGTT, MaNV, MaNV, HanMuc, TongTien, NgayDieuChuyen)

(MaCTLTTMGDCQGTT, MaLTTMGDCQGTT, MaMenhGia, SoLuong) 2.1.3.3 Xây d ng CSDL mự ức vât lý

Thuộc tính Kiểu dữ liệu Kích cỡ Ràng buộc Giải thích

MaCN Varchar 20 Khóa chính Mã chi nhánh

TenCN Nvarchar 50 Tên chi nhánh

SDT Varchar 15 Số điện thoại

MaNH Varchar 20 Khóa ngoại Mã ngân hàng

Bảng 2.1.3.3.1 Bảng Chi nhánh 2.1.3.3.2 B ng Nhân viên ả

MaNV Varchar 20 Khóa chính Mã nhân viên

MaCN Varchar 20 Khóa ngoại Mã chi nhánh

MaPB Varchar 20 Khóa ngoại Mã phòng ban

TenNV Nvarchar 50 Tên nhân viên

SoCCCD Varchar 15 Số căn cước công dân

Bảng 2.1.3.3.2 Bảng Nhân viên 2.1.3.3.3 B ng Phòng ban ả

MaPB Varchar 20 Khóa chính Mã phòng ban

TenPB Nvarchar 50 Tên phòng ban

Bảng 2.1.3.3.3 Bảng Phòng ban 2.1.3.3.4 B ng Chả ức vụ

MaCV Varchar 20 Khóa chính Mã chức vụ

TenCV Nvarchar 50 Tên chức vụ

Bảng 2.1.3.3.4 Bảng Chức vụ 2.1.3.3.5 B ng Két ả

MaKet Varchar 20 Khóa chính Mã két

Bảng 2.1.3.3.5 Bảng Két 2.1.3.3.6 B ng Chi ti t két ả ế

MaChiTietKet Varchar 20 Khóa chính Mã chi tiết két

MaMenhGia Varchar 20 Khóa ngoại Mã mệnh giá

Số lượng Int Số lượng

MaKet Varchar 20 Khóa ngoại Mã két

Bảng 2.1.3.3.6 Bảng Chi tiết két 2.1.3.3.7 B ng Giao dả ịch

MaGiaoDich Varchar 20 Khóa chính Mã két

LoaiGiaoDich Nvarchar 50 Loại giao dịch

NgayGiaoDich Date Ngày giao dịch

MaNhanVien Varchar 20 Khóa ngoại Mã nhân viên

MaLoaiTien Varchar 20 Khóa ngoại Mã loại tiền

Bảng 2.1.3.3.7 Bảng Giao dịch 2.1.3.3.8 B ng Loả ại tiền

MaLoaiTien Varchar 20 Khóa chính Mã loại tiền

DonViTienTe Nvarchar 50 Đơn vị tiền tệ

Bảng 2.1.3.3.8 Bảng Loại tiền 2.1.3.3.9 B ng M nh giá ả ệ

MaMenhGia Varchar 20 Khóa chính Mã mệnh giá

MaLoaiTien Varchar 20 Khóa ngoại Mã loại tiền

Bảng 2.1.3.3.9 Bảng Mệnh giá 2.1.3.3.10 B ng Tr ng thái ả ạ

MaTrangThai Varchar 20 Khóa chính Mã trạng thái

TenTrangThai Nvarchar 50 Tên trạng thái

Bảng 2.1.3.3.10 Bảng Trạng thái 2.1.3.3.11 B ng Ngân hàng ả

MaNH Varchar 20 Khóa chính Mã ngân hàng

TenNH Nvarchar 50 Tên ngân hàng

Bảng 2.1.3.3.11 Bảng Ngân hàng 2.1.3.3.12 Bảng Lượng ti n theo m nh giá ti p qu liên chi nhánh ề ệ ế ỹThuộc tính Kiểu dữ liệu Kích cỡ Ràng buộc Giải thích

Mã lượng tiền theo mệnh giá tiếp quỹ liên chi nhánh

MaCN Varchar 20 Khóa ngoại Mã chi nhánh tiếp

MaCN Varchar 20 Khóa ngoại Mã chi nhánh nhận

NgayYeuCau Date Ngày yêu cầu

NgayKetThuc Date Ngày kết thúc

Bảng 2.1.3.3.12 trình bày lượng tiền theo mệnh giá khi tiếp quỹ liên chi nhánh Bảng 2.1.3.3.13 mô tả chi tiết về lượng tiền theo mệnh giá trong quá trình tiếp quỹ liên chi nhánh, bao gồm các thuộc tính, kiểu dữ liệu, kích cỡ, ràng buộc và giải thích.

Mã chi tiết lượng tiền theo mệnh giá tiếp quỹ liên chi nhánh

Mã lượng tiền theo mệnh giá tiếp quỹ liên chi nhánh

Bảng 2.1.3.3.13 Bảng Chi tiết lượng tiền theo mệnh giá tiếp quỹ liên chi nhánh

2.1.3.3.14 Bảng Lượng ti n theo mề ệnh giá điều chuy n qu gi a Vault - Teller ể ỹ ữ Thuộc tính Kiểu dữ liệu Kích cỡ Ràng buộc Giải thích

Mã lượng tiền theo mệnh giá điều chuyển quỹ giữa Vault - Teller

MaNV Varchar 20 Khóa ngoại Mã nhân viên Vault

MaNV Varchar 20 Khóa ngoại Mã nhân viên Teller

NgayDieuChuyen Date Ngày điều chuyển

Bảng 2.1.3.3.14 Bảng Lượng tiền theo mệnh giá điều chuyển quỹ giữa Vault - Teller

2.1.3.3.15 B ng Chi tiả ết lượng ti n theo mề ệnh giá điều chuy n qu gi a Vault - ể ỹ ữ Teller

Mã chi tiết lượng tiền theo mệnh giá điều chuyển quỹ giữa Vault - Teller

Mã lượng tiền theo mệnh giá điều chuyển quỹ giữa Vault - Teller

Bảng 2.1.3.3.15 Bảng Chi tiết lượng tiền theo mệnh giá điều chuyển quỹ giữa Vault -

Teller 2.1.3.3.16 Bảng Lượng ti n theo mề ệnh giá điều chuy n qu gi a Teller - Teller ể ỹ ữ Thuộc tính Kiểu dữ liệu Kích cỡ Ràng buộc Giải thích

Mã lượng tiền theo mệnh giá điều chuyển quỹ giữa Teller - Teller

MaNV Varchar 20 Khóa ngoại Mã nhân viên Teller chuyển

MaNV Varchar 20 Khóa ngoại Mã nhân viên Teller nhận

Bảng 2.1.3.3.16 Bảng Lượng tiền theo mệnh giá điều chuyển quỹ giữa Teller - Teller

2.1.3.3.17 B ng Chi tiả ết lượng ti n theo mề ệnh giá điều chuy n qu gi u Teller- ể ỹ ữ Teller

Mã chi tiết lượng tiền theo mệnh giá điều chuyển quỹ giữa Teller - Teller

Mã lượng tiền theo mệnh giá điều chuyển quỹ giữa Teller - Teller

Bảng 2.1.3.3.17 Bảng Chi tiết lượng tiền theo mệnh giá điều chuyển quỹ giữa Teller -

Teller 2.1.3.3.18 Bảng Lượng ti n theo mề ệnh giá điều chuy n Vault - Safe ể

Mã lượng tiền theo mệnh giá điều chuyển Vault - Safe

MaNV Varchar 20 Khóa ngoại Mã nhân viên Vault

MaKet Varchar 20 Khóa ngoại Mã két

Bảng 2.1.3.3.18 trình bày lượng tiền theo mệnh giá điều chuyển trong Vault - Safe, trong khi Bảng 2.1.3.3.19 cung cấp chi tiết về việc quản lý tiền theo mệnh giá điều chuyển Các thuộc tính bao gồm kiểu dữ liệu, kích cỡ, và các ràng buộc cần thiết, cùng với giải thích rõ ràng về ý nghĩa của từng mục.

Mã chi tiết lượng tiền theo mệnh giá điều chuyển Vault - Safe

Mã lượng tiền theo mệnh giá điều chuyển Vault - Safe

Bảng 2.1.3.3.19 Bảng Chi tiết lượng tiền theo mệnh giá điều chuyển Vault - Safe 2.1.3.3.20 Bảng Lượng ti n theo m nh giá ti p qu liên ngân hàng ề ệ ế ỹ

Mã lượng tiền theo mệnh giá tiếp quỹ liên ngân hàng

MaNH Varchar 20 Khóa ngoại Mã ngân hàng tiếp

MaNH Varchar 20 Khóa ngoại Mã ngân hàng nhận

NgayYeuCau Date Ngày yêu cầu

NgayKetThuc Date Ngày kết thúc

Bảng 2.1.3.3.20 trình bày lượng tiền theo mệnh giá tiếp quỹ liên ngân hàng, trong khi Bảng 2.1.3.3.21 cung cấp chi tiết về lượng tiền theo mệnh giá tiếp quỹ liên ngân hàng Các thuộc tính bao gồm kiểu dữ liệu, kích cỡ, ràng buộc và giải thích, giúp người đọc hiểu rõ hơn về cấu trúc và nội dung của bảng dữ liệu này.

Mã chi tiết lượng tiền theo mệnh giá tiếp quỹ liên ngân hàng

Mã lượng tiền theo mệnh giá tiếp quỹ liên ngân hàng

Bảng 2.1.3.3.21 Bảng Chi tiết lượng tiền theo mệnh giá tiếp quỹ liên ngân hàng

Các quy ước chung của chức năng

Mỗi chức năng được liên kết với một menu riêng, cho phép người dùng truy cập vào giao diện cụ thể của chức năng khi nhấn vào menu Trên giao diện đó, người dùng sẽ thấy các nút bấm để thực hiện các chức năng khác nhau.

Lọc thông tin (Thêm các điều kiện tìm kiếm)

Refresh lại màn hình Trạng thái giao dịch

Trạng thái Mô tả Ghi chú

N:New Trạng thái khi giao dịch mới được tạo

P: Pending Trạng thái giao dịch khi đẩy sang kiểm duyệt (NSD nhấn nút Submit)

Trạng thái giao dịch khi kiểm soát viên phê duyệt chấp nhận/GDV phê duyệt giao dịch trong hạn mức (NSD nhấn nút Approve)

Trạng thái giao dịch khi kiểm soát viên từ chối phê duyệt/GDV từ chối phê duyệt giao dịch trong hạn mức (NSD nhấn nút Reject)

V-N: Vault.New Trạng thái giao dịch khi Vault kê tiền và ấn nút Save trên form kê tiền

Trạng thái giao dịch khi Vault đẩy sang kiểm duyệt (Vaut nhấn nút Submit trên form kê tiền)

V-R: Vau.Reject Trạng thái giao dịch khi Vault từ chối giao dịch (NSD nhấn nút Reject)

C:Cancel Trạng thái bút toán khi thực hiện hủy giao dịch

Trạng thái giao dịch khi kiểm soát viên

(tại chi nhánh nhận quỹ) duyệt giao dịch

Trạng thái giao dịch khi kiểm soát viên

(tại chi nhánh nhận quỹ) từ chối duyệt giao dịch

Quy định về thao tác

Hệ thống chỉ hiển thị nút lệnh cho NSD kích chọn tương ứng với thao tác NSD tại thời điểm đó và theo quyền NSD được cấp quyền

Màn hình chính quản lý thông tin giao dịch cho phép người sử dụng (NSD) chọn giao dịch, sau đó hệ thống sẽ hiển thị form thông tin chi tiết của giao dịch đó để NSD có thể xem và thực hiện các thao tác như duyệt hoặc hủy giao dịch.

Tất cả mã nguồn được óm qunh ản lý trên git

2.2.1 Chức năng tiếp quỹ liên chi nhánh

2.2.1.1 Màn hình chính chức năng tiếp qu liên chi nhánh ỹ

Hình 2.2.1.1 Màn hình chính chức năng tiếp quỹ liên chi nhánh

- Đối tượng tham gia: NSD được cấp quyền tại chi nhánh gửi, chi nhánh nhận.

2.2.1.2 Màn hình thêm m i giao dớ ịch tiếp quỹ liên chi nhánh

Hình 2.2.1.2 Màn hình thêm mới giao dịch tiếp quỹ liên chi nhánh

- Mục đích màn hình: dùng để thêm mới thông tin tiếp quỹ liên chi nhánh

- Đối tượng tham gia: NSD được cấp quyền.

Sau khi người dùng nhấn nút "Thêm" trên màn hình chính của thông tin quỹ liên chi nhánh, hệ thống sẽ hiển thị một cửa sổ để nhập chi tiết thông tin cần thiết cho người sử dụng.

2.2.1.3 Màn hình ch nh sỉ ửa giao dịch ti p quế ỹ liên chi nhánh

Hình 2.2.1.3 Màn hình chỉnh sửa giao dịch tiếp quỹ liên chi nhánh

- Mục đích màn hình: Cho phép sửa thông tin tiếp quỹ liên chi nhánh

- Điều kiện: Chỉ cho phép đối với các giao dịch tiếp quỹ đang ở trạng thái N:New và chỉ cho sửa các trường yêu cầu nhập thông tin

- Đối tượng tham gia: NSD được cấp quyền

- Thao tác: Sau khi người dùng click vào nút sửa , hệ thống sẽ mở ra cửa sổ để thực hiện sửa thông tin tiếp quỹ

- Các thông tin không được phép sửa, sẽ được làm mờ để NSD không thao tác được. 2.2.2 Chức năng điều chuy n qu giể ỹ ữa Vault –Teller/Teller - Teller

2.2.2.1 Màn hình chính chức năng chuyển qu giỹ ữa Vault Teller/Teller Teller- -

Hình 2.2.2.1 Màn hình chính chức năng chuyển quỹ giữa Vault - Teller/Teller - Teller

- Mục đích màn hình: hiển thị toàn bộ thông tin giao dịch chuyển quỹ giữa Vault-Teller và Teller – Teller

2.2.2.2 Màn hình thêm m i giao d ch chuy n qu gi a Vault - Teller/Teller - Teller ớ ị ể ỹ ữ

Hình 2.2.2.2 Màn hình thêm mới giao dịch chuyển quỹ giữa Vault - Teller/Teller - Teller

- Mục đích màn hình: dùng để thêm mới thông tin tiếp chuyển quỹ nội bộ giữa Vault – Teller/ Teller Teller -

Sau khi người dùng nhấn nút "Thêm" trên màn hình chính của chức năng chuyển quỹ, hệ thống sẽ hiển thị cửa sổ để nhập thông tin chi tiết cần thiết cho quá trình thao tác.

2.2.2.3 Màn hình ch nh sỉ ửa giao dịch chuy n qu gi a Vault - Teller/Teller - Teller ể ỹ ữ

Hình 2.2.2.3 Màn hình chỉnh sửa giao dịch chuyển quỹ giữa Vault - Teller/Teller - Teller

- Mục đích màn hình: Cho phép sửa thông tin chuyển quỹ giữa Vault – Teller/ Teller - Teller

Chỉ cho phép sửa đổi các giao dịch chuyển quỹ chưa được duyệt, tức là những giao dịch có trạng thái "N: New" Việc chỉnh sửa chỉ áp dụng cho các trường yêu cầu nhập thông tin.

- Thao tác: Sau khi người dùng click vào nút sửa , hệ thống sẽ mở ra cửa sổ để thực hiện sửa thông tin

- Các thông tin không được phép sửa, sẽ được làm mờ để NSD không thao tác được.

2.2.3 Chức năng điều chuy n ti n trong kho ngoài kho ể ề –

2.2.3.1 Màn hình chính chức năng điều chuy n ti n trong kho - ngoài kho ể ề

Hình 2.2.3.1 Màn hình chính chức năng điều chuyển tiền trong kho - ngoài kho

- Mục đích màn hình: hiển thị toàn bộ thông tin giao dịch điều chuyển tiền vào và ra két của Vault

2.2.3.2 Màn hình thêm m i giao dớ ịch điều chuy n ti n trong kho - ngoài kho ể ề

Hình 2.2.3.2 Màn hình thêm mới giao dịch điều chuyển tiền trong kho - ngoài kho

- Mục đích màn hình: dùng để thêm mới thông tin chuyển tiền trong kho – ngoài kho

Sau khi người dùng nhấn nút "Thêm" trên màn hình chính, hệ thống sẽ hiển thị cửa sổ để nhập thông tin chi tiết, giúp người dùng thực hiện thao tác một cách dễ dàng.

2.2.3.3 Màn hình ch nh sỉ ửa giao dịch điều chuy n ti n trong kho - ngoài kho ể ề

Hình 2.2.3.3 Màn hình chỉnh sửa giao dịch điều chuyển tiền trong kho - ngoài kho

- Mục đích màn hình: Cho phép sửa thông tin chuyển tiền trong kho – ngoài kho

- Điều kiện: Chỉ cho phép đối với các giao dịch chưa được duyệt (trạng thái giao dịch là N:New)

- Thao tác: Sau khi người dùng click vào nút sửa , hệ thống sẽ mở ra cửa sổ để thực hiện sửa thông tin chi tiết

2.2.3.4 Màn hình duyệt giao dịch điều chuy n ti n trong kho - ngoài kho ể ề

Hình 2.2.3.4 Màn hình duyệt giao dịch điều chuyển tiền trong kho - ngoài kho

- Mục đích màn hình: Để xem chi tiết thông tin giao dịch và thực hiện duyệt/từ chối

- Đối tượng sử dụng: NSD được cấp quyền

Người sử dụng chỉ cần nhấn vào giao dịch tương ứng trên màn hình chính của thông tin chuyển tiền trong kho hoặc ngoài kho, hệ thống sẽ hiển thị giao diện cho phép xem và thực hiện các thao tác trên giao dịch đó.

2.2.4 Chức năng nộp ti n/rút ti n t các t ề ề ừ ổchức tín dụng khác

2.2.4.1 Màn hình chính chức năng nộp ti n/rút ti n t ề ề ừcác tổ chức tín d ng khác ụ

Hình 2.2.4.1 Màn hình chính chức năng nộp tiền/rút tiền từ các tổ chức tín dụng khác

- Mục đích màn hình: hiển thị toàn bộ thông tin giao dịch nộp tiền/rút tiền từ các tổ chức tín dụng khác

2.2.4.2 Màn hình thêm m i giao dớ ịch nộp ti n/rút ti n tề ề ừ các tổchức tín d ng khác ụ

Hình 2.2.4.2 Màn hình thêm mới giao dịch nộp tiền/rút tiền từ các tổ chức tín dụng khác

- Mục đích màn hình: dùng để thêm mới thông tin nộp tiền/rút tiền vào các tổ chức tín dụng

2.2.4.3 Màn hình ch nh sỉ ửa giao dịch n p ti n/rút ti n t các t ộ ề ề ừ ổchức tín dụng khác

Hình 2.2.4.3 Màn hình chỉnh sửa giao dịch nộp tiền/rút tiền từ các tổ chức tín dụng khác

- Mục đích màn hình: Cho phép sửa thông tin nộp/rút tiền từ các tổ chức tín dụng

- Điều kiện: Chỉ cho phép đối với các giao dịch chưa được duyệt (trạng thái giao dịch là

- Thao tác: Sau khi người dùng click vào nút sửa , hệ thống sẽ mở ra cửa sổ để thực hiện sửa thông tin chi tiết

2.2.5 Chức năng cân tiền trong ngày

2.2.5.1 Màn hình chính chức năng cân tiền trong ngày

Hình 2.2.5.1 Màn hình chính chức năng cân tiền trong ngày

- Mục đích màn hình: hiển thị toàn bộ thông tin cân tiền trong ngày của teller theo từng chi nhánh

2.2.5.2 Màn hình cân ti n cề ủa teller

Hình 2.2.5.2 Màn hình cân tiền của teller

Tuyên b d án 56 ố ự 3.2 Qu n lý th i gian 59ảờ 3.2.1 Sơ đồ mạng AOA

Tên dự án: Xây dựng hệ thống quản lý tiền mặt của ngân hàng VIB

Ngày bắt đầu: 07/02/2022 Ngày kết thúc: 08/04/2022 Mốc đánh giá:

Chuyển giao xong trước ngày 08/04/2022

Chịu trách nhiệm dự án: Nguyễn Thị Minh

Thực hiện dự án: Nhóm 1

Dự án quản lý tiền mặt của ngân hàng VIB là một phương thức quan trọng, bao gồm các giao dịch và biến động tiền mặt giữa các chi nhánh, phòng giao dịch và hội sở, cũng như với các ngân hàng khác Dự án này có tính khả thi cao và độ phức tạp lớn, với phương pháp và kết quả được xác định rõ ràng Trong quá trình chuẩn bị tài liệu, nhóm đã xác định phạm vi và yêu cầu của ngân hàng, đồng thời đưa ra các ý tưởng cụ thể về quy trình thực hiện và triển khai dự án, cùng với việc cung cấp và cập nhật tài liệu về tình hình dự án để bảo trì trong tương lai.

Các tính chất và yêu cầu của sản phẩm:

- User: Nhân viên của các phòng ban, chi nhánh, hội sở được thực hiện thêm, sửa, xóa, in, xuất báo cáo, kiểm tra, … trong phân quyền của mình

- Admin: quản trị toàn bộ hệ thống, phân quyền cho User, tạo mới User

- Giao diện đẹp, thu hút, khoa học, màu sắc đặc trưng của ngân hàng VIB

- Tính năng dễ sử dụng

- Hệ thống hoàn thiện được tích hợp vào COREX

- Các yêu cầu chức năng của sản phẩm: (Theo từng danh mục)

+ Hiển thị trường thông tin các giao dịch của mỗi màn hình chức năng

+ Cho phép (Tìm kiếm, Thêm, Sửa, Refresh, Print, Export to excel, Exit) tại màn hình chức năng tiếp quỹ liên chi nhánh

+ Cho phép (Tìm kiếm, Thêm, Sửa, Refresh, Print, Export to excel, Exit) tại màn hình chính chức năng điều chuyển giữa Vault-Teller/Teller - Teller

+ Cho phép (Tìm kiếm, Thêm, Sửa, Refresh, Print, Export to excel, Exit) tại màn hình chính chức năng điều chuyển tiền trong kho-ngoài kho

+ Cho phép (Tìm kiếm, Thêm, Sửa, Refresh, Print, Export to excel, Exit) tại màn hình chính chức năng nộp/rút tiền từ các tổ chức tín dụng khác

+ Cho phép ( Tìm kiếm, Print, Export to excel, Exit) tại màn hình chính chức năng cân tiền

+ Cho phép (Tìm kiếm, Thêm, Sửa, Refresh, Print, Export to excel, Exit) tại màn hình chính chức năng hạch toán thừa thiếu quỹ của Teller/Vault

- Các yêu cầu phi chức năng:

+ Khả năng sẵn sàng của hệ thống: 24/7

Thời gian thực hiện GD:

+ Thời gian trích xuất dữ liệu:

Thời gian sinh báo báo ngày không quá 1 phút

Thời gian sinh báo cáo tháng không quá 2 phút

+ Ngôn ngữ hỗ trợ: Anh/Việt

+ Lưu trữ dữ liệu: lưu trữ trong vòng 20 năm

- Giao diện người dùng: Giao diện bố cục hợp lý, khoa học, thân thiện, màu sắc theo chuẩn VIB

- Cung cấp các tài liệu sau sau khi triển khai: FSD, BRD, user manual, test case, data dictionary, detail design

- Đào tạo end user vận hành, sử dụng tính năng

- Source code: Bàn giao toàn bộ phiên bản final source code liên quan đến hệ thống (app, middleware, db code )

- Khả năng mở rộng của hệ thống: VIB dễ dàng chỉnh sửa, customize màn hình, báo cáo

Tổng kết về các sản phẩm chuyển giao của dự án:

- Hệ thống mà đơn vị dự án xây dựng

- Tài liệu phát triển, kiểm thử, biên bản yêu cầu phát sinh, thay đổi của hệ thống

- Tài liệu hướng dẫn người dùng

- Hướng dẫn người dùng (VIB) cách quản lý, sử dụng hệ thống để quản lý tiền mặt

- Support hệ thống trong giai đoạn vận hành ban đầu như đã thỏa thuận Các kết quả liên quan đến quản lý dự án:

- Kế hoạch nguồn lực, phân công

- Quản lý thời gian, chi phí, nhân lực, chất lượng, rủi ro

- Quyết toán chi phí, tài chính

- Xác định hướng phát triển của hệ thống

- Cài đặt môi trường, domain

- Thiết kế cơ sở dữ liệu

- Lập trình front end, back end

- Kiểm thử, đánh giá và tinh chỉnh

- Chuyển giao cho người dùng

- Bảo trì và cập nhật

Các yêu cầu để đánh giá sự thành công của dự án

1 Sản phẩm được hoàn thành đúng thời hạn đề ra

2 Sản phẩm hoạt động ổn định và đúng như dự kiến

3 Dự án không vượt dự toán

4 Dự án phù hợp và đáp ứng với các yêu cầu được đặt ra

Tính khả thi của dự án

- Tính khả thi công nghệ và hệ thống: ngân hàng cần trang bị internet ổn định, thiết bị điện tử như máy tính

VIB cần xem xét tính khả thi kinh tế khi hàng năm phải chi một khoản tiền để duy trì và bảo hành hệ thống sau khi hết hạn bảo hành Bên cạnh đó, việc cập nhật và cải tiến hệ thống cũng đòi hỏi một phần chi phí phụ thuộc vào các yêu cầu cụ thể.

- Tính khả thi pháp lý: Tuân thủ quy định của ngân hàng, nhà nước, chính sách pháp luật

- Tính khả thi vận hành: hệ thống dễ dàng vận hành, đưa vào sử dụng nhanh chóng

3.2.1.1 Các công vi c c n thệ ầ ực hiện trong sơ đồAOA

Dưới đây là bảng tổng hợp các công việc chính trong kế hoạch phát triển dự án quản lý tiền mặt, với mục đích thể hiện sơ đồ mạng AOA một cách rõ ràng và hiệu quả.

Bảng công việc bao gồm 21 đầu mục chính, trong đó thời gian hỗ trợ sau dự án là khoảng thời gian dài nhất Quá trình quản lý phạm vi, thời gian, chi phí, rủi ro, nhân lực và chất lượng bắt đầu từ giai đoạn ước lượng quản lý đầu dự án và kéo dài đến khi dự án hoàn tất.

STT Tên công việc Đặt tên Thời gian

1 Xác định yêu cầu A 3 Làm ngay

2 Demo quy trình và giao diện B 5 Sau A

4 Quản lý phạm vi C 5 Sau A

5 Quản lí thời gian D 48 Sau C

6 Quản lý chi phí E 46 Sau C

7 Quản lý rủi ro F 46 Sau C

8 Quản lý chất lượng G 46 Sau C

9 Quản lý nhân lực H 46 Sau C

10 Phân tích và thiết kế quy trình I 2 Sau B

11 Thiết kế giao diện K 2 Sau B

14 Lập trình Front-End và Back-End N 15 Sau M

15 Kiểm thử đơn vị, module, giao diện O 3 Sau K,N

16 Điều chỉnh thay đổi sau lập trình P 19 Sau O

17 Tích hợp hệ thống Q 2 Sau P

18 Kiểm thử hệ thống R 4 Sau Q

19 Đưa hệ thống vào hoạt động S 9 Sau R

20 Kế hoạch chuyển giao X 5 Sau S

H,Y Bảng 3.2.1.1 Bảng đầu công việc chính của kế hoạch

Hình 3.2.1.2 Sơ đồ mạng AOA Lập và xác định đường găng:

Vậy đường A-B-I-L-M-N-O-P-Q-R-S-X-Y-Z= 261 dài nhất nên là đường găng của dự án

Thời gian bắt đầu sớm

Thời gian kết thúc sớm

Thời gian bắt đầu muộn

Thời gian kết thúc muộn

Thời gian dự trữ toàn phần

Thời gian dự trữ tự do

- ES: Thời gian bắt đầu sớm của công việc a

- EF: Thời gian kết thúc sớm của công việc a

- LS: Thời gian bắt đầu muộn của công việc a

- LF: Thời gian kết thúc muộn của công việc a

Thời gian dự trữ toàn phần của công việc là khoảng thời gian mà công việc có thể kéo dài mà không ảnh hưởng đến ngày kết thúc của dự án, được tính bằng công thức LS(a) - ES(a).

Thời gian dự trữ tự do của công việc là khoảng thời gian mà một công việc có thể kéo dài mà không ảnh hưởng đến thời gian bắt đầu của công việc tiếp theo Nó được xác định bằng cách lấy giá trị nhỏ nhất của ngày bắt đầu sớm nhất (ES) của tất cả các công việc liên quan.

64 các công việc sau a) – EF(a))

3.2.2 Xác định thời gian công việc chi tiết

Bảng dưới đây liệt kê các đầu việc, trình tự thực hiện chi tiết và thời gian ước tính cho từng đầu việc từ ngày bắt đầu dự án 7/2/2022 đến ngày hoàn tất bàn giao 6/4/2022, với 6 tháng tiếp theo dành cho hỗ trợ.

Bảng phục vụ cho việc quản lý tiến độ công việc

Số mục Tên công việc Độ dài Thời gian bắt đầu

0 Tiến độ tổng dự án 61 days 07-02-22 08-04-22

Lên kế hoạch/ ý tưởng thiết kế ệ h thống

1.1 Gặp khách hàng và xác định yêu cầu 3 days 07-02-22 09-02-22 1

1.2 Xác định giá thành sản phẩm 2 days 10-02-22 11-02-22 2

1.3 Demo quy trình và giao diện 5 days 12-02-22 16-02-22 3,4,5

2 Kế hoạch qu n lýả 54 days 12-02-22 06-04-22

2.1 Quản lí phạm vi 5 days 12-02-22 16-02-22 3,4,5

Chi tiết kế hoạch quản lý (Ý tưởng, mục tiêu, yêu cầu)

2.1.3 Kế hoạch kiểm soát phạm vi 1 day 14-02-22 14-02-22 4

2.1.4 Xác định các bên liên quan, đối tác và họp 2 days 15-02-22 16-02-22 5

2.1.5 Xác định hình thức đầu tư, tổng vốn 2 days 15-02-22 16-02-22 5

2.2.1 Sơ đồ mạng AOA 4 hours 18-02-22 18-02-22 7

2.2.2 Lập và xác định đường găng

Lập kế hoạch thời gian chi tiết các công việc

2.2.5 Kiểm soát tiến độ 46 days 20-02-22 06-04-22 9, ,20

2.3 Quản lý chi phí 46 days 20-02-22 06-04-22 9, ,20

2.5 Quản lý chất lượng 46 days 20-02-22 06-04-22 9, ,20

2.6 Quản lý nhân lực 46 days 20-02-22 06-04-22 9, ,20

3 Kế hoạch phát tri n ể 44 days 16-02-22 31-03-22

3.1 Phân tích và thiết kế quy trình 2 days 16-02-22 17-02-22 6 3.2 Thiết kế giao diện 2 days 16-02-22 17-02-22 6 3.3 Thiết kế CSDL 4 days 20-02-22 23-02-22 9

3.4 Lập trình Back-End và Front-End

15 days 25-02-22 11-03-22 11 3.5 Tích hợp hệ thống 2 days 15-03-22 16-03-22 13

3.6 Vận hành hệ thống thực tế 9 days 23-03-22 31-03-22 16,17

3.6.1 Đồng bộ dữ liệu lên hệ thống 2 days 23-03-22 24-03-22 16

Trong kế hoạch kiểm thử kéo dài 27 ngày từ 24-02-22 đến 22-03-22, các hoạt động bao gồm: kiểm thử logic diễn ra trong 1 ngày (24-02-22), kiểm thử đơn vị kéo dài 3 ngày (12-03-22 đến 14-03-22), kiểm thử module cũng trong 3 ngày (12-03-22 đến 14-03-22), kiểm thử giao diện trong 3 ngày (12-03-22 đến 14-03-22), kiểm thử tích hợp kéo dài 2 ngày (17-03-22 đến 18-03-22) và cuối cùng là kiểm thử hệ thống trong 2 ngày (19-03-22 đến 20-03-22).

4.7 Điều chỉnh thay đổi 27 days

5 Kế hoạch chuyển giao 6 days 01-04-22 06-04-22 18,19,2

5.1 Bộ tài liệu quản lý, sử dụng hệ thống 1 day 01-04-22 01-04-22 18

5.2 Hướng dẫn người dùng hệ thống 3 days 02-04-22 04-04-22 19

5.3 Bản kết quả các đợt kiểm thử 1 day 01-04-22 01-04-22 18

Biên bản tài liệu điều chỉnh thay đổi trong quá trình triển khai

5.5 Bản quyết toán tài chính 2 days 05-04-22 06-04-22 20

Trong thời gian thực hiện dự án, nhóm dự án xác định các mốc thời gian quan trọng của dự án bao gồm các mốc thời gian như sau:

- Kết thúc lập trình hệ thống: 14/03/2022

- Chuyển giao xong trước ngày: 07/04/2022

Sơ đồ Gantt cung cấp cái nhìn rõ ràng về trạng thái dự án, giúp nhóm dễ dàng theo dõi và kiểm soát thông tin các công việc cần thực hiện Nó cho phép nhanh chóng phát hiện sự sai lệch và chậm trễ, từ đó đánh giá ảnh hưởng đến tiến độ của dự án Ngoài ra, sơ đồ Gantt còn hỗ trợ xác định thứ tự ưu tiên cho các công việc, nâng cao hiệu quả làm việc và đảm bảo không làm chậm tiến độ dự án Tính đến ngày 6/4/2022, tất cả các công việc đã hoàn thành 100% và chuyển sang giai đoạn hỗ trợ.

Qu n lý chi phí 68 ả 1 Các b ng giá d ch v 68ảịụ 2 B ảng lương nhân viên

Dưới đây là bảng giá dịch vụ sau khi khảo sát và thống nhất của nhóm dự án

STT Hạng mục Đơn giá Thành tiền

1 Thiết kế giao diện hệ thống 20.000.000 20.000.000

3 Đào tạo end-user 6.000.000/3 buổi 6.000.000

4 Support user/Vận hành 48.000.000/6 tháng 48.000.000

5 Chi trả phần mềm bản quyền hỗ trợ dự án

6 Chi phí mua phần mềm chỉ trả 1 lần

7 Chi trả giấy tờ, in ấn 300.000 -

Bảng 3.3.1 Bảng giá dịch vụ chi tiết

Tất cả các thành viên tham gia dự án đều được trả lương hàng tháng, thường dựa trên giai đoạn và tiến độ triển khai Bên cạnh đó, dự án còn có sự hỗ trợ từ nhân lực bên ngoài để đảm bảo quá trình triển khai diễn ra suôn sẻ.

STT Họ tên nhân viên Lương/Tháng Thưởng tiến độ Thưởng cuối dự án

1 Nguyễn Thị Minh 15.000.000 3.000.000/giai đoạn

2 Bùi Thị Hằng 13.000.000 2.000.000/giai đoạn 8% lợi nhuận dự án

3 Phạm Đức An 13.000.000 2.000.000/giai đoạn 8% lợi nhuận dự án

4 Nguyễn Trung Đức 13.000.000 2.000.000/giai đoạn 8% lợi nhuận dự án

Thúy 13.000.000 2.000.000/giai đoạn 8% lợi nhuận dự án

(Số lượng 3) 10.000.000 5% lợi nhuận dự án

Bảng 3.3.2 Bảng lương nhân viên

Chi ngân sách dựa trên hạng mục dự án, theo sơ đồ phân rã công việc WBS, được trình bày trong bảng dưới đây Bảng này hỗ trợ nhóm dự án trong việc quản lý ngân sách qua từng giai đoạn, giúp đo lường và tính toán hiệu suất chi phí một cách hiệu quả.

Bảng 3.3.3 Cơ sở chi phí

Tổng chi phí của dự án ước tính khoảng 800.000.000 VNĐ, trong khi ngân sách ban đầu được xác định là 900.000.000 VNĐ Do đó, lợi nhuận cuối cùng của dự án đạt 100.000.000 VNĐ.

Các giai đoạn phát sinh chi phí

Các khoản chi phí phát sinh Đơn giá Số lần Thành tiền % Ngân sách

Giai đoạn lên ý tưởng sản phẩm/

Thiết kế demo sản phẩm ban đầu

71 xăng xe đi lại cho việc trao đổi với khách hàng

Chi phí cho cuộc họp lên ý tưởng

Giai đoạn quản lý, phát triển và kiểm thử sản phẩm

Tạm ứng cho quản lý 10.000.000 1 10.000.000 1.11%

Hỗ trợ xăng xe đi lại cho việc trao đổi với khách hàng

Chi phí cho cuộc họp

Tại thời điểm báo cáo

Chi phí phát sinh khác

Bảng 3.3.4 Bảng giải ngân theo từng giai đoạn (từ ngày 07-22-2022 đến ngày 06-04-

Dự án sẽ tiếp tục giải ngân trong thời gian tiếp theo, theo đúng tiến độ của dự án

Dự án sẽ tiếp tục giải ngân trong 3 giai đoạn tiếp theo:

- Giai đoạn 06-03-2022 đến hết tháng 3 (31/03/2022)

- Giai đoạn hoàn thành bàn giao dự án (06/04/2022)

- Giai đoạn chuyển sang support từ 07/04 - 07/10/2022

Các giai đoạn phát sinh chi phí

Các khoản chi phí phát sinh Đơn giá Số lượng

Tiếp tục giai đoạn quản lý, phát triển và kiểm thử sản phẩm

Chi phí thiết kế giao diện 20.000.000 20.000.000 2,2%

Chi phí phát triển phần mềm

Tạm ứng cho quản lý 5.000.0000 1 5.000.000 0.56%

Chi phí cho cuộc họp 1.000.000 1 1.000.000 0.11%

Hỗ trợ xăng xe đi lại cho việc trao đổi

Hỗ trợ cho nhân viên triển khai

Chi phí họp báo cáo, nghiệm thu,

Hỗ trợ đi lại họp hành 1.000.000 4 4.000.000 0,4%

Chi phí in ấn tài liệu quản lý hệ thống 100.000đ 4 400.000 0,04%

Chi phí hỗ trợ nhân viên đào tạo cho người sử dụng

Sau khi giải ngân qua hai giai đoạn, giai đoạn 1 d án tự ừ ngày 07/02/2022 đến ngày 06/03/2022 gi i ngân x p xả ấ ỉ 16,22% ngân sách, giai đoạn 2 từ ngày 06/03/2022 đến 07/10/2022 gi i ngân x p x 72,26% ngân sách ả ấ ỉ

Trong quá trình giải ngân, đã phát sinh một số khoản phí khác và có một số sai sót Tổng cộng, dự án đã giải ngân khoảng 88,48% tổng ngân sách, tương đương với 797.100.000 VNĐ.

Như vậy, số tiền và thời gian giải ngân hoàn toàn nằm trong kế hoạch dự kiến và quản lý chi phí mà nhóm đã đề ra.

Qu n lý nhân l c 75 ả ự 1 L p k ho ch tậếạ ổ chứ c 75 2 Thu nh n nhân viên 79ậ

Sơ đồ tổ chức quản lý nhân sự dự án đã được trình bày tại mục 1.2.1.2

Việc lập kế hoạch tổ chức sẽ cho ta biết cần bao nhiêu nhân viên, về kỹ năng gì hay trong khoảng thời gian nào

- Ma trận phân công trách nhiệm (RACI)

Phát triển hệ thống quản lý quỹ tiền mặt của ngân hàng VIB

Lên kế hoạch/ ý tưởng thiết kế hệ thống 07-02-22 16-02-

Phân tích và thiết kế quy trình 16-02-22 17-02-

Lập trình Back-End và

Vận hành hệ thống thực tế 23-03-22 31-03-

22 A I I R R R R Đồng bộ dữ liệu lên hệ thống 23-03-22 24-03-

Bảng 3.4.1 Ma trận phân công trách nhiệm

Responsibility = Người chịu trách thực hiện

Accountability = Người sẽ chịu trách nhiệm phê duyệt các dự án, kế hoạch.

Consultation = Tham mưu, tư vấn

Informed = Người có thể không làm gì trong công việc đó nhưng cần nắm được thông tin

Trong ma trận RACI, việc theo dõi tần suất xuất hiện của chữ R là rất quan trọng Nếu chữ R xuất hiện quá nhiều hoặc quá ít, cần điều chỉnh để tránh tình trạng quá tải hoặc thiếu hụt công việc Bảng phân công trách nhiệm cần đảm bảo rằng mỗi đầu mục công việc có một người chịu trách nhiệm thực hiện (R) và không có công việc nào có hơn một người chịu trách nhiệm (A).

Việc thu nhận nhân sự có thể thực hiện qua nhiều phương thức, bao gồm việc sử dụng nhân sự từ các dự án trước hoặc tuyển dụng mới Đối với dự án này, các thành viên đều được tuyển chọn dựa trên khả năng và thế mạnh riêng của từng người Nhóm dự án hiện tại gồm 5 thành viên đã từng hợp tác trong các dự án trước đây, cùng với 3 thành viên được thuê ngoài.

STT Họ tên Vai trò Trách nhiệm

Nhân sự trong nhóm dự án

Chịu trách nhiệm dự án, chuyên viên phân tích nghiệp vụ

Hỗ trợ và tư vấn nghiệp vụ, giám sát dự án

2 Bùi Thị Hằng Chuyên viên phân tích nghiệp vụ, kiểm thử

Xây dựng các tài liệu đặc tả yêu cầu hệ thống, kiểm thử hệ thống

Thúy Chuyên viên kiểm thử Test hệ thống, hỗ trợ phân tích nghiệp vụ

4 Phạm Đức An Chuyên viên kiểm thử Thiết kế cơ sở dữ liệu, thiết kế giao diện

5 Nguyễn Trung Đức Chuyên viên lập trình Thiết kế cơ sở dữ liệu, thiết kế giao diện Nhân sự bên ngoài nhóm dự án

6 Lê Xuân Phương Chuyên viên vận hành hệ thống Tích hợp hệ thống, vận hành

7 Đỗ Văn Minh Chuyên viên quản lý chất lượng Đảm bảo đúng tiêu chuẩn, chất lượng hệ thống

8 Vũ Thị Ngọc Chuyên viên UI-UX Design giao diện hệ thống, bản prototype ban đầu

Nhóm thực hiện dự án theo phương pháp Agile Scrum tổ chức họp hàng ngày để đánh giá tiến độ công việc Qua các cuộc họp này, nhóm nhanh chóng giải quyết các vấn đề phát sinh, giúp hạn chế sai lệch trong quản lý thời gian ước tính và giảm thiểu rủi ro trong quá trình triển khai dự án.

Nhóm làm việc với đối tác VIB để thảo luận về các thay đổi yêu cầu và vấn đề phát sinh, đồng thời phối hợp với nhóm dự án tổng của hệ thống quản lý tiền mặt ngân hàng VIB Điều này giúp nắm bắt kịp thời các thay đổi liên quan đến dự án tổng, yêu cầu và công nghệ, từ đó điều chỉnh nhân sự phù hợp.

Trong quá trình làm việc, nhóm không chỉ tổ chức các cuộc họp để giải quyết từng phần công việc mà còn thực hiện các buổi trao đổi tài liệu và tự đào tạo nhằm nâng cao kiến thức và năng lực cho các thành viên Những kiến thức được chia sẻ chủ yếu liên quan đến phân tích nghiệp vụ, giúp cải thiện hiệu quả làm việc của nhóm.

Nhóm không chỉ tập trung vào các hoạt động chuyên môn mà còn tổ chức các buổi chia sẻ và trò chuyện để tăng cường sự hiểu biết và gắn kết giữa các thành viên Điều này là cần thiết để nâng cao hiệu quả làm việc nhóm Trong các buổi trao đổi, nhóm trưởng sẽ quan sát và đưa ra nhận định về tính cách và năng lực của từng thành viên, từ đó phân công công việc phù hợp, góp phần nâng cao hiệu suất công việc chung.

3.4.4 Qu n lý nhóm dả ự án

Quá trình thực thi dự án của nhóm đòi hỏi sự quản lý hiệu quả, bởi vì người quản lý cần phải tạo ảnh hưởng tích cực đến tất cả các thành viên trong nhóm.

Bà Nguyễn Thị Minh là người quản lý dự án, chịu trách nhiệm điều phối trực tiếp cho dự án tổng "Quản lý quỹ tiền mặt của ngân hàng VIB" Bà cũng đảm nhận việc điều phối nhân sự, bao gồm các thành viên thực hiện các nhiệm vụ công việc và những người có trách nhiệm phê duyệt các vấn đề trong module con "Quản lý tiền mặt VIB".

Nhân sự triển khai hệ thống cho dự án gồm các thành viên đã hợp tác qua ba dự án trước đó, giúp họ hiểu và dễ dàng làm việc cùng nhau Với kinh nghiệm từ các dự án chuyên ngành ngân hàng, đặc biệt là các mô-đun về ví điện tử và hệ thống core, đội ngũ này đã sẵn sàng để thực hiện dự án mới một cách hiệu quả.

Qu n lý ch ả ất lượng

Quản lý chất lượng dự án là đảm bảo rằng dự án sẽ đáp ứng các nhu cầu mà nó được cam kết

Quy trình quản lý chất lượng dự án bao gồm:

- Lập kế hoạch chất lượng: xác định những tiêu chuẩn chất lượng có liên quan đến dự án và làm thế nào để đáp ứng chúng

Để đảm bảo chất lượng dự án, cần thực hiện đánh giá hiệu suất tổng thể định kỳ nhằm xác định rằng dự án đáp ứng các tiêu chuẩn chất lượng liên quan.

- Kiểm soát chất lượng: kết quả giám sát dự án cụ thể để đảm bảo rằng họ tuân thủ các tiêu chuẩn chất lượng có liên quan

3.5.1 L p k ho ch chậ ế ạ ất lượng

Lập kế hoạch chất lượng là khả năng dự đoán tình huống và chuẩn bị hành động để mang lại kết quả mong muốn

Người quản lý dự án Bà Nguyễn Thị Minh chịu trách nhiệm cuối cùng cho việc quản lý chất lượng dự án

3.5.1.1 L p k ho ch qu n lý ậ ế ạ ả Để đảm bảo được chất lượng dự án, nhóm lập kế hoạch quản lý chất lượng của dự án bao gồm:

Để đảm bảo thành công cho dự án, việc xác định đầy đủ các yêu cầu, tiêu chuẩn ẩn và quy định về chất lượng là rất quan trọng trong giai đoạn phân tích và xác định yêu cầu.

Để đảm bảo tuân thủ các yêu cầu của dự án, cần xây dựng các phương án và kế hoạch giám sát, kiểm tra, kiểm soát bao gồm quản lý thời gian, quản lý nhân lực và phạm vi dự án Những biện pháp này sẽ giúp ngăn chặn và giảm thiểu sai sót có thể xảy ra trong quá trình thực hiện.

Quy trình thực hiện dự án cần đảm bảo tính phù hợp và sản phẩm bàn giao phải đạt yêu cầu chất lượng Trong giai đoạn lập kế hoạch quản lý, việc xác định các tiêu chuẩn và thước đo hệ thống là rất quan trọng để đảm bảo sự thành công của dự án.

- Tính khả dụng của giao diện: Đảm bảo giao diện được thiết kế bắt mắt, thân thiện với người dùng, đầy đủ các chức năng và dễ sử dụng

+ Giao diện đơn giản, dễ chịu, làm quen nhanh, thao tác được các task cơ bản ngay lần đầu sử dụng

+ Người dùng cảm nhận được mức độ nhanh chóng, thuận tiện khi sử dụng hệ thống

+ Người dùng sử dụng thành thạo, vẫn dễ dàng sử dụng lại được sau một thời gian không dùng

Đảm bảo tính toàn vẹn của dữ liệu là yếu tố quan trọng, giúp dữ liệu luôn đồng bộ, chính xác và không bị thay đổi hay mất mát trong quá trình xử lý giao dịch Ngoài ra, dữ liệu cũng cần được bảo vệ để duy trì sự toàn vẹn khi người dùng truy cập và cập nhật thông tin.

Đảm bảo tính an toàn bảo mật là ưu tiên hàng đầu, đặc biệt là trong việc bảo vệ dữ liệu và ngăn chặn các cuộc tấn công thông thường.

Để đảm bảo an toàn cho ứng dụng và máy chủ phía đầu VIB, cần sử dụng các framework và plugin mới nhất, đảm bảo rằng các thành phần này không chứa lỗ hổng bảo mật nguy hiểm Ngoài ra, máy chủ cũng cần được cài đặt giải pháp chống virus của VIB để bảo vệ tối ưu.

+ Giải pháp cần được đánh giá bảo mật cho ứng dụng, OS, cấu hình trước khi đưa vào vận hành

Để đảm bảo tính bảo mật chung của hệ thống khi người dùng đăng nhập, giải pháp cần cung cấp thông tin chi tiết về chính sách mật khẩu và cơ chế xác thực, bao gồm tài khoản và mật khẩu.

+ Độ phức tạp của mật khẩu: ít nhất 8 ký tự, kết hợp số, ký tự, ký tự đặc biệt; + Mật khẩu thay đổi định kỳ

+ Cơ chế password history: không sử dụng lại mật khẩu cũ

Tài khoản sẽ bị khóa sau 5 lần đăng nhập không thành công, với thời gian khóa là 15 phút Người dùng cần phải đổi mật khẩu trong lần đăng nhập đầu tiên, tuy nhiên, nếu giải pháp tích hợp với hệ thống AD của VIB, yêu cầu này sẽ không được áp dụng.

Hệ thống cần được cấu trúc thành các module riêng biệt theo chức năng, cho phép tích hợp dễ dàng Đảm bảo hệ thống hoạt động ổn định, không gặp lỗi khi có thay đổi Chương trình phải gọn nhẹ, ổn định và tương thích với nhiều nền tảng hệ điều hành khác nhau Việc bảo trì và sửa đổi hệ thống cũng cần được thực hiện một cách dễ dàng.

3.5.1.2 L p k ho ch kiậ ế ạ ểm thử

Kế hoạch kiểm thử bao gồm:

- Kiểm thử logic: kiểm thử logic hệ thống gồm mã nguồn, mô hình thiết kế

Kiểm thử đơn vị là quá trình kiểm tra từng thành phần nhỏ nhất trong phần mềm như hàm, thủ tục, hoặc lớp, nhằm giảm thiểu chi phí sửa lỗi sau này Để thực hiện kiểm thử hiệu quả, cần chuẩn bị trước các test case hoặc script, xác định rõ dữ liệu đầu vào, các bước thực hiện và dữ liệu mong đợi đầu ra Việc cô lập đoạn code và thực hiện kiểm thử giúp đảm bảo chất lượng phần mềm.

Kiểm thử Module là quá trình đảm bảo các chức năng nhỏ của hệ thống hoạt động hiệu quả, giúp việc gỡ lỗi chương trình trở nên dễ dàng hơn Nó cũng tạo điều kiện cho việc kiểm thử đồng thời bởi nhiều người, nâng cao tính hiệu quả trong phát triển phần mềm.

- Kiểm thử giao diện: Đảm bảo đúng yêu cầu của thiết kế, các trường thông tin, nút chức năng, được đặt trên giao diện phù hợp

Kiểm thử tích hợp là quá trình quan trọng nhằm đảm bảo không xảy ra mất mát dữ liệu và xung đột giữa các module Trong quá trình tích hợp, nếu không đạt được tính năng mong muốn, cần tiến hành tích hợp từng chức năng nhỏ đã hoàn thành, sau đó thực hiện kiểm thử Nếu các chức năng này đạt yêu cầu, có thể tiếp tục tích hợp để tránh gây ra xung đột lớn cho hệ thống.

Kiểm thử hệ thống là giai đoạn quan trọng nhằm đảm bảo tính toàn vẹn của dữ liệu, đáp ứng đầy đủ các tính năng, có giao diện chuẩn và hoạt động mượt mà Đây là bước kiểm thử cuối cùng trước khi hệ thống được đưa vào hoạt động.

Nhóm th c hi n ph i h p nhu n nhuyự ệ ố ợ ầ ễn các hành động qu n lý chả ất lượng bao gồm Testing, Review, Audit

- Đối v i hoớ ạt động “Review”, nhóm liên tục c p nh t checklist review, chia nh công ậ ậ ỏ việc, review sớm theo nhóm ho c h p review ặ ọ

Trong hoạt động "Testing", lập trình viên sẽ thực hiện Unit Test, kiểm tra kỹ lưỡng thiết kế testcase và dữ liệu test Họ cũng sẽ xem xét bộ dữ liệu được sử dụng để thực hiện kiểm thử.

Qu ản lý rủ i ro

3.6.1 Xác định danh mụ ủc ri ro và xác định mức độ rủi ro

Với dự án “Quản lý ti n mề ặ ủt ca ngân hàng VIB”, nhóm chọn phân loạ ủi ro g m nhi r ồ ững loại sau:

- Rủi ro biết được: được phát hiện sau khi đánh giá cẩn th n k ho ch d án, môi ậ ế ạ ự trường kinh doanh và kỹ thuật

- Rủi ro d ự đoán được: được ngo i suy t kinh nghi m c a các d ạ ừ ệ ủ ự án trước (VD: luân chuyển nhân s ) ự

- Rủi ro không đoán được: là một phần r i ro r t nh có th xủ ấ ỏ ể ảy ra nhưng rất khó để xác định trước

STT Thành phần rủi ro Tỷ l x y ra ệ ả Khả năng xảy ra Rủi ro biết được

Nhân sự mới tham gia vào dự án không làm được việc, làm sai, chậm tiến độ dự án

2 Mục đích và yêu cầu của khách hàng chưa xác định rõ 86% Rất cao

3 Phân tích và thiết kế dự án chưa đầy đủ 60 - 65% Cao

4 Dự án chậm tiến độ 31 - 35% Trung bình

5 Tính toán sai về chi phí ngân sách 35 - 40% Trung bình

Phối hợp giữa các thành viên không khớp (Dev không hiểu ý của Test,

Test không hiểu ý của BA)

7 Thiếu kinh nghiệm trong việc xử lý 34 - 36% Trung bình

8 Nhân sự không hợp tác thực hiện dự án 10 - 11% Rất thấp

9 Điều kiện làm việc của nhân sự dự án 45 - 50% Trung bình

10 Điều chuyển nhân sự 15 -18% Thấp

1 Thay đổi về nhu cầu của khách hàng 75 - 80% Rất cao

Nhân sự mới tham gia vào dự án không làm được việc, làm sai, chậm tiến độ dự án 62 - 66% Cao

3 Khách hàng khó khăn trong phê duyệt hệ thống 45 - 50% Trung bình

4 Giải ngân chậm 35 - 40% Trung bình

5 Ước lượng sai về nhân sự 12 - 17% Thấp

Rủi ro không đoán được

1 Nhân sự chủchốt rời khỏi dựán 1 - 3% Rất thấp

2 Khách hàng hủy hợp đồng 0 - 0,5% Không

3 Cắt giảm ngân sách b t ng ấ ờ 1 - 2% Rất thấp

Bảng 3.6.1.1 Danh mục rủi ro tiêu cực

Nhóm đánh giá rủi ro sử dụng hai tiêu chí chính: mức độ ảnh hưởng và khả năng xảy ra Mức độ ảnh hưởng được phân loại thành các cấp độ từ "rất cao" đến "không", trong khi khả năng xảy ra được chia thành các tỷ lệ phần trăm tương ứng từ ">70%" đến "

Tiêu đề	Xây Dựng Hệ Thống Quản Lý Tiền Mặt Của Ngân Hàng VIB
Tác giả	Nguyễn Thị Minh, Bùi Thị Hằng, Nguyễn Thị Thu Thúy, Phạm Đức An, Nguyễn Trung Đức
Người hướng dẫn	TS. Đinh Trọng Hiếu
Trường học	Học viện Ngân hàng
Thể loại	báo cáo cuối kỳ
Năm xuất bản	2022
Thành phố	Hà Nội

Định dạng
Số trang	120
Dung lượng	12,25 MB