INFOCHIEF ACADEMY · IT MANAGER KNOWLEDGE SERIES

IT và các phòng ban bất đồng: Chuyển tranh luận kỹ thuật thành mục tiêu chung

Khi IT và phòng ban bất đồng, trưởng phòng cần đưa tranh luận về mục tiêu, rủi ro và lựa chọn kinh doanh thay vì hơn thua về giải pháp kỹ thuật.

Biên soạn: Infochief Academy · Chuyên đề: Trưởng phòng IT chuyên nghiệp – IT Manager

← Trở về danh mục IT Manager

Minh họa biên tập: IT và các phòng ban chuyển bất đồng từ giải pháp kỹ thuật sang lựa chọn dựa trên mục tiêu và rủi ro kinh doanh.

Phần nổi của xung đột thường là công nghệ, phần chìm là mục tiêu và rủi ro

Marketing muốn triển khai nhanh một nền tảng mới; IT lo bảo mật và tích hợp. Tài chính muốn giảm chi phí; IT muốn thay thiết bị đã cũ. Vận hành cần thay đổi hệ thống ngay; IT yêu cầu thêm thời gian kiểm thử. Những cuộc tranh luận này thường được diễn đạt bằng ngôn ngữ kỹ thuật, nhưng nguyên nhân sâu hơn là các bên đang tối ưu những mục tiêu khác nhau.

Nếu IT Manager chỉ chứng minh “giải pháp của IT đúng hơn”, xung đột dễ leo thang. Cách hữu ích hơn là làm rõ mục tiêu chung, rủi ro mà mỗi bên đang cố bảo vệ và trade-off mà doanh nghiệp phải chấp nhận. Khi mục tiêu được đặt lên trước giải pháp, nhiều bất đồng kỹ thuật chuyển thành lựa chọn quản trị có thể so sánh.

Khung quản trị IT như ISO/IEC 38500 nhấn mạnh direction, capability, policy, delegation, performance và accountability — một gợi ý quan trọng rằng quyết định IT cần gắn với cơ chế trách nhiệm của tổ chức, không chỉ nằm trong phòng kỹ thuật.

Tách “vị trí” khỏi “lợi ích” để nhìn đúng vấn đề

Trong xung đột, vị trí là điều một bên nói họ muốn: “phải dùng SaaS này”, “phải chặn”, “phải go-live tuần sau”. Lợi ích là lý do phía sau: “cần kịp chiến dịch”, “cần bảo vệ dữ liệu”, “cần giảm chi phí”, “cần tránh trễ cam kết với khách hàng”.

IT Manager nên hỏi ba câu: mục tiêu kinh doanh nào đang được bảo vệ, rủi ro nào không thể chấp nhận và mức linh hoạt còn lại là gì. Khi hai bên thấy lợi ích của nhau, có thể xuất hiện phương án thứ ba mà ban đầu không ai đề xuất: triển khai phạm vi hẹp, dùng dữ liệu giả, tách tích hợp nhạy cảm, hoặc chấp nhận giải pháp tạm với thời hạn rõ.

PMI xem xung đột là điều bình thường trong môi trường dự án và nhấn mạnh việc làm rõ mục đích cùng quá trình hợp tác để giải quyết. IT Manager nên coi bất đồng là dữ liệu về mục tiêu và ràng buộc, không phải bằng chứng rằng một bên “không hợp tác”.

Dịch rủi ro kỹ thuật thành tác động mà phòng ban có thể cân nhắc

Một lỗi phổ biến của IT là dùng ngôn ngữ kỹ thuật để thuyết phục người không chịu trách nhiệm kỹ thuật. “Thiếu MFA”, “không có rollback”, “API chưa rate-limit” có thể đúng nhưng chưa nói rõ doanh nghiệp sẽ đối mặt điều gì.

Ngôn ngữ kỹ thuật	Dịch sang câu hỏi kinh doanh	Lựa chọn quản trị
Chưa có MFA	Nguy cơ tài khoản bị chiếm và dữ liệu bị truy cập trái phép?	Chặn, giới hạn phạm vi hoặc chấp nhận có thời hạn
Không có rollback	Nếu triển khai lỗi, thời gian phục hồi và ảnh hưởng khách hàng là gì?	Hoãn hoặc tạo phương án khôi phục
Tích hợp chưa kiểm thử tải	Rủi ro gián đoạn trong giờ cao điểm?	Giới hạn lưu lượng hoặc pilot

Khi IT diễn đạt rủi ro dưới dạng tác động và lựa chọn, phòng ban có thể tham gia quyết định. Điều này cũng giảm cảm giác IT là “bộ phận nói không”.

Thiết lập decision rights: ai được quyết định, ai phải được tham vấn

Nhiều xung đột kéo dài vì không ai rõ ai có quyền quyết định cuối cùng. IT chịu trách nhiệm an toàn kỹ thuật, nhưng chủ quy trình chịu trách nhiệm kết quả nghiệp vụ; tài chính chịu trách nhiệm ngân sách; lãnh đạo chịu trách nhiệm chấp nhận rủi ro ở mức tổ chức.

IT Manager nên xác định decision rights cho các quyết định thường gặp: thay đổi mức dịch vụ, chấp nhận rủi ro, lựa chọn nhà cung cấp, thay đổi kiến trúc, ưu tiên backlog, ngoại lệ chính sách. Có thể dùng RACI hoặc ma trận quyền quyết định đơn giản, nhưng mục tiêu là tránh tình trạng “mọi người cùng góp ý nên không ai chịu trách nhiệm”.

Khi cần nâng năng lực về phân quyền và phối hợp, chương trình Trưởng Phòng IT Chuyên Nghiệp – IT Manager và Quản Lý Giám Sát IT – IT Supervisor cung cấp nền tảng phù hợp cho quản lý tuyến giữa và trưởng nhóm.

Quy trình 6 bước cho một cuộc trao đổi khó

Khi cuộc họp bắt đầu căng thẳng, IT Manager có thể dùng một cấu trúc ngắn để tránh tranh luận vòng tròn:

Chốt mục tiêu chung: ví dụ bảo đảm chiến dịch chạy đúng ngày mà rủi ro dữ liệu nằm trong mức chấp nhận.
Tách dữ kiện khỏi giả định: điều gì đã xác minh, điều gì mới là lo ngại.
Nêu ràng buộc: thời gian, chi phí, policy, kỹ thuật, pháp lý.
Đề xuất tối thiểu hai lựa chọn: cùng trade-off rõ ràng.
Xác định người quyết định: ai có quyền chấp nhận rủi ro hoặc thay đổi ưu tiên.
Ghi quyết định và điều kiện: phạm vi, owner, deadline, review point.

Nếu vấn đề là thiết kế giải pháp hoặc xử lý vấn đề kỹ thuật phức tạp, có thể liên kết thêm Giải Quyết Vấn Đề & Tìm Giải Pháp IT để chuẩn hóa cách phân tích phương án và lựa chọn giải pháp.

Tình huống minh họa: marketing muốn mua SaaS trước chiến dịch

Tình huống giả định: phòng Marketing muốn ký một SaaS mới trong hai tuần để kịp chiến dịch. IT phát hiện nhà cung cấp chưa trả lời đầy đủ câu hỏi bảo mật và muốn hoãn. Marketing cho rằng IT “cản trở kinh doanh”.

Thay vì tranh luận “an toàn hay tốc độ”, IT Manager cùng Marketing xác định mục tiêu: công cụ phải hỗ trợ chiến dịch đúng lịch và không đưa dữ liệu khách hàng nhạy cảm vào rủi ro không kiểm soát. Ba lựa chọn được đưa ra: hoãn toàn bộ; triển khai đầy đủ và chấp nhận rủi ro; hoặc pilot phạm vi giới hạn với dữ liệu không nhạy cảm trong khi hoàn thành đánh giá nhà cung cấp.

Phương án thứ ba có thể không hoàn hảo nhưng tạo trade-off có chủ sở hữu. Nếu lãnh đạo chọn nó, decision log ghi rõ phạm vi, thời hạn, người chấp nhận rủi ro và điều kiện mở rộng. IT không còn là người “thắng” hay “thua”; IT đã giúp doanh nghiệp ra quyết định có thông tin.

Phòng ngừa xung đột bằng cơ chế quan hệ, không chỉ kỹ năng mềm

Một IT Manager giỏi giao tiếp vẫn sẽ gặp xung đột nếu cơ chế hợp tác kém. Hãy tạo các điểm tiếp xúc định kỳ với phòng ban: service review, planning quý, backlog review, kiến trúc/đầu tư review và các kênh escalation rõ ràng.

Khi nhu cầu được nhìn thấy sớm, nhiều xung đột biến mất trước khi trở thành “việc gấp”. Khi tiêu chí ưu tiên được thống nhất, phòng ban ít cảm thấy IT tùy ý. Khi service catalogue rõ, tranh cãi về phạm vi trách nhiệm giảm. Vì vậy, quản lý quan hệ phải gắn với cơ chế vận hành, không chỉ dựa vào thiện chí cá nhân.

Tư duy Quản Lý Dịch Vụ IT – ITSM đặc biệt hữu ích vì nó đặt dịch vụ, giá trị và quan hệ với người dùng vào cùng một hệ thống quản lý thay vì xem từng ticket là giao dịch rời rạc.

Checklist chuyển tranh luận thành quyết định chung

Trước khi escalation một bất đồng, IT Manager nên kiểm tra:

Hai bên đã thống nhất mục tiêu kinh doanh chung chưa?
Dữ kiện và giả định đã được tách rõ chưa?
Rủi ro kỹ thuật đã được dịch thành tác động kinh doanh chưa?
Có ít nhất hai lựa chọn với trade-off rõ ràng không?
Ai có quyền quyết định và ai chỉ cần được tham vấn?
Quyết định có được ghi cùng owner và điều kiện xem xét lại?
Có biện pháp phòng ngừa để vấn đề tương tự không lặp lại?

Hành động nên bắt đầu: chọn một bất đồng đang treo và viết lại vấn đề bằng một câu bắt đầu bằng “Chúng ta cùng muốn…”. Nếu hai bên không thể đồng ý câu đó, đừng tranh luận giải pháp vội — hãy tiếp tục làm rõ mục tiêu.

Khi nào cần escalation và cách escalation mà không phá vỡ quan hệ

Không phải xung đột nào cũng nên kéo dài ở cấp trưởng phòng. Khi rủi ro vượt thẩm quyền chấp nhận, các bên không thống nhất sau khi đã có đủ dữ kiện, hoặc quyết định ảnh hưởng nhiều đơn vị và ngân sách lớn, IT Manager cần escalation. Nhưng escalation nên được xem là cơ chế quản trị, không phải hành động “mách cấp trên”.

Một escalation tốt tóm tắt trong một trang: mục tiêu chung, điểm bất đồng, dữ kiện đã xác minh, lựa chọn, tác động của từng lựa chọn, khuyến nghị của các bên và quyết định cần cấp trên chốt. Tránh mang lên một chuỗi email dài hoặc yêu cầu lãnh đạo “phân xử ai đúng”.

Sau khi có quyết định, IT Manager cần quay lại đóng vòng với các bên, giải thích lý do và cập nhật cơ chế để giảm khả năng lặp lại. Nếu xung đột đến từ quy trình mua SaaS quá chậm, hãy cải tiến intake và security review. Nếu đến từ priority không rõ, hãy xây tiêu chí. Nếu đến từ trách nhiệm chồng chéo, hãy làm rõ decision rights.

Quan hệ liên phòng ban mạnh không có nghĩa là không có bất đồng. Nó có nghĩa rằng bất đồng có đường xử lý rõ, được dựa trên dữ kiện và không làm mất lòng tin cá nhân. Đây là dấu hiệu của một mô hình quản lý IT trưởng thành.

Nguồn tham khảo

Các nguồn trên được dùng làm tài liệu tham khảo cho nguyên tắc quản trị và quản lý. Nội dung bài viết là diễn giải ứng dụng của Infochief Academy cho bối cảnh điều hành bộ phận IT.