Chuyển đổi số: Đừng để công nghệ chạy trước tư duy

Một số điểm đáng suy ngẫm

Mới đây, nguyên Bộ trưởng Bộ TT&TT Nguyễn Mạnh Hùng [1] đã chỉ ra một thực trạng mà nhiều người làm trong ngành đều thấy nhưng ít ai nói thẳng: không ít doanh nghiệp (DN) Việt Nam đầu tư rất lớn cho chuyển đổi số (CĐS) nhưng hiệu quả thấp.

Những biểu hiện quen thuộc đến mức gần như thành “mẫu số chung”. Hệ thống được nghiệm thu, lễ khánh thành diễn ra đúng kế hoạch, nhưng nhân viên vẫn lặng lẽ quay về với bảng tính quen thuộc. Dữ liệu được thu thập ngày một nhiều, kho dữ liệu ngày một lớn, nhưng các quyết định quan trọng vẫn được đưa ra bằng kinh nghiệm và cảm tính. Trí tuệ nhân tạo (AI) được đưa nhiều vào báo cáo nhưng ứng dụng còn chưa sâu rộng.

Khi một khoản đầu tư lớn chưa hoàn toàn làm thay đổi cách tổ chức vận hành, ta buộc phải đặt câu hỏi: cái đã được chuyển đổi rốt cuộc là gì?

Kết quả chưa đạt không phải đặc sản của riêng ai

Nếu chỉ nhìn trong nước, dễ cho là năng lực hay trình độ nhân lực. Nhưng nhìn rộng ra, bức tranh công bằng hơn: những điểm chưa thành công trên con đường này là chuyện của cả thế giới.

Nhiều tập đoàn toàn cầu, với nguồn lực tài chính và nhân tài vượt xa phần lớn DN Việt, cũng từng đổ hàng trăm triệu, thậm chí hàng tỷ USD cho các tham vọng số mà không đạt kỳ vọng. General Electric (GE), tập đoàn đa quốc gia của Mỹ, từng định vị mình thành một “công ty phần mềm công nghiệp” với nền tảng Predix, nhưng tham vọng ấy sau đó phải thu hẹp đáng kể. Hãng sản xuất ô tô Ford (Mỹ) từng công bố chiến lược Smart Mobility (di chuyển thông minh) để chuyển mình từ nhà sản xuất ô tô thành nhà cung cấp dịch vụ di chuyển, nhưng sau nhiều năm và những khoản đầu tư lớn, hãng buộc phải điều chỉnh mạnh hướng đi.

Bài học rút ra không phải là “chuyển đổi số không đáng làm”. Bài học là: tiền và công nghệ, tự thân chúng, không bảo đảm được thành công. Có thứ gì đó đứng giữa khoản đầu tư và giá trị thực, và thứ đó chính là cách chúng ta nghĩ về việc mình đang làm.

Gốc rễ: nhầm lẫn giữa tin học hóa và chuyển đổi số

Sai lầm phổ biến nhất mà đa số các quốc gia thế giới gặp phải, là bộ máy còn cồng kềnh, quy trình thủ công cũ kỹ, rồi “phủ” công nghệ lên trên như một lớp sơn mới. Cần phải phân biệt rõ giữa tin học hoá và CĐS.

Tin học hóa (digitization, automation) là đưa công việc cũ lên máy tính. Đơn xin phép từ giấy thành biểu mẫu điện tử, sổ sách từ tay sang phần mềm. Điều này có ích, nhưng nó không thay đổi bản chất của công việc. Một quy trình rườm rà qua nhiều tầng phê duyệt, khi được số hóa, chỉ trở thành một quy trình rườm rà chạy trên máy tính, thậm chí còn khó sửa hơn vì giờ nó đã được “đóng cứng” vào phần mềm.

Chuyển đổi số (digital transformation) thì khác về chất. Đó là tái cấu trúc mô hình kinh doanh, thiết kế lại cách tạo ra và phân phối giá trị, thay đổi kiến trúc vận hành, và quan trọng nhất là thay đổi cách tổ chức ra quyết định. Công nghệ ở đây là công cụ, còn mục tiêu là một tổ chức vận hành theo cách mới, nhanh hơn, chính xác hơn, gần khách hàng hơn.

Sự khác biệt này không phải chuyện học thuật. Nó quyết định DN bắt đầu từ đâu. Người nghĩ mình đang tin học hóa sẽ bắt đầu bằng việc mua phần mềm. Người hiểu mình đang chuyển đổi sẽ bắt đầu bằng câu hỏi: quy trình nào đang cản trở giá trị, và nếu làm lại từ đầu thì ta sẽ làm thế nào?

Thay đổi phương pháp phát triển công nghệ thông tin (CNTT)

Nhận diện đúng vấn đề mới là một nửa chặng đường. Nửa còn lại là thay đổi phương pháp. Có ba trụ cột kỹ thuật và tư duy mà tổ chức, DN cần cân nhắc nghiêm túc.

Kiến trúc microservices: nâng cấp từng phần, không đập đi xây lại

Trong nhiều năm, cách làm quen thuộc là mua một hệ thống nguyên khối (monolithic) như ERP hay CRM truyền thống: một gói lớn, đắt đỏ, bao trùm mọi nghiệp vụ. Ưu điểm là trọn gói. Nhược điểm là cứng nhắc, muốn thay đổi một chức năng nhỏ, DN phải can thiệp vào cả khối, chịu chi phí tùy biến cao và đối mặt rủi ro ảnh hưởng dây chuyền.

Kiến trúc microservices (hay kiến trúc vi dịch vụ) đi theo hướng ngược lại: chia hệ thống thành các dịch vụ nhỏ, độc lập, mỗi dịch vụ đảm nhiệm một nghiệp vụ cụ thể và giao tiếp với nhau qua các chuẩn kết nối. Theo đó, cần cải tiến phần nào, nâng cấp phần đó. Một dịch vụ lỗi không kéo sập cả hệ thống. DN có thể thử nghiệm, thay thế từng mảnh mà không phải “đặt cược” toàn bộ vào một quyết định mua sắm duy nhất. Với những tổ chức đang trong giai đoạn tìm đường, khả năng thay đổi chi phí thấp này có giá trị hơn nhiều so với sự trọn gói.

Cần nói công bằng rằng microservices không phải thuốc chữa bách bệnh. Nó đòi hỏi năng lực kỹ thuật và kỷ luật quản trị cao hơn, và không phải DN nào cũng cần chia nhỏ đến mức đó. Nhưng như một hướng tư duy, ưu tiên sự linh hoạt và khả năng thay đổi hơn sự đồ sộ, đây là điều cần được cân nhắc trước mỗi quyết định đầu tư.

Cloud native: dùng bao nhiêu, trả bấy nhiêu

Mô hình đầu tư hạ tầng truyền thống buộc DN phải chi một khoản lớn ngay từ đầu cho máy chủ, trung tâm dữ liệu, đội vận hành, trong khi chưa biết chắc nhu cầu thực tế sẽ ra sao. Đó thực sự là một khoản đầu tư lớn nếu dự án chưa như kỳ vọng.

Nền tảng cloud native (hay điện toán đám mây nguyên bản) thay đổi bài toán này. DN mở rộng hay thu hẹp quy mô theo nhu cầu thực, trả tiền theo mức sử dụng (pay-as-you-go), và không phải gánh áp lực hạ tầng phần cứng ban đầu. Quan trọng hơn, cloud native giảm chi phí của việc thử và sai. Khi thử nghiệm một ý tưởng chỉ tốn một phần nhỏ so với trước, tổ chức dám thử nhiều hơn, học nhanh hơn, và dừng sớm hơn những hướng đi không hiệu quả.

Phát triển tinh gọn: đừng mất ba năm để biết không ai dùng

Mô hình “thác nước” (waterfall) từng là cách làm chủ đạo: khảo sát kỹ, thiết kế trọn vẹn, xây dựng toàn bộ, rồi mới đưa vào vận hành. Với những hệ thống đồ sộ, quá trình này có thể kéo dài 2 đến 3 năm. Đến khi hệ thống ra mắt, nhu cầu thực tế đã đổi, người dùng không còn thấy phù hợp, và kết cục quen thuộc là hệ thống nằm đó mà không ai dùng.

Phương pháp phát triển tinh gọn (agile, fast-to-market) đảo ngược logic này. Thay vì chờ hoàn hảo, hãy tung ra những tính năng nhỏ, đưa đến tay người dùng thật, quan sát họ dùng ra sao, đo bằng dữ liệu thực tế, rồi điều chỉnh. Mỗi vòng lặp ngắn là một lần kiểm chứng giả định. Sai thì sai sớm, sai rẻ, sửa kịp. Quan trọng nhất, người dùng được tham gia ngay từ đầu, nên họ không còn là đối tượng bị “áp” hệ thống lên, mà là người cùng định hình nó. Đây cũng chính là liều thuốc cho căn bệnh “nhân viên vẫn dùng Excel”.

Yếu tố con người: nơi mọi kế hoạch được thử thách

Không thể bàn về CĐS mà bỏ qua vai trò của lãnh đạo và văn hóa tổ chức. Phương pháp hiện đại sẽ vô dụng nếu người đứng đầu coi CĐS là việc của phòng CNTT, giao khoán rồi chờ nghiệm thu. CĐS liên quan đến cách phân quyền, cách đo lường hiệu quả, cách chia sẻ dữ liệu giữa các phòng ban, và những thứ đó không phần mềm nào tự thay đổi được. Chúng chỉ thay đổi khi lãnh đạo trực tiếp dẫn dắt và dám điều chỉnh cả những thói quen, quyền lợi đã thành nếp.

Tương tự, nếu quyết định vẫn được đưa ra theo cảm tính thì kho dữ liệu lớn đến đâu cũng chỉ là một khoản chi phí lưu trữ. Dữ liệu chỉ có giá trị khi có người cần nó để quyết định, và có cơ chế buộc quyết định phải dựa trên nó.

Kết luận

CĐS không phải cuộc đua sở hữu công nghệ, để báo cáo. CĐS là một phương pháp vận hành và phát triển giúp tổ chức liên tục thích ứng, tối ưu nguồn lực và tạo ra giá trị mới.

Công nghệ chưa bao giờ là mục đích cuối cùng. Khi DN làm chủ được phương pháp phát triển hiện đại, đủ dũng khí để tái cấu trúc quy trình theo hướng tinh gọn, và có lãnh đạo thực sự dẫn dắt, CĐS mới thôi là khoản chi “ngốn tiền” để trở thành năng lực cạnh tranh cốt lõi. Câu hỏi mà mỗi tổ chức nên đặt ra trước mỗi dự án không phải là “ta sẽ mua công nghệ gì”, mà là “ta sẽ làm việc khác đi như thế nào”./.

“

Tài liệu tham khảo

[1] Nguyễn Mạnh Hùng (2026), Vì sao doanh nghiệp chuyển đổi số thất bại, nguyên Bộ trưởng nêu cách giải”, https://dantri.com.vn/kinh-doanh/vi-sao-doanh-nghiep-chuyen-doi-so-that-bai-nguyen-bo-truong-neu-cach-giai-20260923082429802.htm, truy cập ngày 22/9/2026.