Tech Talks: 3 trụ cột phá vỡ data silos trong doanh nghiệp

Dữ liệu phân mảnh không phải lỗi của công nghệ; đó là hệ quả của một thiết kế tổ chức lỗi thời. Tại Tech Talks, Ms. Nguyễn Ngọc Thảo Hiếu (EY Vietnam) chỉ ra rằng các tập đoàn đang vô tình dùng ‘Customization’ để đóng băng sự phức tạp thay vì giải quyết nó. Để phá vỡ các ốc đảo dữ liệu (Data Silos), doanh nghiệp cần một cuộc đại tu đồng bộ trên cả ba mặt trận: Quy trình – Con người – Công nghệ.

Từ kinh nghiệm hàng trăm dự án enterprise, chị cũng cảnh báo về “cái bẫy customization” – khi các tập đoàn vô tình đóng băng độ phức tạp vào hệ thống thay vì giải quyết nó. Bài viết tổng hợp những insight cốt lõi về dữ liệu phân mảnh (data silos), customization và nguyên tắc thiết kế hệ thống enterprise trong thời đại số.

Theo chị, đâu là mối quan hệ giữa quy mô tổ chức và độ phức tạp của hệ thống?

Có một nghịch lý của quy mô: càng lớn mạnh, càng phân mảnh. Sai lầm phổ biến của lãnh đạo là tin rằng mở rộng quy mô sẽ đi kèm với tích hợp hệ thống. Thực tế, dữ liệu cho thấy một kịch bản tàn khốc hơn: Khi doanh nghiệp vượt ngưỡng 200 nhân sự, số lượng ứng dụng tăng vọt 105% (từ 42 lên 86). Đà “phình to” này không dừng lại; ở các tập đoàn trên 5.000 nhân viên, hệ thống trở thành một mê cung với trung bình 158 ứng dụng độc lập. Quy mô không tự sinh ra sự tinh gọn, nó chỉ nhân bản sự phức tạp.

Điều này có nghĩa là mỗi phòng ban, mỗi khu vực địa lý, mỗi đơn vị kinh doanh lại có nhu cầu riêng. Số lượng công cụ phình to theo cấp số nhân. Một tập đoàn có 22 pháp nhân, hoạt động tại 4 quốc gia, phục vụ 10 ngành công nghiệp sẽ cần quản lý 150 quy trình, 101 điểm tích hợp – tất cả trong một dự án kéo dài 11 tháng triển khai.

Tôi ví von các hệ thống legacy với những tòa “lâu đài đá” – kiên cố nhưng khó thay đổi và mở rộng. Trong khi đó, các hệ thống agile giống như những “khối lego” – linh hoạt và có thể tháo lắp.

Như vậy, quy mô không chỉ là vấn đề về số lượng người dùng, mà về số lượng điểm kết nối và sự phụ thuộc lẫn nhau giữa các hệ thống. Đây là khởi đầu của những vấn đề về data silos sau này.

Dữ liệu phân mảnh (data silos) thực chất là gì?

Phần lớn các nhà quản trị vẫn tin rằng data silos là một vấn đề kỹ thuật – do hệ thống cũ, thiếu tích hợp, hoặc cơ sở dữ liệu không tương thích. Tuy nhiên, theo nghiên cứu trên hàng trăm doanh nghiệp, các nguyên nhân được phân bố như sau:

Ở cấp độ quy trình: 65% doanh nghiệp có quy trình bị phân mảnh, trong khi 55% không có người chịu trách nhiệm cho quy trình đầu-cuối (end-to-end). Điều này có nghĩa là các quy trình được thiết kế theo từng phòng ban riêng lẻ, không theo luồng nghiệp vụ hoàn chỉnh.

Về khía cạnh con người: 63% tổ chức có tư duy phòng ban (department-centric mindset) – mỗi phòng ban tối ưu KPI riêng mà không nhìn tổng thể. 40% thiếu kỹ năng cũng như nhận thức về dữ liệu, các team có xu hướng bảo vệ data như quyền lực hoặc lãnh thổ của riêng mình.

Ở tầng công nghệ: Con số ấn tượng nhất là 75% doanh nghiệp thiếu tích hợp giữa các hệ thống, trong khi 47% còn sử dụng các hệ thống legacy. Đây là hệ quả trực tiếp của việc mỗi phòng ban tự chọn công cụ riêng mà không có kiến trúc tổng thể. Kết quả là CRM không nói chuyện được với ERP, ERP không đồng bộ với hệ thống quản lý kho, và phần mềm kế toán lại ở một hệ sinh thái hoàn toàn khác.

Có thể thấy, data silos không phải là vấn đề về dữ liệu – đó là vấn đề về thiết kế quy trình, hành vi tổ chức và kiến trúc hệ thống. Nếu chỉ sửa tầng dữ liệu mà bỏ qua yếu tố quy trình và con người, data silos sẽ quay lại ở một nền tảng công nghệ mới hơn.

Vậy làm thế nào để giải quyết data silos một cách toàn diện?

Vì vấn đề có ba chiều, cách can thiệp cũng phải có ba chiều. Về process, tôi luôn nhấn mạnh: sửa flow trước tiên. Điều này có nghĩa là thiết kế lại quy trình theo hướng đầu-cuối (end-to-end), không theo phòng ban, giảm các biến thể (variants) và ngoại lệ (exceptions) không cần thiết, đồng thời giao quyền sở hữu (ownership) rõ ràng cho toàn bộ chuỗi quy trình.

Về people, cần thực thi trách nhiệm và quyền sở hữu một cách nghiêm túc. Điều này bao gồm định nghĩa rõ ràng ai sở hữu và quản lý dữ liệu nào, thực thi quản trị dữ liệu (data governance) – không chỉ định nghĩa trên giấy, quan trọng hơn, biến chất lượng cũng như việc chia sẻ dữ liệu thành trách nhiệm của ban lãnh đạo, không phải chỉ của IT. Tôi từng thấy nhiều tổ chức có khung quản trị dữ liệu đẹp đẽ nhưng không ai tuân thủ. Dữ liệu không phải là quyền lực hay lãnh địa cá nhân – đó là tài sản chung phải được chia sẻ.

Về technology, cần đơn giản hóa kiến trúc một cách có hệ thống. Điều này đòi hỏi xác định rõ hệ thống nào là “hệ thống ghi nhận” (system of record) cho từng lĩnh vực dữ liệu, chuyển từ tích hợp point-to-point sang lớp tích hợp có thể mở rộng, tăng cường kiến trúc doanh nghiệp và quản trị tích hợp, và hạn chế tùy biến (customization).

Điều tôi học được qua nhiều năm là: can thiệp data silos trong tập đoàn lớn đòi hỏi nhiều hơn công nghệ – cần thay đổi cách thiết kế tổ chức, cách con người làm việc, và cách tổ chức hệ thống. Ba chiều này phải được can thiệp cùng lúc, không thể tách rời.

Tại sao customization lại trở thành “cái bẫy” phổ biến khi mở rộng quy mô?

Customization thường được coi là “con đường nhanh nhất” để giải quyết vấn đề trước mắt – nhưng thực chất nó đang đóng băng độ phức tạp thay vì giải quyết nó.

Từ góc độ quy trình, doanh nghiệp customization để bảo tồn các biến thể và ngoại lệ hiện có, tránh thiết kế lại quy trình phức tạp và tốn thời gian, điều chỉnh theo các quy trình được tích lũy qua nhiều năm tăng trưởng.

Từ góc độ con người, customization được sử dụng để bảo vệ cách làm việc hiện tại, thỏa mãn nhiều bên liên quan với các loại yêu cầu mâu thuẫn, tránh thay đổi nhiều trong tổ chức.

Từ góc độ công nghệ, customization được sử dụng để bù đắp cho hệ thống phân mảnh, lấp khoảng trống do vấn đề tích hợp và dữ liệu, cung cấp chức năng ngắn hạn dưới áp lực thời gian. Đây là đánh đổi sự linh hoạt ngắn hạn lấy sự cứng nhắc dài hạn.

Hậu quả của customization lan tỏa qua cả ba tầng. Ở cấp độ quy trình, độ phức tạp của quy trình được mã hóa cứng (hard-coded) vào hệ thống, các ngoại lệ biến thành quy tắc vĩnh viễn, và việc chuẩn hóa đầu-cuối ngày càng khó khăn. Ở cấp độ con người, trách nhiệm cải tiến dịch chuyển khỏi phòng ban chuyên môn, người dùng kỳ vọng hệ thống phải thích ứng thay vì bản thân họ, đồng thời làm suy giảm kỷ luật trong tổ chức. Ở cấp độ công nghệ, độ phức tạp kiến trúc và nợ kỹ thuật (technical debt) tăng lên, nâng cấp và thay đổi trở nên chậm hơn và rủi ro hơn.

Vậy khi nào thì customization là quyết định chiến lược đúng đắn?

Tôi không phủ nhận hoàn toàn customization, nhưng tôi có một nguyên tắc rất rõ ràng: Customization nên được giới hạn ở 20% và chỉ dành cho các năng lực có giá trị cao, tạo sự khác biệt cạnh tranh, và được sử dụng thường xuyên.

Để cụ thể hơn, về mặt quy trình, customization có ý nghĩa khi có yêu cầu tuân thủ pháp lý mà không thể chuẩn hóa được. Ví dụ, quy định thuế ở mỗi quốc gia khác nhau, hoặc tiêu chuẩn ngành có tính đặc thù riêng. Customization cũng hợp lý khi nó hỗ trợ cấp doanh nghiệp – không phải chỉ vì một phòng ban muốn giữ cách làm quen thuộc. Quan trọng là phải chứng minh được rằng đã thử đơn giản hóa quy trình nhưng thực sự không khả thi.

Về mặt con người, customization chỉ nên được phép khi có người chịu trách nhiệm rõ ràng cho quyết định này. Phải có cơ chế quản trị để đảm bảo customization không phát triển tràn lan không kiểm soát. Lãnh đạo cấp cao cũng phải hiểu và chấp nhận rõ ràng tác động dài hạn – không phải chỉ ký duyệt vì áp lực ngắn hạn.

Về mặt công nghệ, trước khi customization, phải đánh giá kỹ tác động đến toàn bộ kiến trúc hệ thống.

Customization này có làm mất khả năng nâng cấp hệ thống cốt lõi không? Chi phí bảo trì lâu dài là bao nhiêu?

Những câu hỏi này phải được trả lời trước, không phải sau khi đã triển khai.

Customization không phải là xấu – nó xấu khi được sử dụng như phản ứng mặc định thay vì ngoại lệ được cân nhắc kỹ. Hãy hỏi bản thân: “Đây có phải là năng lực cốt lõi tạo lợi thế cạnh tranh?” Nếu không, hãy chuẩn hóa.
Làm thế nào để tránh customization không cần thiết?

Tôi có ba nguyên tắc thực hành mà tôi luôn áp dụng trong mọi dự án. Thứ nhất, về quy trình: chuẩn hóa trước khi customize. Điều này có nghĩa là chuẩn hóa quy trình đầu-cuối, không phải theo phòng ban, áp dụng thực tiễn tốt nhất của ngành thay vì bảo tồn các biến thể cũ, và thách thức các ngoại lệ trước khi chấp nhận chúng là yêu cầu. Nguyên tắc vàng của tôi: nếu quy trình có thể được chuẩn hóa, nó không nên được tùy biến.

Thứ hai, về con người: dẫn dắt thay đổi, đừng né tránh. Điều này bao gồm giải quyết các yêu cầu customization thông qua quản lý thay đổi (change management), không phải cấu hình hệ thống (configuration), trang bị cho nhân viên để họ chấp nhận các quy trình mới thay vì bảo tồn thói quen cũ, và biến việc áp dụng quy trình thành trách nhiệm của lãnh đạo.

Thứ ba, về công nghệ: sử dụng đúng mục đích của mỗi hệ thống. Điều này đòi hỏi định nghĩa rõ vai trò của mỗi hệ thống trong bối cảnh tổng thể, giữ hệ thống cốt lõi sạch và ổn định, và tích hợp các hệ thống vệ tinh (satellite systems) để xử lý nhu cầu chuyên biệt thay vì tùy biến hệ thống cốt lõi. Đừng ép một hệ thống phải làm mọi thứ.

Kết

Phần chia sẻ của chị Nguyễn Ngọc Thảo Hiếu đã vạch ra một chân lý quan trọng: công nghệ tốt nhất không thể bù đắp cho thực tiễn ra quyết định kém. Các tập đoàn lớn với ngân sách không giới hạn vẫn vật lộn với data silos không phải vì thiếu công cụ, mà vì thiếu kỷ luật tổ chức.

Như chị Hiếu đã nhấn mạnh: “Nếu bạn chỉ sửa tầng kỹ thuật mà không sửa quy trình và con người, data silos sẽ quay lại, chỉ khác là ở một nền tảng công nghệ mới hơn.” Đây không chỉ là bài học về MIS – đây là bài học về chuyển đổi tổ chức trong thời đại số.

Tech Talks là series quy tụ các chuyên gia công nghệ chia sẻ xu hướng chuyển đổi số, phân tích các rào cản kỹ thuật trong doanh nghiệp và chuyển hóa thành giải pháp công nghệ tối ưu theo triết lý đào tạo của PSO – Problem Solving in Organization.