Nghệ thuật "Alignment" (Sự đồng bộ): Phá vỡ các "ốc đảo thông tin" (Silos) giữa phòng Công nghệ (IT) và phòng Kinh doanh (Business).

Hãy thử một bài kiểm tra đơn giản trong chính công ty của bạn. Hỏi Giám đốc Kinh doanh: "Dự án nền tảng bán hàng mới đang ở đâu?" Rồi hỏi Giám đốc Công nghệ đúng câu đó. Nếu bạn nhận về hai câu trả lời khác nhau — một bên nói "IT làm chậm, thiếu tính năng", một bên nói "Business đổi yêu cầu liên tục, không chốt được scope" — thì bạn không có một vấn đề kỹ thuật. Bạn có một vấn đề về alignment (sự đồng bộ mục tiêu). Và nó đắt hơn bất kỳ dòng chi phí công nghệ nào trong ngân sách của bạn.

Phần lớn các chương trình chuyển đổi số thất bại không phải vì chọn sai công nghệ. Chúng thất bại vì hai bộ phận quan trọng nhất — bên tạo ra doanh thu (Business) và bên xây dựng năng lực số (IT) — vận hành như hai quốc gia có ngôn ngữ riêng, ngân sách riêng, và quan trọng nhất: thước đo thành công riêng và thường xung đột nhau. Đây chính là "silo" — ốc đảo thông tin. Nó không phải một sự cố. Nó là một trạng thái cân bằng mà chính cơ cấu tổ chức và cách bạn phân bổ ngân sách đã cẩn thận tạo ra.

Bài viết này không bàn về "làm việc nhóm tốt hơn" — đó là lời khuyên vô dụng. Nó bàn về việc tại sao silo là kết quả tất yếu của các động lực bạn đang cài đặt, và một C-Level phải tái thiết kế những gì để buộc hai bên đứng cùng một chiến tuyến.

Silo không phải lỗi con người — đó là lỗi thiết kế

Khi một dự án đổ vỡ, phản xạ thường thấy của lãnh đạo là quy về thái độ: "các phòng không chịu hợp tác", "thiếu tinh thần đồng đội". Đây là chẩn đoán sai lầm và tốn kém nhất. Con người trong tổ chức của bạn đa phần đều thông minh và có thiện chí. Họ hành xử theo silo vì hệ thống đang tưởng thưởng cho hành vi silo.

Hãy nhìn vào ba gốc rễ:

Thứ nhất, mục tiêu bộ phận xung đột trực tiếp. Giám đốc Kinh doanh được đánh giá bằng doanh số quý này. Vì vậy mọi yêu cầu của họ là "thêm tính năng, thêm khuyến mãi, thêm ngay". Giám đốc Công nghệ được đánh giá bằng độ ổn định hệ thống, tỷ lệ downtime, và chi phí hạ tầng trong tầm kiểm soát. Vì vậy phản xạ của họ là "làm chậm lại, kiểm thử kỹ, đừng đụng vào cái đang chạy". Cả hai đều đang làm đúng công việc mà bạn giao. Xung đột không nằm ở con người — nó được ghi thẳng vào bảng KPI (chỉ số đánh giá hiệu quả) của họ.

Thứ hai, ngôn ngữ khác nhau. Business nói bằng ngôn ngữ của thị phần, tỷ lệ chuyển đổi, vòng đời khách hàng. IT nói bằng ngôn ngữ của API, nợ kỹ thuật (technical debt), độ trễ, kiến trúc. Khi một bên nói "tôi cần khách hàng thấy giá real-time", bên kia nghe thành "phải viết lại toàn bộ tầng đồng bộ dữ liệu tồn kho" — và không ai dịch khoảng cách đó thành một quyết định đánh đổi rõ ràng. Thông tin không mất đi; nó thất lạc trong dịch thuật.

Thứ ba, cấu trúc ngân sách và cách tổ chức "dự án". Đây là gốc rễ sâu nhất và ít ai đụng tới. Khi bạn phân bổ tiền theo từng "dự án" có ngày bắt đầu và ngày bàn giao, bạn đã vô tình dựng lên bức tường: Business là "khách hàng" đặt hàng, IT là "nhà thầu" giao hàng. Mối quan hệ khách hàng–nhà thầu về bản chất là đối kháng: một bên muốn tối đa hoá phạm vi, một bên muốn tối thiểu hoá cam kết. Bạn không thể yêu cầu hai bên "đứng cùng chiến tuyến" khi mô hình tài chính đặt họ ở hai đầu bàn đàm phán.

GÓC NHÌN C-LEVEL

• Bảng KPI của Giám đốc Kinh doanh và Giám đốc Công nghệ của tôi có ô nào trùng nhau không? Nếu không, tôi đang trả lương cho họ để kéo về hai hướng.
• Chúng tôi đang cấp ngân sách cho "dự án" hay cho "năng lực kinh doanh"? Sự khác biệt này định hình mọi hành vi phía dưới.
• Khi một sáng kiến số thất bại, câu đầu tiên tôi hỏi là "ai sai" hay "thiết kế nào của tổ chức đã khiến kết quả này gần như chắc chắn xảy ra"?
• Ai trong công ty tôi có thể dịch trơn tru giữa ngôn ngữ P&L và ngôn ngữ kiến trúc hệ thống? Nếu câu trả lời là "không ai", đó là một lỗ hổng vai trò, không phải lỗ hổng nhân sự.

Khung tạo Alignment: bốn tầng phải khớp nhau

Alignment không đến từ một buổi teambuilding hay một khẩu hiệu treo tường. Nó là kết quả của bốn tầng thiết kế phải đồng bộ. Thiếu bất kỳ tầng nào, ba tầng còn lại sẽ bị vô hiệu hoá.

Tầng 1 — Shared OKR: một con số, hai chữ ký

Đòn bẩy mạnh nhất và rẻ nhất mà một C-Level có trong tay là thay đổi thước đo. Thay vì để Business chịu trách nhiệm về doanh thu còn IT chịu trách nhiệm về uptime, hãy đặt một kết quả kinh doanh đầu-cuối mà cả hai cùng ký tên. Ví dụ: "Giảm tỷ lệ khách bỏ giỏ hàng từ 70% xuống 55% trong hai quý." Con số này không thuộc về IT hay Business. Nó chỉ đạt được khi cả hai cùng thắng, và cùng thua nếu thất bại. Khoảnh khắc Giám đốc Công nghệ bắt đầu quan tâm đến tỷ lệ chuyển đổi, và Giám đốc Kinh doanh bắt đầu hiểu vì sao nợ kỹ thuật làm chậm mọi thứ — đó là khoảnh khắc silo bắt đầu tan.

Tầng 2 — Đội liên chức năng: phá tường bằng cách xoá tường

Silo được duy trì bằng những bức tường phòng ban. Cách phá không phải là dạy người ta trèo tường, mà là đặt họ chung một phòng. Một đội liên chức năng đúng nghĩa gồm người kinh doanh, kỹ sư, thiết kế, phân tích dữ liệu — cùng chịu trách nhiệm cho một sản phẩm hoặc một hành trình khách hàng, báo cáo về cùng một mục tiêu. Khi một kỹ sư ngồi cạnh người bán hàng và nghe khách phàn nàn mỗi ngày, "yêu cầu" không còn là dòng chữ lạnh lùng trong ticket — nó trở thành vấn đề của chính anh ta.

Tầng 3 — Vai trò cầu nối: người dịch có quyền quyết định

Đây là mắt xích thường bị bỏ quên. Bạn cần một vai trò — thường gọi là Product Owner hoặc Product Manager — đứng ở giao điểm, thông thạo cả hai ngôn ngữ, và quan trọng nhất: có thẩm quyền ra quyết định đánh đổi tại chỗ. Không phải người ghi biên bản chuyển yêu cầu, mà là người có quyền nói "tính năng A quan trọng hơn B, chúng ta làm A trước" mà không cần leo thang lên ban giám đốc. Thiếu vai trò này, mọi bất đồng nhỏ đều bị đẩy lên bàn C-Level, biến lãnh đạo cấp cao thành trọng tài phân xử tranh chấp vặt — một sự lãng phí năng lực điều hành nghiêm trọng.

Tầng 4 — Nhịp điệu: alignment là động từ, không phải danh từ

Alignment không phải trạng thái đạt được một lần rồi giữ mãi. Thị trường đổi, ưu tiên đổi, thông tin mới xuất hiện. Vì vậy cần một nhịp điệu (cadence) cố định: buổi review sản phẩm định kỳ nơi Business và IT cùng nhìn dữ liệu thật, buổi sắp xếp thứ tự ưu tiên backlog theo chu kỳ ngắn. Nhịp điệu biến alignment từ một sự kiện hiếm hoi thành một thói quen vận hành.

Từ "Dự án" sang "Sản phẩm": thay đổi buộc cả hai đứng cùng chiến tuyến

Nếu bạn chỉ được chọn một đòn bẩy duy nhất để phá silo, hãy chọn cái này: dịch chuyển từ mô hình dự án (project) sang mô hình sản phẩm (product). Đây không phải thay đổi từ ngữ. Nó là thay đổi triết lý tài chính và tổ chức tận gốc.

Sự khác biệt cốt lõi nằm ở chữ "bàn giao". Trong mô hình dự án, thành công của IT là bàn giao đúng hạn — và ngay khoảnh khắc bàn giao, trách nhiệm được chuyển sang Business. Nếu sản phẩm không tạo ra doanh thu, đó là "vấn đề của Business". Cấu trúc này định nghĩa thất bại là bình thường: IT có thể "thành công" (giao đúng hạn) trong khi công ty thất bại (sản phẩm không ai dùng).

Trong mô hình sản phẩm, không có điểm bàn giao. Đội sản phẩm — cả kỹ sư lẫn người kinh doanh — chịu trách nhiệm cho kết quả kinh doanh của sản phẩm đó, liên tục, cho đến khi nó tạo ra giá trị. Không còn chỗ để đổ lỗi, vì không còn ranh giới để đổ qua. Đây là lý do các tổ chức số trưởng thành trên thế giới — từ các nền tảng thương mại điện tử lớn đến các ngân hàng số dẫn đầu — đều tổ chức quanh sản phẩm và hành trình khách hàng, không phải quanh phòng ban chức năng. Họ không "phá silo" như một chiến dịch; họ thiết kế một cấu trúc mà silo không có đất để mọc.

Liên hệ thị trường Việt Nam

Ở nhiều doanh nghiệp Việt quy mô vừa và lớn, IT vẫn được đặt dưới khối vận hành hoặc tài chính như một trung tâm chi phí (cost center) — nơi để "xin ngân sách làm hệ thống". Cách đặt để này gần như đảm bảo silo. Khi IT là trung tâm chi phí, mọi đồng chi cho công nghệ là một khoản phải "biện minh", và Business là bên đi "đặt hàng". Bước chuyển thực chất đầu tiên mà một CEO Việt Nam có thể làm không phải là mua thêm phần mềm, mà là tái định vị công nghệ từ trung tâm chi phí thành đối tác tạo giá trị, với những đội sản phẩm ổn định được cấp vốn theo kết quả kinh doanh. Điều này khó, vì nó đụng đến quyền lực, ngân sách và cái tôi phòng ban — chính vì thế nó là việc của C-Level, không thể uỷ quyền xuống dưới.

Vai trò không thể uỷ quyền của C-Level

Alignment là bài toán quyền lực và cấu trúc, nên nó chỉ có thể được giải từ trên xuống. Cấp trung không thể tự phá silo vì chính họ là sản phẩm của những bức tường đó. Có ba việc chỉ C-Level làm được:

Một, dỡ bỏ các động lực gây silo. Hãy soi lại hệ thống thưởng, KPI, và cả những "phần thưởng ngầm" (ai được thăng chức, ai được khen trong họp giao ban). Nếu bạn vẫn khen thưởng người "bảo vệ được ngân sách phòng mình" hay "giao dự án đúng hạn bất kể kết quả", bạn đang bơm nhiên liệu cho silo trong khi miệng kêu gọi hợp tác. Nhân viên tin vào những gì được tưởng thưởng, không phải những gì được rao giảng.

Hai, tái thiết kế cơ cấu tổ chức và dòng ngân sách theo giá trị đầu-cuối. Chuyển từ cấp vốn theo dự án sang cấp vốn theo sản phẩm hoặc theo hành trình khách hàng. Đây là hành động có sức nặng nhất, vì tiền định hình hành vi mạnh hơn mọi bài diễn thuyết về văn hoá. Khi bạn cấp vốn cho một "năng lực kinh doanh sống" thay vì một "gói tính năng bàn giao", bạn buộc IT và Business phải cùng sở hữu kết quả.

Ba, làm gương và bảo vệ vai trò cầu nối. Vai trò Product Owner chỉ có thực quyền nếu C-Level công khai trao và bảo vệ nó. Nếu mỗi lần Business không hài lòng lại gọi thẳng cho CEO để vượt mặt, vai trò cầu nối sẽ chết yểu. Alignment ở tầng dưới chỉ tồn tại nếu alignment ở tầng ban lãnh đạo là thật — nếu Giám đốc Kinh doanh và Giám đốc Công nghệ của bạn thực sự chia sẻ mục tiêu, chứ không phải cùng gật đầu trong phòng họp rồi ai về phe nấy.

Kết: Alignment là điều kiện tiên quyết, không phải điểm cộng

Silo là kẻ thù số một của chuyển đổi số không phải vì nó gây khó chịu, mà vì nó âm thầm định nghĩa thất bại là kết quả mặc định. Nó khiến mỗi bộ phận có thể "thành công" theo thước đo riêng trong khi cả công ty thất bại theo thước đo duy nhất quan trọng: giá trị tạo ra cho khách hàng và cho P&L.

Bạn không phá silo bằng cách kêu gọi mọi người tử tế với nhau hơn. Bạn phá nó bằng cách thay đổi bốn thứ bạn kiểm soát: thước đo chung, cấu trúc đội ngũ, vai trò cầu nối, và trên hết là dòng ngân sách chảy theo giá trị đầu-cuối thay vì theo dự án bàn giao. Đó là công việc thiết kế lại tổ chức — và nó nằm trọn trong tầm tay của C-Level.

Câu hỏi cuối cùng để suy ngẫm không phải "làm sao để IT và Business hợp tác tốt hơn". Mà là: nếu tôi thiết kế lại công ty từ đầu quanh giá trị mang lại cho khách hàng — thay vì quanh các phòng ban tôi thừa hưởng — thì tổ chức đó trông ra sao? Khoảng cách giữa hình dung đó và thực tại hôm nay chính là bản đồ công việc alignment của bạn.

Bài trước: Execution Plan 6–12 tháng · Bài tiếp theo: Quản trị sự thay đổi