CÂU HỎI THƯỜNG GẶP

Giải pháp phần mềm quản trị vận hành

Tài liệu này tổng hợp các câu hỏi mà CIO và Head of Operations đặt ra khi đánh giá phần mềm quản trị vận hành của OKAXI. Trả lời được viết theo kinh nghiệm thực chiến vận hành sản phẩm cho khách hàng bán lẻ và hệ thống quản lý hợp đồng trong môi trường thực tế.

Giải pháp phần mềm quản trị vận hành

Quay lại trang FAQ chính

Phần mềm OKAXI có tùy chỉnh được workflow theo nghiệp vụ riêng không?

Có. OKAXI thiết kế core engine theo dạng configurable thay vì hardcoded. Mọi workflow doanh nghiệp định nghĩa qua schema JSON với các node (action, condition, approval) và edge (transition). Quản trị viên phía doanh nghiệp tự sửa workflow qua bảng quản trị mà không cần OKAXI triển khai lại mã nguồn. Một số khách hàng đã vận hành hơn 50 workflow khác nhau cho các phòng ban khác nhau trên cùng một hệ thống.

Cách OKAXI thiết kế biểu mẫu động cho doanh nghiệp?

OKAXI dùng form schema theo chuẩn JSON Schema và UI Schema phân tách. Mỗi field có metadata gồm tên, kiểu dữ liệu, validation rule, dependency và visibility condition. Admin tự thêm field, ẩn field, hoặc đổi label qua giao diện drag-and-drop. Migration dữ liệu khi schema thay đổi tự động thông qua versioning, dữ liệu cũ vẫn đọc được sau khi nâng cấp form.

Có thể thay đổi workflow sau khi đã go-live không?

Có. OKAXI quản lý workflow theo version. Workflow đang chạy giữ nguyên cho các bản ghi đã khởi tạo. Bản ghi mới dùng workflow version mới. Khi cần migrate bản ghi đang chạy sang version mới, admin chạy migration script với mapping rule rõ ràng. Quy trình này tránh đột ngột thay đổi state máy đang chạy và đảm bảo tính nhất quán nghiệp vụ.

Time-to-customize cho một workflow mới là bao lâu?

Workflow đơn giản với 5 đến 7 bước được quản trị viên doanh nghiệp đã qua đào tạo cấu hình trong 2 ngày làm việc. Workflow phức tạp với hơn 20 node, nhiều cấp phê duyệt và tích hợp hệ thống ngoài mất 1 đến 2 tuần hợp tác với chuyên viên BA của OKAXI. Mọi workflow đều có môi trường sandbox để kiểm thử trước khi đưa lên vận hành thực tế. OKAXI cung cấp 4 buổi đào tạo cho 3 đến 5 quản trị viên doanh nghiệp trong giai đoạn bàn giao.

Khả năng xử lý dữ liệu lớn của OKAXI ra sao?

OKAXI áp dụng kỹ thuật indexing chuyên dụng cho từng query pattern. Hot table có composite index theo (tenant_id, status, created_at). Cold data archive xuống separate table với compression. Partition theo time range hoặc tenant để tránh full table scan. Trên dự án retail đang chạy, bảng contract chứa 1.2 triệu record vẫn cho query p95 dưới 200ms cho list view 50 dòng và filter 3 trường.

Quản lý hợp đồng số lượng lớn thì hiệu năng thế nào?

OKAXI thiết kế contract management theo command-query responsibility separation (CQRS). Command side ghi vào normalized table cho data integrity. Query side dùng denormalized read model được sync qua Kafka event. Read model có sẵn aggregate (count by status, sum by amount) để dashboard không tính lại từ raw.

Theo dõi nhân sự thị trường thời gian thực chịu tải ra sao?

OKAXI dùng time-series database chuyên dụng (TimescaleDB hoặc InfluxDB) cho sự kiện GPS. Mỗi nhân sự thị trường gửi tín hiệu định vị (ping) mỗi 30 giây qua ứng dụng di động, đẩy về backend qua MQTT hoặc HTTP batch. Backend ghi vào time-series, tự động nén dữ liệu cũ hơn 30 ngày.

Báo cáo từ tập dữ liệu lớn không bị timeout ra sao?

OKAXI tách báo cáo thành ba tier theo độ phức tạp. Tier 1 (real-time dashboard, dưới 1 giây) chạy trên materialized view được refresh mỗi 5 phút. Tier 2 (báo cáo chi tiết, dưới 30 giây) chạy ad-hoc query với streaming cursor. Tier 3 (báo cáo cross-domain heavy, vài phút) chạy qua job queue, kết quả gửi qua email hoặc download link. Người dùng nhận thông báo thay vì chờ UI block.

Lưu trữ và search file đính kèm ra sao?

OKAXI dùng object storage (S3 hoặc S3-compatible) cho file gốc, metadata trên PostgreSQL. File text được index full-text search qua Elasticsearch hoặc PostgreSQL pg_trgm tùy quy mô. PDF tự động extract text qua tika-server và đẩy vào index. Khách hàng search được nội dung trong hơn 50000 file PDF với latency p95 dưới 500ms.

Cơ chế phân quyền của OKAXI hoạt động như thế nào?

OKAXI áp dụng role-based access control (RBAC) kết hợp attribute-based access control (ABAC). RBAC định nghĩa role và quyền tổ chức theo cây phòng ban. ABAC thêm điều kiện runtime, ví dụ chỉ xem hợp đồng của khu vực mình quản lý. Mọi check permission đi qua một central policy engine viết bằng Open Policy Agent (OPA) hoặc Casbin, audit được mọi quyết định cấp quyền.

Có hỗ trợ row-level và field-level permission không?

Có. Row-level: mỗi record có owner_id và scope_id, query tự filter dựa trên context user. Field-level: mỗi form field có visibility rule và editability rule. Một số field nhạy cảm (lương, giá trị hợp đồng) chỉ vai trò người dùng nhất định mới đọc được. Quy tắc phân quyền được định nghĩa khai báo, không cố định cứng trong mã, quản trị viên doanh nghiệp tự sửa được mà không cần OKAXI triển khai lại.

Audit trail lưu vết những gì?

Audit trail ghi sáu chiều thông tin cho mỗi event. Một là actor (ai). Hai là action (làm gì: create, update, delete, view, export). Ba là target (record nào). Bốn là timestamp. Năm là before/after diff (giá trị cũ và mới). Sáu là context (IP, device, session_id). Log lưu immutable trên storage append-only với SHA-256 chain để phát hiện tampering. Compliance reporting export ra CSV hoặc kết nối SIEM khách hàng.

Có hỗ trợ approval workflow nhiều cấp không?

Có. Mỗi loại document có thể gắn approval flow với số cấp tùy ý. Routing rule cấu hình theo amount range, region, department, hoặc custom condition. Mỗi cấp có timeout tự động escalate lên cấp cao hơn. Approver nhận thông báo qua mobile push, email và in-app. Approver có quyền delegate cho người khác trong khoảng thời gian xác định. Lịch sử approval ghi đầy đủ trong audit trail.

API public và webhook ra sao?

OKAXI expose REST và GraphQL API theo chuẩn OpenAPI 3.0 và GraphQL SDL. Mọi resource đều có endpoint CRUD chuẩn hóa và filter theo OData-like syntax. Authentication qua OAuth 2.0 hoặc API key tùy use case. Webhook gửi event với HMAC SHA-256 signature header để khách hàng verify nguồn gốc. Rate limit cấu hình per API key. Documentation auto-generate và publish tại /api/docs với try-it-out trên Swagger UI.

Khả năng thêm tính năng mới sau khi go-live ra sao?

OKAXI thiết kế core theo dạng plugin architecture. Mỗi module nghiệp vụ là một plugin với contract định nghĩa rõ event nào sẽ subscribe, API nào sẽ expose. Tính năng mới triển khai dưới dạng plugin mới mà không cần modify core code. Plugin được enable per tenant qua feature flag. Khách hàng có thể tự phát triển plugin riêng và deploy vào instance của họ qua marketplace nội bộ, OKAXI review và approve security.

Quay lại trang FAQ chính