Một khách hàng hỏi vì sao đơn hàng tháng trước giao trễ ba ngày. Hệ thống ERP có thể trả lời câu đó cho một đơn hàng cụ thể, trên một màn hình, trong vài giây — vì nó được xây ra để chạy chính đơn hàng đó: kiểm tra kho nào có thể đáp ứng, tính thời gian lấy hàng và thời gian vận chuyển, áp dụng các điều chỉnh theo ngày làm việc và cut-off, rồi chuyển sang đơn tiếp theo. Nhưng nếu hỏi cùng cơ sở dữ liệu đó câu hỏi tương tự cho tất cả khách hàng, tất cả kho, trong cả một quý — hệ thống bắt đầu ì ạch. Đây không phải vấn đề phần cứng. Đây là vấn đề mô hình dữ liệu: chúng tôi đang bắt một hệ thống được xây để xử lý từng giao dịch một trả lời một câu hỏi về tất cả giao dịch cùng lúc.
Hai công việc, hai mô hình
Đây chính là ranh giới giữa OLTP (online transaction processing — xử lý giao dịch trực tuyến) và một mô hình được xây cho phân tích. Trong một module tính thời gian giao hàng thực tế xây trên hệ thống ERP Infor, phần vận hành xử lý quy trình sống:
- Kiểm tra kho nào (hoặc những kho nào) có thể đáp ứng đơn hàng
- Tính thời gian lấy hàng và thời gian vận chuyển cho từng kho
- Áp dụng các điều chỉnh theo ngày làm việc và cut-off để ngày giao hàng cam kết là thực tế
Mô hình đó được tối ưu để ghi và đọc đúng một đơn hàng, nhanh, ngay lúc này. Nó chưa bao giờ được xây để cộng dồn, cắt lát, so sánh trên hàng nghìn đơn hàng — và cũng không nên bị ép làm việc đó.
Dựng lại cùng dữ liệu đó thành hình ngôi sao
Để báo cáo/phân tích trên nền quy trình vận hành đó, cùng một dữ liệu được mô hình hóa khác đi: theo Sternschema (mô hình ngôi sao), cấu trúc nền tảng của cách tiếp cận Kimball trong mô hình hóa phân tích. Ở trung tâm là một bảng sự kiện (fact table), ví dụ FAKT_Lieferung, chứa các đại lượng đáng phân tích:
- Thời gian giao hàng theo kế hoạch (Lieferzeit_geplant)
- Thời gian giao hàng thực tế (Lieferzeit_ist)
- Độ lệch giữa hai giá trị đó (deviation)
- Một cờ đúng-hạn (OnTime)
Xung quanh là các bảng chiều (dimension) mô tả bối cảnh của từng lần giao hàng:
- Dim_Zeit — đơn hàng xảy ra khi nào
- Dim_Kunde — thuộc khách hàng nào
- Dim_Lager — kho nào thực hiện
- Dim_Artikel — sản phẩm nào được giao
Chính cấu trúc này giúp các câu hỏi kiểu OLAP trở nên khả thi sau đó: cắt lát tổng số đơn giao trễ theo khách hàng, chia nhỏ theo kho và khoảng thời gian, rồi đào sâu từ "số đơn giao trễ trong quý này" xuống tận tổ hợp kho-khách hàng cụ thể gây ra vấn đề. Không câu hỏi nào trong số này được các bảng vận hành của Infor thiết kế để trả lời hiệu quả.
Đưa dữ liệu vào mô hình
Sternschema không tự đầy lên. Cần một bước ETL (extract-transform-load) để chuyển dữ liệu từ hệ thống vận hành sang mô hình phân tích, thường thông qua change-data-capture — ví dụ Debezium đọc các thay đổi từ cơ sở dữ liệu vận hành và đẩy chúng qua một pipeline message trước khi đến được FAKT_Lieferung và các bảng chiều của nó. Pipeline này chạy tách biệt với, và sau, chính giao dịch vận hành.
Bài học thực tế cho một xưởng sản xuất đang vận hành ERP riêng: nếu báo cáo về thời gian giao hàng, tồn đọng đơn hàng, hay công suất máy móc chạy chậm hoặc khó dựng, giải pháp hiếm khi là một server nhanh hơn hay thêm một index trên bảng dữ liệu sống. Vấn đề thường là chưa ai xây mô hình thứ hai — mô hình có nhiệm vụ duy nhất là trả lời câu hỏi sau khi sự việc đã xảy ra, tách biệt với mô hình có nhiệm vụ chạy đơn hàng của hôm nay.
Nguyễn Hải Minh
Tôi làm việc trong ngành CNTT tại Đức — trực tiếp viết phần mềm và xử lý dữ liệu hệ thống ERP (như INFOR) cho các nhà máy sản xuất của Đức. Về học vấn, tôi có bằng Cử nhân Kỹ thuật CNTT và bằng Kỹ thuật viên Điện tử Thông tin cấp nhà nước tại Đức. Tất cả những nền tảng đó giúp tôi rèn luyện một tư duy hệ thống vững vàng để làm tự động hóa và tối ưu vận hành chuẩn chỉ.
Tìm hiểu thêm về tác giả →