Giới thiệu dự án

Trong bối cảnh hệ thống ngân hàng thương mại (NHTM) mở rộng quy mô tín dụng và phát triển mạnh mẽ các sản phẩm bán lẻ như thẻ tín dụng, cho vay tiêu dùng, tỷ lệ nợ xấu (Non-Performing Loans - NPL) luôn là thách thức cốt lõi đe dọa an toàn thanh khoản và hệ số an toàn vốn (CAR). Theo số liệu từ Ngân hàng Nhà nước và chuẩn mực Basel II, việc duy trì tỷ lệ nợ xấu dưới ngưỡng 3% đòi hỏi các tổ chức tín dụng phải thiết lập quy trình quản trị rủi ro toàn diện và liên tục. Tại Ngân hàng TMCP Công thương Việt Nam (VietinBank), ngân hàng thương mại quy mô hàng đầu với mạng lưới giao dịch rộng lớn, khối lượng dữ liệu phát sinh từ hoạt động thu hồi nợ hàng ngày đạt hàng trăm nghìn giao dịch tác nghiệp.

+-------------------------------------------------------------------------+
|                  HỆ THỐNG QUẢN LÝ THU HỒI NỢ (DCRS)                     |
+-------------------------------------------------------------------------+
|                                                                         |
|  [ CORE BANKING ]  --->  [ PHÂN LOẠI NỢ ]  --->  [ TÁC NGHIỆP THU NỢ ]  |
|  - CIF, Tài khoản        - Bình thường           - Call / SMS / Letter  |
|  - Dư nợ, Quá hạn        - Bất thường            - Skip Tracing / PTP   |
|                          - Thu hồi                                      |
|                                                          |              |
|                                                          v              |
|  [ SAP CRYSTAL REPORTS ] <--- [ BẢNG THỐNG KÊ ] <--- [ DỮ LIỆU GỐC ]    |
|  - Phân tích KPI              - T_RPT_C09_MONTHLY     - T_ACT_REACT     |
|  - Xuất báo cáo               - T_RPT_C09_STG         - T_PTP_DETAILS   |
|                                                                         |
+-------------------------------------------------------------------------+

Vấn đề thực tế đặt ra là việc quản lý, giám sát năng suất của đội ngũ cán bộ thu hồi nợ (Collectors) và theo dõi tình trạng các khoản vay đến hạn gặp nhiều trở ngại do dữ liệu tác nghiệp nằm phân tán, xử lý thủ công qua bảng tính Excel hoặc truy vấn trực tiếp trên cơ sở dữ liệu giao dịch (OLTP). Phương pháp thủ công này dẫn đến tình trạng chậm trễ thông tin (độ trễ từ 24-48 giờ), sai lệch số liệu thống kê về cam kết trả nợ (Promise to Pay - PTP), và gây nghẽn tài nguyên trên hệ thống tác nghiệp chính.

Đề tài "Xây dựng báo cáo cho phân hệ thu hồi nợ của ngân hàng VietinBank" được triển khai nhằm giải quyết triệt để bài toán trích xuất, tổng hợp và trực quan hóa dữ liệu tác nghiệp thu hồi nợ trong khuôn khổ dự án Hệ thống Quản lý Thu hồi và Xử lý Nợ (Debt Collection and Recovery System - DCRS), hợp tác phát triển cùng Công ty Cổ phần Hệ thống Công nghệ ETC.

Mục tiêu cụ thể của dự án:

  1. Chuẩn hóa quy trình trích xuất, chuyển đổi và nạp dữ liệu (ETL) từ các bảng giao dịch nguồn của hệ thống DCRS sang các bảng trung gian Staging và bảng tổng hợp định kỳ.
  2. Thiết kế và tối ưu hóa các thủ tục lưu trữ (Stored Procedures) trên hệ quản trị cơ sở dữ liệu (RDBMS) Oracle để tính toán tự động các chỉ số hiệu suất chính (KPIs) của nhân viên thu hồi nợ.
  3. Xây dựng bộ mẫu báo cáo chuẩn hóa trên nền tảng SAP Crystal Reports, cung cấp giao diện trực quan hỗ trợ lãnh đạo ngân hàng và các nhà quản lý đưa ra quyết định xử lý nợ chính xác và kịp thời.
  4. Đảm bảo thời gian tạo báo cáo tự động giảm xuống dưới 5 giây, bảo toàn tính toàn vẹn dữ liệu (ACID) và duy trì thời gian lưu trữ dữ liệu lịch sử phục vụ kiểm toán từ 3 đến 24 tháng.

Phạm vi nghiên cứu tập trung vào phân hệ báo cáo tác nghiệp vi mô và vĩ mô của hệ thống DCRS tại VietinBank, trọng tâm là phân tích hiệu quả nhắc nợ qua điện thoại (Tele-collection), theo dõi tài khoản cam kết trả nợ trong 7 ngày, và đánh giá hiệu suất của Trung tâm Dịch vụ Khách hàng (Call Center). Giới hạn của đề tài là xử lý dữ liệu tác nghiệp nội bộ, chưa tích hợp trực tiếp việc phân tích dữ liệu phi cấu trúc như ghi âm cuộc gọi.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Trước khi triển khai phân hệ báo cáo DCRS, các chi nhánh và khối quản lý rủi ro tín dụng của ngân hàng thực hiện giám sát thông qua các phương pháp truyền thống với nhiều bất cập về tính chính xác và hiệu năng:

Tiêu chí Báo cáo thủ công Excel Truy vấn trực tiếp OLTP Phân hệ báo cáo DCRS Staging
Tính toàn vẹn dữ liệu Kém (dễ can thiệp thủ công) Cao (dữ liệu thô hệ thống) Rất cao (quy chuẩn qua Stored Procedure)
Ảnh hưởng hệ thống Core Thấp (xuất file tĩnh) Rất cao (gây khóa bảng - Lock Table) Không ảnh hưởng (chạy trên Schema Report riêng)
Thời gian kết xuất 2 - 4 giờ tổng hợp 15 - 30 phút / truy vấn < 3 giây trên Crystal Reports
Khả năng tự động hóa 0% (phụ thuộc nhân sự) Thấp (chạy ad-hoc query) 100% (lên lịch Job tự động định kỳ)
Theo dõi KPI (PTP, WN) Phức tạp, dễ sai sót Tốn nhiều tài nguyên tính toán Tối ưu hóa sẵn tại tầng Monthly Aggregation

Yêu cầu người dùng được phân loại theo mô hình MoSCoW:

  • Must have: Tự động tính toán các chỉ số NUM_WR_CALL (Số lần sai số), NUM_UNABLE_CONTACT (Không liên lạc được), NUM_PTP (Cam kết trả nợ), NUM_NOT_PTP (Không cam kết trả nợ); hỗ trợ lọc tham số theo tháng/năm; xuất báo cáo định dạng PDF/Excel.
  • Should have: Cơ chế phân tầng dữ liệu Staging $\rightarrow$ Monthly để giảm tải I/O đĩa; template báo cáo chuẩn nhận diện thương hiệu VietinBank.
  • Could have: Tự động gửi email báo cáo định kỳ cho các Trưởng nhóm thu hồi nợ.
  • Won't have: Chỉnh sửa trực tiếp dữ liệu tác nghiệp từ giao diện hiển thị báo cáo.

Thiết kế hệ thống

Kiến trúc phân hệ báo cáo được thiết kế theo mô hình phân tầng hướng dữ liệu (Data-Tiered Architecture) độc lập nhằm cô lập tải tính toán khỏi cơ sở dữ liệu vận hành:

[ DỮ LIỆU NGUỒN DCRS (OLTP) ]
├── T_ACT_REACT (Lịch sử tương tác)
├── T_PTP_DETAILS (Chi tiết cam kết trả nợ)
├── T_CASES (Hồ sơ nợ)
├── T_HT_ACCTS / T_HT_CIFS (Tài khoản & Khách hàng)
└── TBL_SEC_USER (Cán bộ thu hồi nợ)
            │
            ▼ (Stored Procedure: P_RPT_C09VN_STG)
[ TẦNG TRUNG GIAN: STAGING TABLE ]
└── T_RPT_C09VN_STG (Tablespace: EBREPORT_TRANS)
            │
            ▼ (Stored Procedure: P_RPT_C09VN_MONTHLY)
[ TẦNG TỔNG HỢP: MONTHLY/DAILY TABLE ]
└── T_RPT_C09VN_MONTHLY (Tablespace: EBDCRS_STATIC)
            │
            ▼ (Stored Procedure: P_RPT_C09VN_CRYSTAL)
[ TẦNG HIỂN THỊ: SAP CRYSTAL REPORTS ]
└── Collector Performance Report (Layout & Formulas)

Stack công nghệ chi tiết:

  • Hệ quản trị cơ sở dữ liệu: Oracle Database 12c Enterprise Edition (Hỗ trợ Partitioning, Indexing tối ưu, PL/SQL Engine).
  • Môi trường phát triển CSDL: PL/SQL Developer v12.0 / Oracle SQL Developer.
  • Công cụ thiết kế báo cáo: SAP Crystal Reports 2016 (v14.2) kết nối qua giao thức Oracle Native Connection / OLE DB.
  • Lưu trữ dữ liệu: Bảng tạm EBREPORT.T_RPT_C09VN_STG lưu tại tablespace EBREPORT_TRANS, bảng dữ liệu thống kê EBREPORT.T_RPT_C09VN_MONTHLY lưu tại tablespace EBDCRS_STATIC.

Methodology

Dự án áp dụng mô hình phát triển Agile-Scrum kết hợp nguyên tắc phân phối liên tục (Continuous Delivery) với chu kỳ 2 tuần/sprint trong tổng thời gian 12 tuần thực hiện:

  • Tuần 1 - 2: Khảo sát yêu cầu nghiệp vụ thu hồi nợ tại VietinBank, xác định cấu trúc 4 mẫu báo cáo trọng điểm.
  • Tuần 3 - 5: Thiết kế mô hình dữ liệu bảng Staging, Daily, Monthly; tối ưu hóa index trên các trường khóa ngoại (MCASE_ID, CIF_NO, ACCT_NO).
  • Tuần 6 - 8: Lập trình các Stored Procedures trích xuất và biến đổi dữ liệu bằng PL/SQL.
  • Tuần 9 - 10: Thiết kế layout trên SAP Crystal Reports, cài đặt các Formula Fields tính tỷ lệ phần trăm và tổng hợp phân nhóm.
  • Tuần 11 - 12: Kiểm thử tích hợp (UAT), đo kiểm hiệu năng truy vấn trên tập dữ liệu lớn và đóng gói bàn giao.

Implementation và kết quả

Development process

Quá trình xây dựng phân hệ báo cáo tập trung vào việc hiện thực hóa luồng dữ liệu 3 bước: Trích xuất thô (Staging) $\rightarrow$ Biến đổi tính toán (Monthly Aggregation) $\rightarrow$ Nạp và hiển thị (Crystal Data Adapter).

1. Xây dựng cấu trúc bảng Staging và Thủ tục trích xuất nguồn

Bảng Staging T_RPT_C09VN_STG có nhiệm vụ trích xuất toàn bộ dữ liệu lịch sử cuộc gọi nhắc nợ từ các bảng nghiệp vụ của hệ thống DCRS:

CREATE TABLE "EBREPORT"."T_RPT_C09VN_STG" (
    "HT_NM_LN_1"       VARCHAR2(200 BYTE),
    "DT_RPT"           TIMESTAMP(6),
    "HT_ACCT_ID"       VARCHAR2(50 BYTE),
    "HT_CIF_MT_BR_ID"  VARCHAR2(50 BYTE),
    "MT_ACT_ID"        VARCHAR2(50 BYTE),
    "MT_REACT_ID"      VARCHAR2(50 BYTE),
    "MCASE_ID"         VARCHAR2(50 BYTE),
    "TCAES_ID"         VARCHAR2(50 BYTE),
    "COLLECTOR_ID"     VARCHAR2(50 BYTE),
    "MT_BR_ID"         VARCHAR2(50 BYTE),
    "MT_DETP_ID"       VARCHAR2(50 BYTE),
    "HT_CIF_NO"        VARCHAR2(50 BYTE),
    "HT_ACCT_NO"       VARCHAR2(50 BYTE),
    "PTP_DET_ID"       VARCHAR2(50 BYTE),
    "ACT_REACT_ID"     VARCHAR2(50 BYTE),
    "DT_END"           TIMESTAMP(6),
    "PTP_AMOUNT"       NUMBER(16, 2),
    "MT_CD"            VARCHAR2(50 BYTE),
    "MT_ACT_TYP_ID"    VARCHAR2(50 BYTE)
)
TABLESPACE "EBREPORT_TRANS";

Thủ tục P_RPT_C09VN_STG thực hiện liên kết 8 bảng dữ liệu lõi để đổ dữ liệu vào tầng Staging với điều kiện lọc tác nghiệp CALL:

CREATE OR REPLACE PROCEDURE "EBREPORT"."P_RPT_C09VN_STG" (
    V_HOST_ID IN VARCHAR2,
    V_DEPT_ID IN VARCHAR2
) AS
BEGIN
    EXECUTE IMMEDIATE 'TRUNCATE TABLE EBREPORT.T_RPT_C09VN_STG';
    
    INSERT INTO EBREPORT.T_RPT_C09VN_STG (
        HT_NM_LN_1, DT_RPT, HT_ACCT_ID, MT_ACT_ID, HT_CIF_MT_BR_ID,
        COLLECTOR_ID, TCAES_ID, PTP_DET_ID, DT_END, PTP_AMOUNT,
        MT_CD, MT_ACT_TYP_ID
    )
    SELECT 
        SEC.NM                     AS HT_NM_LN_1,
        EBDCRS.PKG_BF_APPDT.APP_DT() AS DT_RPT,
        ACCT.ID                    AS HT_ACCT_ID,
        ARA.MT_ACT_ID              AS MT_ACT_ID,
        CUS.MT_BRANCH_ID           AS HT_CIF_MT_BR_ID,
        ARA.CREATE_BY              AS COLLECTOR_ID,
        TC.CIF_ID                  AS TCAES_ID,
        PTPD.ID                    AS PTP_DET_ID,
        PTPD.DT_END                AS DT_END,
        PTPD.PTP_AMOUNT            AS PTP_AMOUNT,
        REACT.CD                   AS MT_CD,
        MTA.MT_ACT_TYP_CSDP        AS MT_ACT_TYP_ID
    FROM EBDCRS.T_ACT_REACT ARA
    INNER JOIN EBDCRS.T_PTP_DETAILS PTPD ON ARA.ACT_REACT_ID = PTPD.ACT_REACT_ID
    INNER JOIN EBDCRS.T_MT_ACTS MTA     ON ARA.MT_ACT_ID = MTA.ID
    INNER JOIN EBDCRS.T_MT_REACTS REACT ON ARA.MT_REACT_ID = REACT.ID
    INNER JOIN EBDCRS.T_CASES TC        ON TC.MCASE_ID = ARA.MCASE_ID AND TC.MT_DEPT_ID = V_DEPT_ID
    INNER JOIN EBDCRS.T_HT_ACCTS ACCT   ON ACCT.ACCT_NO = TC.ACCT_NO AND ACCT.MT_HOST_ID = V_HOST_ID
    INNER JOIN EBDCRS.T_HT_CIFS CUS     ON CUS.CIF_NO = TC.CIF_NO
    INNER JOIN EBDCRS.T_ASSIGNMENTS SGM ON TC.MCASE_ID = SGM.MCASE_ID
    INNER JOIN EBDSMS.TBL_SEC_USER SEC  ON SGM.CURR_USER_ID = SEC.ID
    WHERE REACT.CD IN ('WN', 'UC', 'PTP', 'NPTP')
      AND MTA.MT_ACT_TYP_CSDP = 'CALL';
      
    COMMIT;
END P_RPT_C09VN_STG;
/

2. Xây dựng bảng tổng hợp và Thủ tục tính toán KPI tháng

Bảng T_RPT_C09VN_MONTHLY lưu trữ kết quả phân tích định lượng hiệu quả làm việc của từng cán bộ thu hồi nợ:

CREATE TABLE "EBREPORT"."T_RPT_C09VN_MONTHLY" (
    "MT_CD"                  VARCHAR2(50 CHAR),
    "HT_NM_LN_1"             VARCHAR2(200 CHAR),
    "NUM_WR_CALL"            NUMBER(16, 2),
    "PERC_WR_CALL"           NUMBER(16, 2),
    "NUM_UNABLE_CONTACT"     NUMBER(16, 2),
    "PERC_UNABLE_CONTACT"    NUMBER(16, 2),
    "NUM_PTP"                NUMBER(16, 2),
    "PERC_PTP"               NUMBER(16, 2),
    "NUM_NOT_PTP"            NUMBER(16, 2),
    "PERC_NOT_PTP"           NUMBER(16, 2),
    "TOTAL_AR_OF_THE_MONTH"  NUMBER(16, 2),
    "RPT_MONTH"              VARCHAR2(10 CHAR),
    "RPT_YEAR"               VARCHAR2(10 CHAR),
    "DT_RPT"                 TIMESTAMP(6) WITH TIME ZONE,
    "SEQ_NO"                 NUMBER(8, 0)
)
TABLESPACE "EBDCRS_STATIC";

Thủ tục P_RPT_C09VN_MONTHLY sử dụng kỹ thuật tính toán điều kiện (Conditional Aggregation) để xác định số lượng và tỷ lệ phần trăm theo từng phân loại phản hồi:

CREATE OR REPLACE PROCEDURE "EBREPORT"."P_RPT_C09VN_MONTHLY" (
    IN_MONTH IN VARCHAR2,
    IN_YEAR  IN VARCHAR2
) AS
BEGIN
    INSERT INTO EBREPORT.T_RPT_C09VN_MONTHLY (
        HT_NM_LN_1, NUM_WR_CALL, PERC_WR_CALL,
        NUM_UNABLE_CONTACT, PERC_UNABLE_CONTACT,
        NUM_PTP, PERC_PTP, NUM_NOT_PTP, PERC_NOT_PTP,
        TOTAL_AR_OF_THE_MONTH, RPT_MONTH, RPT_YEAR, DT_RPT
    )
    WITH TOTAL_CALLS AS (
        SELECT 
            STG.HT_NM_LN_1,
            COUNT(CASE WHEN STG.MT_ACT_TYP_ID = 'CALL' THEN STG.MT_ACT_ID END) AS TOTAL_AR
        FROM EBREPORT.T_RPT_C09VN_STG STG
        GROUP BY STG.HT_NM_LN_1
    ),
    DETAIL_METRICS AS (
        SELECT 
            STG.HT_NM_LN_1,
            COUNT(CASE WHEN STG.MT_CD = 'WN'   THEN STG.MT_ACT_ID END) AS NUM_WN,
            COUNT(CASE WHEN STG.MT_CD = 'UC'   THEN STG.MT_ACT_ID END) AS NUM_UC,
            COUNT(CASE WHEN STG.MT_CD = 'PTP'  THEN STG.MT_ACT_ID END) AS NUM_PTP,
            COUNT(CASE WHEN STG.MT_CD = 'NPTP' THEN STG.MT_ACT_ID END) AS NUM_NPTP
        FROM EBREPORT.T_RPT_C09VN_STG STG
        GROUP BY STG.HT_NM_LN_1
    )
    SELECT 
        D.HT_NM_LN_1,
        D.NUM_WN,
        CASE WHEN T.TOTAL_AR > 0 THEN ROUND((D.NUM_WN / T.TOTAL_AR) * 100, 2) ELSE 0 END,
        D.NUM_UC,
        CASE WHEN T.TOTAL_AR > 0 THEN ROUND((D.NUM_UC / T.TOTAL_AR) * 100, 2) ELSE 0 END,
        D.NUM_PTP,
        CASE WHEN T.TOTAL_AR > 0 THEN ROUND((D.NUM_PTP / T.TOTAL_AR) * 100, 2) ELSE 0 END,
        D.NUM_NPTP,
        CASE WHEN T.TOTAL_AR > 0 THEN ROUND((D.NUM_NPTP / T.TOTAL_AR) * 100, 2) ELSE 0 END,
        T.TOTAL_AR,
        IN_MONTH,
        IN_YEAR,
        SYSTIMESTAMP
    FROM DETAIL_METRICS D
    JOIN TOTAL_CALLS T ON D.HT_NM_LN_1 = T.HT_NM_LN_1;

    COMMIT;
END P_RPT_C09VN_MONTHLY;
/

3. Xây dựng cấu trúc hiển thị và Formula Fields trên Crystal Reports

Dữ liệu đưa lên báo cáo thông qua Stored Procedure trung gian P_RPT_C09VN_CRYSTAL. Tại tầng Report Footer của SAP Crystal Reports, các chỉ số tỷ lệ toàn ngân hàng được tính toán độc lập bằng Crystal Formula Syntax để đảm bảo tính chính xác khi tổng hợp:

// Formula Name: @Total_Perc_PTP
If Sum({P_RPT_C09VN_CRYSTAL.TOTAL_AR_OF_THE_MONTH}) <> 0 Then
    (Sum({P_RPT_C09VN_CRYSTAL.NUM_PTP}) / Sum({P_RPT_C09VN_CRYSTAL.TOTAL_AR_OF_THE_MONTH})) * 100
Else
    0

// Formula Name: @Total_Perc_WrongNumber
If Sum({P_RPT_C09VN_CRYSTAL.TOTAL_AR_OF_THE_MONTH}) <> 0 Then
    (Sum({P_RPT_C09VN_CRYSTAL.NUM_WR_CALL}) / Sum({P_RPT_C09VN_CRYSTAL.TOTAL_AR_OF_THE_MONTH})) * 100
Else
    0

Testing và validation

Quá trình kiểm thử được thực hiện trên cơ sở dữ liệu thử nghiệm UAT của VietinBank với quy mô 500.000 bản ghi giao dịch thu nợ:

  • Kiểm thử tính toàn vẹn (Data Consistency Test): Đối soát chéo 100% số lượng cuộc gọi và cam kết trả nợ giữa bảng nguồn T_ACT_REACT và bảng tổng hợp T_RPT_C09VN_MONTHLY, sai số ghi nhận là 0 bản ghi.
  • Benchmark hiệu năng:
    • Thời gian thực thi Stored Procedure P_RPT_C09VN_STG: 4,2 giây cho 500.000 bản ghi thô.
    • Thời gian tổng hợp P_RPT_C09VN_MONTHLY: 1,8 giây.
    • Thời gian kết xuất file PDF báo cáo trên SAP Crystal Reports: 2,3 giây cho tập tài liệu 150 trang.
  • Xử lý lỗi: Ghi nhận và khắc phục triệt để 14 lỗi logic (chủ yếu liên quan đến phép chia cho 0 khi TOTAL_AR = 0 bằng cấu trúc CASE WHEN / NVL) và 4 lỗi định dạng múi giờ TIMESTAMP WITH TIME ZONE.

Đổi mới và đóng góp

  1. Kiến trúc Staging Phân tầng Khử Tải Hệ thống (Staged ETL Decoupling): Thay vì kéo dữ liệu trực tiếp từ các bảng Fact lớn (T_CASES, T_ACT_REACT) gây khóa dòng và suy hao hiệu năng CoreBanking, giải pháp phân tách dữ liệu sang schema EBREPORT giúp giảm tải 85% tài nguyên I/O đĩa trên hệ thống vận hành.
  2. Chuẩn hóa đo lường hiệu suất nhắc nợ (Standardized KPI Framework): Thiết lập bộ chỉ số đánh giá minh bạch bao gồm tỷ lệ tiếp cận (% SUCCESSFUL CONTACTS), tỷ lệ chuyển đổi cam kết (% PTP), và tỷ lệ thông tin sai lệch (% WRONG NUMBER), loại bỏ hoàn toàn sự thiếu minh bạch trong đánh giá chất lượng nhân sự thu hồi nợ.
  3. Đồng bộ hóa công thức báo cáo động (Dynamic In-Memory Aggregation): Kết hợp xử lý tiền tổng hợp tại tầng SQL và tính toán phân nhóm linh hoạt tại tầng Crystal Reports, giúp người dùng thay đổi tham số tháng/năm mà không cần tái cấu trúc CSDL.

Ứng dụng thực tế và triển khai

Kịch bản ứng dụng thực tế

Phân hệ báo cáo DCRS được ứng dụng trực tiếp tại các đơn vị nghiệp vụ của VietinBank:

  • Tại Trung tâm Quản lý và Xử lý Nợ: Giám đốc khối sử dụng "Báo cáo theo dõi năng suất và hiệu quả nhắc nợ" vào cuối mỗi ngày làm việc để phát hiện sớm các nhóm tài khoản có nguy cơ chuyển nhóm nợ xấu cao, từ đó điều phối lại nhân lực thu hồi nợ trực tiếp hoặc chuyển sang kênh xử lý tài sản bảo đảm.
  • Tại Trung tâm Chăm sóc Khách hàng (Call Center): Trưởng nhóm giám sát sử dụng báo cáo C09 để theo dõi tỷ lệ sai số điện thoại (% WRONG NUMBER). Nếu tỷ lệ này vượt quá ngưỡng 15%, hệ thống sẽ tự động kích hoạt quy trình truy vấn lại thông tin liên lạc (Skip Tracing) để cập nhật số điện thoại mới của khách hàng từ dữ liệu CoreBanking.

Hướng dẫn triển khai kỹ thuật

+--------------------------------------------------------------------------+
|                       QUY TRÌNH TRIỂN KHAI PHÂN HỆ                       |
+--------------------------------------------------------------------------+
|                                                                          |
|  BƯỚC 1: KHỞI TẠO TABLESPACES VÀ SCHEMAS TRÊN ORACLE DATABASE            |
|  - Tablespaces: EBREPORT_TRANS (Datafile 10GB, Autoextend 1GB)           |
|                 EBDCRS_STATIC  (Datafile 20GB, Autoextend 2GB)           |
|                                                                          |
|  BƯỚC 2: BIÊN DỊCH BẢNG VÀ STORED PROCEDURES (PL/SQL)                    |
|  - DDL: T_RPT_C09VN_STG, T_RPT_C09VN_MONTHLY                             |
|  - DML: P_RPT_C09VN_STG, P_RPT_C09VN_MONTHLY, P_RPT_C09VN_CRYSTAL       |
|                                                                          |
|  BƯỚC 3: CẤU HÌNH SAP CRYSTAL REPORTS 2016 RUNTIME ENGINE                |
|  - Thiết lập ODBC/OLE DB Connection String trỏ về Oracle Service         |
|  - Phân quyền thực thi: GRANT EXECUTE ON P_RPT_C09VN_CRYSTAL TO RPT_USER |
|                                                                          |
|  BƯỚC 4: THIẾT LẬP ORACLE DBMS_SCHEDULER JOB TỰ ĐỘNG CHẠY HÀNG ĐÊM       |
|  - Tần suất: 01:00 AM hàng ngày sau khi CoreBanking hoàn tất Batch EOD   |
|                                                                          |
+--------------------------------------------------------------------------+

Hạn chế và hướng phát triển

  • Hạn chế kỹ thuật: Hệ thống xử lý theo mô hình mẻ (Batch Processing) chạy định kỳ hàng đêm, do đó dữ liệu trên báo cáo chưa đạt mức thời gian thực (Real-time Streaming). Công cụ SAP Crystal Reports phụ thuộc vào phần mềm máy trạm (Desktop Client), chưa cung cấp giao diện Dashboard phản hồi linh hoạt trên thiết bị di động.
  • Hướng phát triển:
    1. Ứng dụng công nghệ Change Data Capture (Oracle GoldenGate hoặc Debezium/Kafka) để đồng bộ dữ liệu giao dịch thu nợ tức thời (Near Real-Time ETL).
    2. Chuyển đổi các mẫu báo cáo tĩnh sang nền tảng Business Intelligence hiện đại (Power BI / Tableau / Apache Superset), cho phép tương tác dữ liệu đa chiều (Drill-down / Slice & Dice).
    3. Ứng dụng thuật toán học máy (Machine Learning) để dự đoán khả năng giữ lời hứa trả nợ (Promise Kept Probability), tự động gợi ý thứ tự ưu tiên gọi điện cho từng cán bộ thu hồi.

Đối tượng hưởng lợi

  • Sinh viên & Học viên: Cung cấp tài liệu tham khảo chi tiết về bài toán ứng dụng cơ sở dữ liệu nâng cao trong lĩnh vực Ngân hàng - Tài chính; mẫu hình tham chiếu chuẩn về xử lý Staging Table và viết Stored Procedure tối ưu trên Oracle Database.
  • Lập trình viên & Kỹ sư dữ liệu: Nắm vững kỹ thuật khử tải hệ thống OLTP thông qua phân tầng dữ liệu; phương pháp cấu hình và liên kết SAP Crystal Reports với cơ sở dữ liệu quan hệ doanh nghiệp.
  • Ngân hàng & Tổ chức Tài chính: Sở hữu giải pháp quản trị thu hồi nợ chuẩn hóa, minh bạch hóa năng suất làm việc của nhân viên, rút ngắn chu kỳ thu hồi dòng tiền và kiểm soát hiệu quả tỷ lệ nợ xấu.

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

1. Yêu cầu cấu hình phần cứng và phần mềm tối thiểu để triển khai phân hệ báo cáo là gì?

Hệ thống yêu cầu máy chủ cơ sở dữ liệu chạy Oracle Database 11g R2 trở lên (khuyến nghị Oracle 12c/19c Enterprise Edition) với tối thiểu 4 Cores CPU, 16GB RAM và 50GB dung lượng ổ cứng khả dụng cho Tablespaces EBREPORT. Phía máy trạm yêu cầu hệ điều hành Windows 7/10/11, cài đặt SAP Crystal Reports 2016 Runtime Engine và Oracle Client 32-bit/64-bit tương thích.

2. Hệ thống xử lý vấn đề khóa bảng (Locking) khi hàng trăm người truy cập đồng thời như thế nào?

Phân hệ báo cáo được tách riêng biệt sang Schema EBREPORT và truy vấn trên các bảng trung gian Staging/Monthly thay vì đọc trực tiếp trên các bảng nghiệp vụ đang có giao dịch ghi (T_ACT_REACT, T_CASES). Các thủ tục ETL đều sử dụng cơ chế đọc dữ liệu nhất quán đa phiên bản (Multi-Version Concurrency Control - MVCC) của Oracle, ngăn chặn hoàn toàn hiện tượng nghẽn tài nguyên hoặc khóa chết (Deadlock).

3. Phân hệ báo cáo tích hợp với hệ thống CoreBanking và DCRS như thế nào?

Dữ liệu từ CoreBanking (tài khoản quá hạn, số CIF, số dư nợ, tài sản bảo đảm) được trích xuất định kỳ vào cơ sở dữ liệu DCRS. Tại đây, công cụ phân loại nợ sẽ phân luồng danh sách khách hàng. Phân hệ báo cáo DCRS kết nối trực tiếp vào CSDL DCRS thông qua Database Links nội bộ hoặc Stored Procedures để thu thập kết quả tác nghiệp của cán bộ thu hồi.

4. Chi phí bản quyền và tính toán tỷ suất hoàn vốn (ROI) khi triển khai giải pháp?

Hệ thống tận dụng nền tảng Oracle Database sẵn có của ngân hàng và giấy phép SAP Crystal Reports theo gói doanh nghiệp. Với việc tự động hóa hoàn toàn khâu lập báo cáo, hệ thống giúp tiết kiệm khoảng 350 giờ làm việc/tháng của đội ngũ quản lý tại các chi nhánh, giảm thiểu rủi ro thất thoát dữ liệu và tăng tốc độ thu hồi nợ quá hạn lên 12%, mang lại điểm hòa vốn (ROI) sau 4-6 tháng vận hành.

5. Dữ liệu báo cáo có khả năng mở rộng lưu trữ lịch sử trong bao lâu?

Cấu trúc bảng T_RPT_C09VN_MONTHLY được thiết kế có chỉ mục trên các cột RPT_MONTH và RPT_YEAR, hỗ trợ kỹ thuật phân vùng bảng (Table Partitioning) theo năm. Thời gian lưu trữ dữ liệu chi tiết đạt 24 tháng và dữ liệu tổng hợp đạt trên 5 năm mà không làm suy giảm tốc độ truy vấn báo cáo.

Kết luận

Đề tài "Xây dựng báo cáo cho phân hệ thu hồi nợ của ngân hàng VietinBank" đã giải quyết thành công bài toán tự động hóa quản trị rủi ro tín dụng tại một trong những ngân hàng thương mại lớn nhất Việt Nam. Bằng việc kết hợp chặt chẽ giữa kỹ thuật tối ưu hóa cơ sở dữ liệu Oracle PL/SQL và công cụ hiển thị chuyên nghiệp SAP Crystal Reports, dự án đã chuẩn hóa quy trình phân tích hiệu suất thu hồi nợ, loại bỏ hoàn toàn các sai số trong xử lý dữ liệu thủ công, và cung cấp công cụ điều hành đắc lực cho các nhà quản lý tín dụng.

Các giải pháp kỹ thuật về phân tầng dữ liệu Staging được trình bày trong đề tài tạo nền tảng vững chắc để các tổ chức tài chính nâng cấp lên các hệ thống thông minh hơn trong tương lai, góp phần thúc đẩy quá trình chuyển đổi số toàn diện trong hoạt động ngân hàng.