Bối cảnh và vấn đề nghiên cứu

Bối cảnh thực tiễn và lý do thực hiện đề tài

Dự án Phân tích Nghiệp vụ (Business Analysis) mang tên Sáng kiến Nâng cấp Ngân hàng Số (Digital Banking Enhancement Initiative) do Diwakar Singh xây dựng (với báo cáo đánh giá nhu cầu do Chuyên viên Phân tích Nghiệp vụ Radhika Joshi lập) tập trung vào lĩnh vực ngân hàng bán lẻ (retail banking). Trong bối cảnh ngành dịch vụ tài chính phát triển nhanh chóng, các ngân hàng đối mặt với áp lực cạnh tranh gay gắt và sự thay đổi trong kỳ vọng của khách hàng đối với các nền tảng trực tuyến.

Hiện trạng của hệ thống ngân hàng số đang sử dụng bộc lộ nhiều hạn chế (AS-IS State):

  • Các giải pháp ngân hàng số còn phân mảnh, tính năng trên ứng dụng di động bị giới hạn.
  • Trải nghiệm người dùng không đồng nhất giữa các nền tảng kỹ thuật số khác nhau của ngân hàng.
  • Khối lượng cuộc gọi khiếu nại và yêu cầu hỗ trợ gửi đến bộ phận dịch vụ khách hàng (Customer Service Department) ở mức cao do người dùng gặp lỗi giao dịch và vướng mắc trong tra cứu thông tin.
  • Hệ thống bảo mật còn ở mức cơ bản, chủ yếu dựa trên mật khẩu đơn lớp; hiệu năng máy chủ bị suy giảm và xảy ra tình trạng gián đoạn hoạt động (downtime) vào các khung giờ cao điểm.

Mục đích của dự án là chuyển đổi sang trạng thái mục tiêu (TO-BE State), xây dựng một ứng dụng ngân hàng số tích hợp toàn diện, cung cấp giao diện trực quan, đồng nhất, giao dịch thời gian thực (real-time), tính năng bảo mật nâng cao và các công cụ quản lý tài chính cá nhân hóa nhằm nâng cao mức độ hài lòng và tỷ lệ giữ chân khách hàng.

Mục tiêu và nhiệm vụ nghiên cứu

Đề tài xác định các mục tiêu và nhiệm vụ phân tích cụ thể bao gồm:

  1. Đánh giá hiệu năng và các tính năng của nền tảng ứng dụng ngân hàng số hiện tại.
  2. Nhận diện các khoảng trống về tính năng, trải nghiệm người dùng và hiệu quả vận hành thông qua thu thập dữ liệu từ các bên liên quan.
  3. Phân tích nguyên nhân gốc rễ (Root Cause Analysis) của các sự cố kỹ thuật trọng yếu như độ trễ thông báo giao dịch.
  4. Xây dựng tài liệu phạm vi dự án (Project Scope Document), ma trận phân định trách nhiệm (RACI Matrix) và kế hoạch tương tác các bên liên quan (Stakeholder Engagement Plan).
  5. Thiết lập mô hình yêu cầu (sơ đồ ngữ cảnh, phân rã chức năng, ca sử dụng, biểu đồ tuần tự, mô hình dữ liệu quan hệ) và soạn thảo Tài liệu Đặc tả Yêu cầu Phần mềm (Software Requirements Specification - SRS) theo chuẩn IEEE.

Đối tượng và phạm vi nghiên cứu

  • Đối tượng nghiên cứu: Quy trình nghiệp vụ ngân hàng bán lẻ, luồng tương tác người dùng, các yêu cầu chức năng (Functional Requirements), yêu cầu phi chức năng (Non-Functional Requirements) và cấu trúc dữ liệu của ứng dụng ngân hàng số.
  • Phạm vi trong dự án (In-Scope):
    • Phát triển tính năng đăng ký, xác thực bảo mật đa yếu tố (Multi-Factor Authentication - MFA).
    • Quản lý tài khoản và tích hợp theo dõi số dư, lịch sử giao dịch theo thời gian thực.
    • Xử lý giao dịch chuyển khoản, thanh toán hóa đơn và nạp tiền gửi qua di động (mobile check deposit).
    • Cung cấp thông tin chi tiêu cá nhân hóa và các công cụ tài chính tương tác.
    • Tối ưu hóa hiệu năng máy chủ và thiết kế giao diện thích ứng (responsive UI design).
  • Phạm vi ngoài dự án (Out-of-Scope):
    • Đại tu toàn bộ hệ thống ngân hàng lõi (Core Banking System).
    • Tích hợp trực tiếp với các nền tảng dịch vụ đầu tư bên ngoài (Investment Services Integration).
    • Tích hợp với các công cụ quản lý tài chính và lập kế hoạch ngân sách của bên thứ ba (Third-Party Financial Management Tools).
    • Thay thế hệ thống quản trị quan hệ khách hàng (CRM) hiện hành.

Cơ sở lý thuyết và phương pháp

Khung lý thuyết và tiêu chuẩn phân tích nghiệp vụ

Đề tài vận dụng các phương pháp và chuẩn mực chuyên môn trong phân tích nghiệp vụ phần mềm:

  • Chuẩn đặc tả IEEE SRS: Định dạng cấu trúc tài liệu đặc tả yêu cầu phần mềm theo tiêu chuẩn ngành.
  • Mô hình hóa nghiệp vụ: Sử dụng Sơ đồ ngữ cảnh (Context Diagram), Phân rã chức năng (Functional Decomposition), Phân tích ca sử dụng (Use Case Analysis), Biểu đồ tuần tự (Sequence Diagram) và Sơ đồ quan hệ thực thể (ER Diagram).
  • Phân tích khoảng cách (Gap Analysis): Đối chiếu chi tiết giữa hiện trạng (AS-IS) và trạng thái tương lai (TO-BE) trên các khía cạnh xác thực, xử lý giao dịch, hiệu năng, giao diện, bảo mật dữ liệu, hỗ trợ khách hàng và báo cáo.
  • Phân tích nguyên nhân gốc rễ (Root Cause Analysis - RCA): Truy vết các lớp nguyên nhân từ hiện tượng bề mặt đến vấn đề kỹ thuật tại tầng API và cơ sở dữ liệu.
  • Ma trận phân công trách nhiệm (RACI Matrix): Phân định vai trò Trách nhiệm thực hiện (Responsible), Trách nhiệm giải trình (Accountable), Tham vấn (Consulted) và Nhận thông tin (Informed).

Phương pháp thu thập và xử lý dữ liệu

Tác giả đã triển khai bốn phương pháp thu thập dữ liệu trong giai đoạn đánh giá nhu cầu (Needs Assessment):

  • Khảo sát qua bảng hỏi (Surveys and Questionnaires): Thực hiện khảo sát trực tuyến tập trung vào mức độ hài lòng của khách hàng đối với các tính năng hiện hữu của ứng dụng ngân hàng số.
  • Phỏng vấn (Interviews): Phỏng vấn sâu các bên liên quan nội bộ (đại diện bộ phận dịch vụ khách hàng, nhân sự IT, phòng marketing) và các bên ngoài (người dùng cuối, chuyên gia trong ngành tài chính).
  • Quan sát (Observation): Phân tích dữ liệu tương tác người dùng, tỷ lệ thoát trang (bounce rates) tại màn hình đăng nhập và tần suất truy cập các mục giải đáp sự cố.
  • Rà soát tài liệu (Document Review): Đánh giá báo cáo kết quả các dự án trước, dữ liệu phản hồi tổng hợp và nhật ký hỗ trợ kỹ thuật (support logs).

Tiêu chuẩn và quy định tuân thủ

  • Tuân thủ các quy định bảo vệ dữ liệu và quyền riêng tư: Quy định chung về bảo vệ dữ liệu của Liên minh Châu Âu (GDPR) và Đạo luật về quyền riêng tư của người tiêu dùng California (CCPA).
  • Chuẩn tiếp cận nội dung web: WCAG 2.1.
  • Đảm bảo tính toàn vẹn giao dịch dữ liệu theo tiêu chuẩn ACID (Nguyên tử, Nhất quán, Cô lập, Bền vững).

Nội dung chính theo từng chương

Phần 1: Báo cáo Đánh giá Nhu cầu (Needs Assessment Report)

Báo cáo do Chuyên viên Phân tích Nghiệp vụ Radhika Joshi lập, tổng hợp kết quả điều tra thực nghiệm và phân định thứ tự ưu tiên cho dự án:

Hạng mục dữ liệu Tỷ lệ / Phát hiện chính
Đánh giá giao diện người dùng 70% người dùng khảo sát phản hồi giao diện không trực quan (đặc biệt là khách hàng lớn tuổi).
Nhu cầu tính năng mới 65% khách hàng mong muốn bổ sung tính năng gửi séc qua di động (mobile check deposit).
So sánh với đối thủ cạnh tranh 60% đánh giá dịch vụ của ngân hàng kém hơn đối thủ về tính năng cá nhân hóa và công cụ tương tác.
Dữ liệu quan sát hành vi Tỷ lệ thoát (bounce rate) cao tại trang đăng nhập; tần suất truy cập cao vào mục hỏi đáp (FAQ) xử lý lỗi giao dịch.
Nhật ký kỹ thuật (Support logs) Tồn tại lỗi giao dịch thất bại lặp lại và sự chậm trễ trong cập nhật số dư tài khoản.

Dựa trên dữ liệu thực nghiệm, nhu cầu được phân cấp theo ba mức ưu tiên:

  1. Ưu tiên cao (High Priority): Cải tiến giao diện người dùng (UI) và tối ưu hóa hiệu năng hệ thống nhằm trực tiếp nâng cao tỷ lệ giữ chân khách hàng.
  2. Ưu tiên trung bình (Medium Priority): Bổ sung tính năng gửi séc qua thiết bị di động và thông báo giao dịch theo thời gian thực.
  3. Ưu tiên thấp (Lower Priority): Xây dựng các thuật toán cá nhân hóa chuyên sâu dựa trên thói quen chi tiêu.

Phần 2: Quản trị Phạm vi và Kế hoạch Tương tác Các bên Liên quan

Đồ án thiết lập kế hoạch phân tích và ma trận quản trị các bên liên quan dựa trên mức độ ảnh hưởng (Influence) và mức độ quan tâm (Interest):

Nhóm bên liên quan Phân loại Ảnh hưởng & Quan tâm Chiến lược tương tác Phương thức giao tiếp
Ban quản lý Ngân hàng Bán lẻ Ảnh hưởng cao / Quan tâm cao Tham gia chặt chẽ (Engage Closely) Họp định kỳ, báo cáo chiến lược
Đội ngũ Phát triển IT Ảnh hưởng cao / Quan tâm cao Tham gia chặt chẽ (Engage Closely) Hội thảo kỹ thuật, họp Stand-up hàng ngày
Cổ đông (Shareholders) Ảnh hưởng cao / Quan tâm thấp Cung cấp thông tin (Keep Informed) Báo cáo tài chính quý, đại hội thường niên
Pháp chế & Tuân thủ (Compliance) Ảnh hưởng cao / Quan tâm thấp Tham gia chặt chẽ (Engage Closely) Họp rà soát tuân thủ định kỳ
Khách hàng (Customers) Ảnh hưởng thấp / Quan tâm cao Lấy ý kiến phản hồi (Gather Feedback) Khảo sát trực tuyến, biểu mẫu phản hồi
Bộ phận Dịch vụ Khách hàng Ảnh hưởng thấp / Quan tâm cao Tham vấn thường xuyên (Consult Regularly) Họp giao ban tuần, báo cáo sự cố
Đội ngũ Marketing Ảnh hưởng thấp / Quan tâm thấp Cung cấp thông tin (Keep Informed) Cập nhật qua email, họp tháng
Nhà cung cấp bên thứ ba Ảnh hưởng thấp / Quan tâm thấp Cung cấp thông tin (Keep Informed) Đánh giá định kỳ, hợp đồng cung ứng

Bên cạnh đó, đề tài xây dựng ma trận RACI chi tiết cho các đầu việc: Thu thập yêu cầu, Thiết kế giải pháp, Phát triển, Kiểm thử, Triển khai, Đào tạo & Tài liệu hóa, Kiểm tra tuân thủ, và Thu thập phản hồi.

Phần 3: Phân tích Khoảng cách (Gap Analysis) và Nguyên nhân Gốc rễ (Root Cause Analysis)

Tài liệu thực hiện đối chiếu khoảng cách trên 7 lĩnh vực trọng yếu:

Lĩnh vực Hiện trạng (AS-IS) Trạng thái tương lai (TO-BE) Giải pháp thu hẹp khoảng cách
Xác thực người dùng Xác thực mật khẩu cơ bản. Bảo mật nâng cao với MFA và sinh trắc học. Triển khai MFA, cập nhật chính sách bảo mật, đào tạo kỹ thuật.
Xử lý giao dịch Giao dịch cơ bản, không xử lý tức thời. Xử lý giao dịch và cảnh báo thời gian thực. Nâng cấp backend, tích hợp cổng thanh toán hiện đại, gửi thông báo tức thì.
Hiệu năng hệ thống Gián đoạn hoạt động khi lượng truy cập cao. Khả năng sẵn sàng cao, đảm bảo thời gian hoạt động 99,9%. Ứng dụng điện toán đám mây tự co giãn, cân bằng tải, kiểm thử chịu tải.
Giao diện người dùng Lỗi thời, không tối ưu cho mọi thiết bị. Giao diện hiện đại, trực quan, thiết kế thích ứng (responsive). Thiết kế lại UI/UX, áp dụng chuẩn responsive, kiểm thử người dùng lặp lại.
Bảo mật & Tuân thủ Tuân thủ luật bảo vệ dữ liệu ở mức cơ bản. Tuân thủ toàn diện GDPR, CCPA và các quy định ngành. Rà soát chính sách bảo mật, mã hóa dữ liệu, đào tạo nhân viên.
Hỗ trợ khách hàng Kênh hỗ trợ hạn chế, quá tải cuộc gọi. Đa dạng hóa kênh hỗ trợ: AI Chatbot, cổng tự phục vụ. Tích hợp AI Chatbot, mở rộng tính năng tự phục vụ trong app.
Báo cáo & Phân tích Báo cáo cơ bản, thông tin hạn chế. Công cụ phân tích dự báo và báo cáo nâng cao. Tích hợp công cụ phân tích BI, thiết lập báo cáo tùy chỉnh.

Trong phân tích nguyên nhân gốc rễ (RCA) đối với sự cố chậm trễ thông báo giao dịch (Delay in Transaction Notifications), tác giả đã bóc tách dữ liệu kỹ thuật:

  • Phân tích nhật ký API cho thấy thời gian phản hồi tăng đột biến trong giờ cao điểm, thường xuyên gặp lỗi 504 Gateway Timeout.
  • Nguyên nhân kỹ thuật bắt nguồn từ việc cơ sở dữ liệu bị thắt nút cổ chai: câu lệnh SQL chưa tối ưu, thiếu chỉ mục (indexing), máy chủ thiếu tài nguyên CPU/RAM và kiến trúc chưa hỗ trợ mở rộng linh hoạt.

Phần 4: Đặc tả Yêu cầu Nghiệp vụ và Ca sử dụng

Tài liệu SRS và User Stories định nghĩa các luồng nghiệp vụ cốt lõi:

  • Đăng ký tài khoản (UC101 / US1): Xác thực tính duy nhất của email, gửi liên kết kích hoạt, kích hoạt đăng nhập tự động sau đăng ký thành công.
  • Đăng nhập an toàn (UC102 / US2): Xác thực thông tin đăng nhập, kích hoạt MFA khi phát hiện thiết bị mới, khóa tài khoản 30 phút nếu nhập sai quá 3 lần liên tiếp.
  • Truy vấn số dư tài khoản (US3): Hiển thị số dư tức thời, phân định số dư khả dụng và số dư thực tế, cho phép xem chi tiết lịch sử giao dịch.
  • Chuyển tiền (UC103 / US4): Kiểm tra số dư khả dụng trước khi xử lý, hỗ trợ đặt lịch chuyển tiền trong tương lai, cập nhật đồng thời số dư hai tài khoản và hoàn tất giao dịch dưới 5 giây.
  • Thanh toán hóa đơn (US5): Quản lý danh bạ đơn vị thụ hưởng (billers), lưu lịch sử thanh toán, thiết lập thanh toán tự động định kỳ và gửi thông báo nhắc nợ.

Thiết kế và triển khai

Mô hình hóa yêu cầu và luồng xử lý

  • Sơ đồ phân rã chức năng (Functional Decomposition): Chia nhỏ hệ thống thành Quản lý tài khoản (Account Management), Quản lý giao dịch (Transaction Management) và Quản lý người dùng (User Management).
  • Luồng biểu đồ tuần tự cho tính năng Chuyển tiền (Sequence Diagram):
    1. Khách hàng (Customer) chọn tính năng chuyển tiền trên giao diện người dùng (UI Component).
    2. UI yêu cầu Logic nghiệp vụ (Business Logic) hiển thị biểu mẫu.
    3. Khách hàng nhập thông tin tài khoản đích và số tiền rồi gửi yêu cầu.
    4. Business Logic gửi truy vấn kiểm tra và xác thực tài khoản tới Cơ sở dữ liệu giao dịch (Transaction Database).
    5. Transaction Database phản hồi trạng thái hợp lệ của tài khoản và số dư.
    6. Business Logic thực thi giao dịch ghi nợ/ghi có trong CSDL và nhận thông báo kết quả.
    7. UI Component tiếp nhận kết quả từ Business Logic và hiển thị màn hình xác nhận giao dịch thành công cho khách hàng.

Thiết kế cấu trúc cơ sở dữ liệu

Hệ thống sử dụng cơ sở dữ liệu quan hệ SQL gồm 9 bảng dữ liệu được chuẩn hóa:

Tên bảng CSDL Khóa chính / Khóa ngoại Các trường dữ liệu chính và kiểu dữ liệu
Users user_id (PK) username (VARCHAR 255), password_hash (VARCHAR 255), email (VARCHAR 255), phone_number (VARCHAR 20), full_name (VARCHAR 255), address (VARCHAR 255), role (ENUM: 'customer', 'employee'), registration_date (DATETIME), status (ENUM: 'active', 'locked').
Accounts account_id (PK)
user_id (FK)
account_type (ENUM: 'savings', 'checking', 'loan', 'credit'), balance (DECIMAL 15,2), created_date (DATETIME), status (ENUM: 'active', 'closed').
Transactions transaction_id (PK)
from_account_id (FK)
to_account_id (FK)
amount (DECIMAL 15,2), transaction_type (ENUM: 'deposit', 'withdrawal', 'transfer', 'payment'), transaction_date (DATETIME), status (ENUM: 'pending', 'completed', 'failed'), memo (VARCHAR 255).
Login_Attempts attempt_id (PK)
user_id (FK)
attempt_time (DATETIME), ip_address (VARCHAR 50), result (ENUM: 'success', 'failure').
Notifications notification_id (PK)
user_id (FK)
message (TEXT), notification_type (ENUM: 'transaction', 'security', 'general'), notification_date (DATETIME), status (ENUM: 'sent', 'read').
Billers biller_id (PK)
user_id (FK)
biller_name (VARCHAR 255), account_number (VARCHAR 50), created_date (DATETIME), last_payment_date (DATETIME), recurring (BOOLEAN).
Payments payment_id (PK)
user_id (FK)
biller_id (FK)
amount (DECIMAL 15,2), payment_date (DATETIME), status (ENUM: 'pending', 'completed', 'failed').
Multi-Factor Authentication (MFA) mfa_id (PK)
user_id (FK)
mfa_type (ENUM: 'email', 'sms', 'app'), mfa_status (ENUM: 'enabled', 'disabled'), setup_date (DATETIME).
Audit Logs audit_id (PK)
user_id (FK)
event_type (VARCHAR 255), event_description (TEXT), event_time (DATETIME).

Quan hệ cấu trúc: Bảng Users có quan hệ 1-Nhiều (1:N) với Accounts, Transactions, Login_Attempts, Notifications, Payments và Billers. Bảng Accounts có quan hệ 1:N với Transactions. Bảng Billers có quan hệ 1:N với Payments.

Chỉ số phi chức năng và kiến trúc kỹ thuật

  • Thời gian phản hồi (Response Time): Dưới 2 giây đối với các thao tác ứng dụng; thời gian tải trang web dưới 3 giây; thời gian xử lý giao dịch chuyển tiền không vượt quá 5 giây.
  • Độ sẵn sàng (Availability): Đạt mức 99,9% kèm cơ chế dự phòng sự cố (failover capabilities).
  • Khả năng mở rộng (Scalability): Đáp ứng mức tăng trưởng dự kiến 50% lượng người dùng trong 5 năm tiếp theo.
  • Bảo mật & Tích hợp: Mã hóa toàn diện dữ liệu lưu trữ (at rest) và dữ liệu truyền tải (in transit) qua giao thức HTTPS; tích hợp xác thực API qua OAuth; áp dụng quy trình CI/CD và chiến lược triển khai Blue-Green để giảm thiểu thời gian gián đoạn hệ thống.

Kết quả và đóng góp

Kết quả chính của nghiên cứu

  1. Xác lập căn cứ định lượng về sự không hài lòng của người dùng: Dữ liệu điều tra xác định chính xác 70% người dùng đánh giá giao diện khó thao tác, 65% có nhu cầu nạp séc di động và 60% đánh giá thấp tính năng cá nhân hóa so với đối thủ.
  2. Tìm ra nguyên nhân cốt lõi của lỗi hệ thống: Xác định lỗi chậm thông báo giao dịch bắt nguồn từ việc thiếu chỉ mục trong CSDL và tài nguyên máy chủ không đủ tải trong khung giờ cao điểm (lỗi 504 Gateway Timeout), từ đó đưa ra giải pháp tối ưu câu lệnh SQL, bổ sung bộ nhớ đệm (caching) và cơ chế mở rộng tự động (auto-scaling).
  3. Hoàn thiện bộ hồ sơ phân tích nghiệp vụ chuẩn mực: Đồ án cung cấp đầy đủ các tài liệu kỹ thuật từ Đánh giá nhu cầu, Khảo sát phạm vi, Kế hoạch tương tác các bên liên quan, Báo cáo phân tích khoảng cách đến Tài liệu đặc tả yêu cầu phần mềm IEEE SRS và mô hình CSDL chi tiết.

Đóng góp thực tiễn của đồ án

  • Xây dựng lộ trình cải tiến kỹ thuật số có tính phân cấp rõ ràng theo mức độ tác động và tính khả thi kỹ thuật: tập trung xử lý ngay giao diện và hạ tầng máy chủ trong ngắn hạn, bổ sung tính năng giao dịch trong trung hạn và tích hợp thuật toán cá nhân hóa dữ liệu tài chính trong dài hạn.
  • Cung cấp mô hình phân định trách nhiệm RACI và kế hoạch tương tác 8 nhóm bên liên quan, giúp đảm bảo tính đồng thuận giữa các bộ phận kỹ thuật, nghiệp vụ, pháp chế và người dùng cuối trong các dự án chuyển đổi số ngành ngân hàng.

Hạn chế và hướng nghiên cứu tiếp

Hạn chế của đồ án

  • Giả định về phía người dùng: Đồ án dựa trên giả định rằng mọi khách hàng đều sở hữu thiết bị thông minh có khả năng tương thích và hỗ trợ đầy đủ các tính năng của ứng dụng ngân hàng số mới.
  • Ranh giới hệ thống bị giới hạn: Đồ án loại trừ việc nâng cấp hệ thống Core Banking và thay thế phần mềm CRM sẵn có, do đó khả năng tối ưu hóa nghiệp vụ vẫn phụ thuộc vào năng lực tích hợp của hạ tầng cũ.
  • Rủi ro triển khai: Đồ án ghi nhận các rủi ro liên quan đến sự phản đối của khách hàng quen dùng hệ thống cũ (user adoption resistance), nguy cơ phát sinh chi phí ngoài dự toán, sự phụ thuộc vào phê duyệt của cơ quan quản lý và tiến độ cung cấp giải pháp từ các đối tác thứ ba.

Hướng nghiên cứu và phát triển tiếp theo

  • Nghiên cứu xây dựng và thử nghiệm các thuật toán học máy nhằm phân tích hành vi chi tiêu của khách hàng, phục vụ tính năng tư vấn tài chính tự động trong dài hạn.
  • Mở rộng phạm vi phân tích để đánh giá khả năng kết nối an toàn với các nền tảng quản lý tài chính cá nhân và dịch vụ đầu tư của bên thứ ba khi có sự thay đổi về chính sách nghiệp vụ.

Giá trị tham khảo

Đối tượng thụ hưởng tài liệu

  • Sinh viên ngành Hệ thống Thông tin Quản lý (MIS), Công nghệ Thông tin, Tài chính - Ngân hàng: Tài liệu là đồ án mẫu về quy trình phân tích nghiệp vụ thực tế trong lĩnh vực ngân hàng bán lẻ (Retail Banking).
  • Chuyên viên Phân tích Nghiệp vụ (BA) và Quản lý Dự án (PM): Có thể sử dụng trực tiếp các biểu mẫu, ma trận và cấu trúc phân tích trong tài liệu để áp dụng vào các dự án phần mềm tài chính tương tự.

Các hợp phần giá trị để tham khảo

  • Bộ câu hỏi khảo sát phạm vi (Project Scope Questionnaire) và câu hỏi thu thập yêu cầu (Requirements Gathering Questionnaires): Gồm danh mục chi tiết các câu hỏi phân loại theo chức năng, phi chức năng, cơ sở dữ liệu, API và yêu cầu chuyển đổi hệ thống (Transition Requirements).
  • Quy trình phân tích nguyên nhân gốc rễ (RCA): Cung cấp phương pháp truy vết có hệ thống từ hiện tượng người dùng phản ánh đến lỗi truy vấn CSDL và tài nguyên phần cứng.
  • Mô hình lược đồ CSDL và ma trận RACI: Khung tham chiếu chuẩn cho việc thiết kế phân quyền và lưu trữ dữ liệu trong ứng dụng ngân hàng số.

Câu hỏi thường gặp

1. Dự án đặt ra những yêu cầu phi chức năng cụ thể nào về thời gian phản hồi và độ sẵn sàng của hệ thống?

Theo tài liệu đặc tả, ứng dụng ngân hàng số phải đạt thời gian phản hồi dưới 2 giây cho mọi thao tác của người dùng, thời gian tải trang web dưới 3 giây dưới điều kiện tiêu chuẩn và thời gian xử lý giao dịch chuyển tiền không vượt quá 5 giây. Hệ thống phải đảm bảo độ sẵn sàng đạt mức 99,9% hoạt động liên tục 24/7 (ngoại trừ thời gian bảo trì định kỳ) kèm cơ chế dự phòng sự cố (failover).

2. Kết quả khảo sát người dùng trong báo cáo đánh giá nhu cầu đã chỉ ra những con số cụ thể nào?

Khảo sát người dùng ghi nhận 70% khách hàng đánh giá giao diện hiện tại không trực quan, 65% có nhu cầu bổ sung tính năng nạp séc qua di động (mobile check deposit), và 60% đánh giá dịch vụ của ngân hàng kém hơn đối thủ cạnh tranh về mặt cá nhân hóa và các công cụ tài chính tương tác.

3. Nguyên nhân gốc rễ dẫn đến sự cố chậm trễ thông báo giao dịch là gì?

Nguyên nhân gốc rễ được xác định qua phân tích kỹ thuật là do độ trễ API cao (thường xuyên xuất hiện lỗi 504 Gateway Timeout trong giờ cao điểm) xuất phát từ việc cơ sở dữ liệu backend phản hồi câu lệnh truy vấn chậm. Tình trạng này do các câu lệnh SQL chưa tối ưu, thiếu chỉ mục (indexing) phù hợp, cùng với việc máy chủ cơ sở dữ liệu không được cấp đủ tài nguyên CPU và RAM để xử lý lưu lượng truy cập lớn.

4. Quy tắc an toàn nào được thiết lập cho chức năng Đăng nhập an toàn (UC102)?

Chức năng đăng nhập yêu cầu tên người dùng và mật khẩu, tự động kích hoạt xác thực đa yếu tố (MFA) khi người dùng truy cập từ thiết bị mới. Nếu người dùng đăng nhập không thành công 3 lần liên tiếp, hệ thống sẽ tự động khóa tài khoản trong thời gian 30 phút và gửi thông báo cảnh báo qua email đã đăng ký.

5. Những hạng mục nào được xác định rõ là nằm ngoài phạm vi (Out-of-Scope) của dự án?

Các hạng mục nằm ngoài phạm vi triển khai bao gồm: đại tu toàn bộ hệ thống ngân hàng lõi (Core Banking System), tích hợp trực tiếp với các dịch vụ/nền tảng đầu tư bên ngoài, tích hợp với các công cụ quản lý tài chính và lập ngân sách của bên thứ ba, và thay thế hệ thống quản trị quan hệ khách hàng (CRM) hiện tại của ngân hàng.


Kết luận

Đồ án Sáng kiến Nâng cấp Ngân hàng Số của Diwakar Singh đã hoàn thành toàn diện quy trình phân tích nghiệp vụ cho bài toán hiện đại hóa nền tảng ngân hàng bán lẻ trực tuyến. Bằng việc kết hợp chặt chẽ giữa khảo sát thực nghiệm định lượng, phân tích nguyên nhân kỹ thuật và mô hình hóa hệ thống theo chuẩn IEEE SRS, tác giả đã đưa ra các giải pháp khả thi nhằm khắc phục triệt để các hạn chế về giao diện, tính năng và độ trễ hệ thống. Đây là tài liệu nghiệp vụ có giá trị tham khảo cao về phương pháp luận và kỹ thuật tài liệu hóa cho các dự án chuyển đổi số trong lĩnh vực tài chính - ngân hàng.