CHUYỂN ĐỔI SỐ CHO DOANH NGHIỆP – Tối ưu danh mục dự án chuyển đổi số (Digital Project Portfolio Optimization): Loại bỏ dự án không liên quan chiến lược.

Việc triển khai Chuyển đổi số trong doanh nghiệp giống như một cuộc chạy marathon, không phải là cuộc đua nước rút. Nhưng nhiều doanh nghiệp lại đang chạy lầm đường hoặc cố gắng mang vác quá nhiều vật nặng không cần thiết trên đường chạy.

Mỗi khi Ban điều hành phê duyệt một dự án công nghệ mới, đồng nghĩa với việc họ đang cam kết vốn, thời gian, và quan trọng nhất, sự tập trung của những nhân sự chủ chốt. Khi danh mục dự án (Project Portfolio) phình to không kiểm soát, khi các dự án công nghệ được đề xuất chỉ vì “thị trường đang làm” hay “sếp muốn thử”, hoặc chỉ để giải quyết một triệu chứng thay vì căn bệnh gốc rễ, nguồn lực của doanh nghiệp sẽ bị phân tán khủng khiếp. Năng lượng lẽ ra phải dồn vào việc cải tổ mô hình kinh doanh, cải thiện trải nghiệm khách hàng, hoặc xây dựng nền tảng dữ liệu cốt lõi, lại bị hút vào việc quản lý hàng chục dự án nhỏ lẻ, rời rạc, không có bất kỳ mối liên hệ rõ ràng nào với Chiến lược 3-5 năm của công ty.

Vấn đề không phải là thiếu tiền mua phần mềm, mà là thiếu kỷ luật tư duy để nói KHÔNG với những thứ không mang lại giá trị chiến lược. Nếu không thể tối ưu hóa danh mục dự án ngay từ đầu, doanh nghiệp sẽ rơi vào trạng thái “số hóa mà không chuyển đổi”, hệ thống trở nên phức tạp chồng chất (IT complexity), chi phí vận hành tăng vọt, và cuối cùng, năng lực cạnh tranh bị bào mòn. Việc loại bỏ những dự án không liên quan đến chiến lược không phải là thất bại, mà là hành động quản trị sắc bén nhất để bảo toàn và tăng cường tốc độ chuyển đổi.

MỤC LỤC CHI TIẾT

• I. Nhận diện vấn đề cốt lõi: Ma trận dự án và sự lãng phí chiến lược
• II. Chuyển đổi số không phải là Danh sách ước muốn (Wishlist): Phân biệt giữa Digital Project và Strategic Initiative
• III. Xây dựng Khung Lưới Chiến Lược (Strategic Grid) để đánh giá dự án
• IV. Quy trình Tối ưu hóa Danh mục Dự án (Digital Project Portfolio Optimization – DPPO)
• V. Sai lầm tư duy và quản trị khi loại bỏ dự án
• VI. Case Study Thực chiến: Khi việc loại bỏ là bước tiến lớn
• VII. Khung quản trị và chuẩn mực giúp duy trì sự tập trung
• VIII. Hành động then chốt (Actionable Takeaways) và Rủi ro nếu trì hoãn

***

I. Nhận diện vấn đề cốt lõi: Ma trận dự án và sự lãng phí chiến lược

Mọi Chủ doanh nghiệp (CEO) đều hiểu rằng công nghệ là tương lai. Tuy nhiên, ít CEO nào dành đủ thời gian để xây dựng bộ lọc đủ sắc bén nhằm đảm bảo mỗi đồng chi tiêu cho công nghệ đều phục vụ cho mục tiêu chiến lược cốt lõi.

Vấn đề lớn nhất thường gặp là sự thiếu vắng của Khung Quản trị Danh mục Dự án (Portfolio Governance). Các dự án công nghệ thường được sinh ra từ bốn nguồn:

1. Nhu cầu khẩn cấp của Vận hành (Operational Demand): “Chúng ta cần phần mềm để xuất báo cáo thuế nhanh hơn.”
2. Mong muốn của Cá nhân Lãnh đạo (Leadership Vision): “Tôi thấy đối thủ đang dùng AI, chúng ta cũng phải thử.”
3. Áp lực từ Thị trường (Market Pressure): “Khách hàng yêu cầu phải có app đặt hàng.”
4. Sự thúc đẩy từ Nhà cung cấp (Vendor Push): “Phần mềm XYZ này đang giảm giá 50%, mua đi!”

Khi các dự án được quyết định dựa trên tính khẩn cấp hoặc sự thúc đẩy bên ngoài, chúng ta sẽ có một danh sách dự án rời rạc, không liên kết, tạo nên một “Ma trận dự án” (Project Sprawl).

Hệ quả của Ma trận dự án này không chỉ là lãng phí tiền bạc, mà còn là sự lãng phí tài nguyên quý giá nhất: Tốc độ và Sự tập trung.

Thực tế, khi một doanh nghiệp có 20 dự án chuyển đổi số đang chạy song song, thì 15 dự án trong số đó đang sử dụng cùng một nhóm nhân sự IT hoặc nhân sự chủ chốt từ khối Vận hành/Tài chính. Sự chồng chéo về nhân lực, dữ liệu, và công nghệ tạo ra những điểm nghẽn khủng khiếp, làm giảm chất lượng triển khai của những dự án quan trọng nhất.

Điều đáng sợ nhất là khi phải đối mặt với một dự án lớn, chẳng hạn như triển khai ERP lõi, nhóm triển khai đã kiệt sức và mất niềm tin do thất bại từ 5-7 dự án nhỏ lẻ trước đó. Việc phải “giết” những dự án vô nghĩa lúc này trở thành một nhiệm vụ tối quan trọng, một hành động giải phóng nguồn lực.

II. Chuyển đổi số không phải là Danh sách ước muốn (Wishlist): Phân biệt giữa Digital Project và Strategic Initiative

A. Định nghĩa lại Bản chất của Chuyển đổi số

Chuyển đổi số (Digital Transformation) không phải là việc mua phần mềm hay lắp đặt công nghệ mới. Nó là quá trình thay đổi căn bản cách thức doanh nghiệp vận hành và mang lại giá trị cho khách hàng, sử dụng công nghệ như một đòn bẩy.

Nếu một dự án chỉ giúp tự động hóa một bước công việc mà không thay đổi bản chất của quy trình (ví dụ: thay vì nhập liệu thủ công bằng Excel thì chuyển sang nhập liệu trên Google Sheet), đó là Số hóa (Digitization) hoặc Tự động hóa (Automation) đơn thuần. Nó cần thiết, nhưng chưa phải là Chuyển đổi số.

Một Sáng kiến Chiến lược (Strategic Initiative) liên quan đến Chuyển đổi số phải thỏa mãn các yếu tố sau:

1. Liên kết rõ ràng với 1-2 Mục tiêu Chiến lược Cấp cao (OKR/KPIs C-level).
2. Tạo ra sự khác biệt về năng lực cạnh tranh (Competitive Advantage), không chỉ là giảm chi phí.
3. Yêu cầu sự thay đổi về văn hóa, kỹ năng và cơ cấu tổ chức, không chỉ là thay đổi công cụ.
4. Xây dựng nền tảng dữ liệu (Data Foundation) có thể tái sử dụng cho các quyết định kinh doanh trong tương lai.

Nếu dự án không đáp ứng 3/4 tiêu chí trên, nó cần được xem xét lại mức độ ưu tiên và sự tồn tại của nó trong danh mục.

B. Ba loại dự án thường gặp dẫn đến lãng phí

Trong thực tế triển khai, ba loại dự án sau đây thường chiếm từ 40% đến 60% tổng chi tiêu và thời gian của một danh mục dự án Chuyển đổi số, nhưng lại có tác động chiến lược rất thấp.

1. Dự án “Tô son trát phấn” (Digital Facelift Projects)

Bản chất: Dự án chỉ tập trung vào giao diện hoặc tính năng bề ngoài.

Ví dụ: Phát triển ứng dụng di động cho khách hàng chỉ để “có app”, nhưng ứng dụng đó không tích hợp với hệ thống tồn kho/đơn hàng lõi, không cung cấp dữ liệu hành vi khách hàng, và không thay thế bất kỳ kênh giao tiếp nào đang có. Nó chỉ là một kênh thông tin mới, tốn kém chi phí bảo trì mà không tăng doanh số hay giảm chi phí vận hành.

Hệ quả: Dùng ngân sách quý giá để tạo ra “sự hào nhoáng số hóa” mà không giải quyết vấn đề cốt lõi về chất lượng dịch vụ hay vận hành.

2. Dự án “Giải quyết triệu chứng” (Symptom Treatment Projects)

Bản chất: Dùng công nghệ để bịt một lỗ hổng cụ thể, thay vì sửa chữa kiến trúc.

Ví dụ: Phòng Kế toán phàn nàn việc đối chiếu công nợ mất 3 ngày. Thay vì xem xét lại quy trình mua hàng, quy trình giao nhận, và cách thức ghi nhận dữ liệu ở nguồn (Data Governance), doanh nghiệp lại quyết định mua một công cụ nhỏ, chuyên biệt, chỉ để tự động hóa việc đối chiếu hai file Excel khổng lồ.

Hệ quả: Tạo ra một hệ thống “vá víu” (Patchwork System). Lỗi sai ban đầu vẫn tồn tại nhưng bị che lấp bởi công cụ, khiến việc mở rộng và tích hợp sau này trở nên cực kỳ phức tạp.

3. Dự án “Công nghệ theo trào lưu” (Trend-driven Technology Projects)

Bản chất: Đầu tư vào công nghệ mới (AI, Blockchain, IoT) chỉ vì sợ bị tụt hậu, nhưng không có mô hình kinh doanh hoặc trường hợp sử dụng (Use Case) rõ ràng.

Ví dụ: Triển khai một dự án nhỏ về Blockchain để quản lý nguồn gốc sản phẩm, nhưng chuỗi cung ứng lõi (vận hành từ nhà máy đến kho) vẫn đang ghi chép bằng sổ sách hoặc phần mềm cũ kỹ 15 năm tuổi, không thể cung cấp dữ liệu đầu vào sạch.

Hệ quả: Tiền mất, tật mang. Dự án “nghiên cứu và phát triển” này nhanh chóng trở thành một “PoC – Proof of Concept” vĩnh viễn, chết yểu sau vài tháng mà không thể mở rộng quy mô.

III. Xây dựng Khung Lưới Chiến Lược (Strategic Grid) để đánh giá dự án

Để loại bỏ những dự án không liên quan chiến lược, chúng ta phải có một hệ thống chấm điểm và so sánh khách quan. Đây là nơi tư duy tư vấn chuyên sâu phát huy tác dụng: chúng ta không đánh giá dự án theo cảm tính mà theo khung chiến lược.

A. Từ Mục tiêu Chiến lược đến Các Chỉ số Vận hành (KPIs)

Mỗi dự án Chuyển đổi số phải là một phương tiện để đạt được các Mục tiêu Chiến lược Cấp cao (Corporate Objectives).

Giả sử, mục tiêu chiến lược của doanh nghiệp trong 3 năm tới là:

1. Tăng trưởng doanh thu từ khách hàng hiện tại (Cross-sell/Up-sell) lên 30%.
2. Giảm chi phí vận hành (Cost-to-Serve) xuống 15%.
3. Đạt mức hài lòng khách hàng (CSAT/NPS) 90+.

Khi một dự án mới được đề xuất (ví dụ: triển khai CRM mới), phải có một chuỗi liên kết logic rõ ràng:

Mục tiêu Cấp cao (Tăng trưởng 30%)
^(Hỗ trợ bởi)
V
Chỉ số Chiến lược (Tỷ lệ giữ chân khách hàng – Retention Rate tăng 20%)
^(Tác động bởi)
V
KPIs Vận hành (Thời gian xử lý đơn hàng/yêu cầu hỗ trợ (Cycle Time) giảm 50%)
^(Thực hiện bởi)
V
Dự án (Triển khai CRM, tích hợp với hệ thống kho/tài chính, tự động hóa quy trình hậu mãi)

Nếu dự án đó (ví dụ: mua phần mềm quản lý lịch họp nội bộ) không thể liên kết đến bất kỳ KPI vận hành quan trọng nào, nó không nên có trong danh mục DPPO.

B. Công cụ sàng lọc: Mức độ Tác động vs. Tính khả thi (Impact vs. Feasibility)

Đây là công cụ trực quan và hiệu quả nhất để đánh giá toàn bộ danh mục dự án. Chúng ta chia dự án thành 4 nhóm dựa trên hai trục:

Trục dọc (Y): Mức độ Tác động Chiến lược (Strategic Impact)
(Được đo lường bằng mức độ ảnh hưởng đến các KPIs vận hành và tài chính cốt lõi)

Trục ngang (X): Tính khả thi (Feasibility)
(Được đo lường bằng Năng lực công nghệ hiện tại, nguồn lực tài chính, rủi ro tổ chức, và độ phức tạp kỹ thuật)

Mức độ Tác động (Y)	Tính khả thi (X) Thấp (Rủi ro cao)	Tính khả thi (X) Cao (Rủi ro thấp)
Cao (Must-Do)	Nhóm C: Đầu tư Chiến lược (Strategic Bets)	Nhóm A: Ưu tiên Cốt lõi (Quick Wins/Core)
Thấp (Nice-to-Have)	Nhóm D: Loại bỏ (Kill)	Nhóm B: Xem xét lại (Re-evaluate/Delay)

Phân tích từng nhóm:

• Nhóm A (Ưu tiên Cốt lõi): Tác động lớn, khả thi cao. Đây là các dự án tạo ra giá trị nhanh chóng, xây dựng niềm tin và nền tảng. Ví dụ: Chuẩn hóa dữ liệu khách hàng (Data Cleansing) hoặc Tự động hóa quy trình Tài chính/Kế toán đơn giản (RPA cho các tác vụ lặp).
• Nhóm C (Đầu tư Chiến lược): Tác động lớn, khả thi thấp/rủi ro cao. Đây là những dự án thay đổi cuộc chơi (Game Changers), như triển khai ERP lõi, xây dựng Data Lake, hoặc thay đổi mô hình kinh doanh. Chúng ta phải dành nguồn lực tốt nhất và quản trị rủi ro chặt chẽ cho nhóm này.
• Nhóm B (Xem xét lại): Tác động thấp, khả thi cao. Đây là bẫy. Các dự án này dễ làm, nhưng không giải quyết vấn đề lớn. Nếu không loại bỏ, chúng sẽ hút cạn nguồn lực của nhóm A và C. Chúng có thể được làm sau khi hoàn thành nhóm A và C, hoặc phải được chuyển thành một “Sáng kiến Vận hành” (Operation Initiative) với ngân sách tối thiểu, thay vì một “Dự án Chuyển đổi số” đòi hỏi sự tham gia của C-level.
• Nhóm D (Loại bỏ): Tác động thấp, khả thi thấp. Đơn giản: Gạch bỏ. Chúng chỉ là sự lãng phí tài nguyên.

C. Vai trò của Tài chính: Hiểu rõ Tổng Chi phí Sở hữu (TCO) và ROI/ROA thực tế

Rất nhiều dự án được phê duyệt dựa trên chi phí mua ban đầu (Initial Purchase Cost), mà bỏ qua hoàn toàn Tổng Chi phí Sở hữu (Total Cost of Ownership – TCO).

TCO bao gồm:

1. Chi phí Mua sắm/Phát triển (Capital Expenditure – CAPEX).
2. Chi phí Bảo trì/Vận hành (Operating Expenditure – OPEX): Phí license hàng năm, chi phí Cloud, chi phí nhân sự vận hành hệ thống (SysAdmin, Data Analyst).
3. Chi phí Ẩn: Chi phí đào tạo lại nhân sự, chi phí quản lý thay đổi (Change Management), chi phí tích hợp với các hệ thống khác.

Một dự án “rẻ tiền” ở khâu mua sắm (ví dụ: một phần mềm nội địa hóa, giá license thấp) có thể biến thành một cơn ác mộng TCO nếu:

• Không tích hợp được với ERP/CRM hiện có.
• Yêu cầu đội ngũ IT phải viết quá nhiều mã API kết nối thủ công.
• Yêu cầu phải thuê thêm 2 nhân viên IT chuyên trách bảo trì.

Chúng ta phải đánh giá khả năng sinh lời thực tế (ROI – Return on Investment hoặc ROA – Return on Assets) của từng dự án trong danh mục. ROI của một dự án chuyển đổi số không chỉ là tăng doanh thu, mà còn là cải thiện các KPIs vận hành đã được cam kết.

Ví dụ: Dự án A (triển khai hệ thống quản lý kho WMS) cam kết:

• Giảm 30% sai sót tồn kho.
• Tăng tốc độ luân chuyển hàng hóa (Inventory Turnover Rate) thêm 15%.
• Giảm chi phí nhân công kho bãi 5%.

Nếu sau 6 tháng, hệ thống WMS chỉ giảm được 5% sai sót và không ảnh hưởng đến tốc độ luân chuyển, dự án đó không đạt được ROI chiến lược và phải được đưa vào danh sách kiểm điểm, thậm chí là loại bỏ nếu không có khả năng sửa chữa.

IV. Quy trình Tối ưu hóa Danh mục Dự án (Digital Project Portfolio Optimization – DPPO)

Tối ưu hóa danh mục không phải là hành động một lần, mà là một quy trình quản trị định kỳ, yêu cầu sự kỷ luật và tính khách quan cao.

A. Giai đoạn 1: Kiểm kê và Thẩm định độc lập (Audit & Due Diligence)

Bước đầu tiên là phải biết mình đang có gì. Nhiều doanh nghiệp lớn không biết chính xác họ đang chi tiêu bao nhiêu cho công nghệ và những dự án nào đang chạy.

1. Lập danh sách đầy đủ (Inventory): Liệt kê tất cả dự án công nghệ đang chạy, đã hoàn thành nhưng chưa đưa vào vận hành, hoặc đang trong giai đoạn đề xuất.
2. Xác định Chủ sở hữu (Owner) và Mục tiêu Ban đầu: Dự án này do ai đề xuất? Mục tiêu ban đầu của nó là gì?
3. Thẩm định Hiệu suất Hiện tại (Performance Audit): Đánh giá khách quan tiến độ (đã hoàn thành bao nhiêu %), chi phí đã tiêu (Sunk Cost), và quan trọng nhất, Tác động thực tế đã đạt được (Actual Impact).

Nếu một dự án đã tiêu tốn 80% ngân sách nhưng chỉ hoàn thành 20% phạm vi công việc và không có khả năng đạt được mục tiêu KPI ban đầu, đây là một lá cờ đỏ cực lớn. Việc thẩm định độc lập phải được thực hiện bởi một nhóm không phải là nhóm chịu trách nhiệm triển khai dự án đó, thường là Văn phòng Quản lý Dự án (PMO) hoặc đơn vị Tư vấn bên ngoài.

B. Giai đoạn 2: Thiết lập Quy tắc Loại bỏ (Kill Criteria)

Đây là bước khó khăn nhất, đòi hỏi sự dũng cảm của Ban Lãnh đạo. Quy tắc loại bỏ phải dựa trên dữ liệu khách quan, không phải cảm xúc.

Quy tắc loại bỏ nên được xác định rõ ràng, ví dụ:

• Tiêu chí 1: Không liên kết Chiến lược
  Bất kỳ dự án nào không liên kết được với ít nhất một trong Ba Mục tiêu Chiến lược Cấp cao (như đã định nghĩa ở Mục III.A) sẽ bị đánh giá là Loại Bỏ hoặc Hoãn Vô Thời Hạn.
• Tiêu chí 2: Thiếu Năng lực Kỹ thuật
  Dự án yêu cầu công nghệ mà đội ngũ IT không có khả năng hỗ trợ bảo trì sau triển khai, và chi phí thuê ngoài quá cao (ví dụ: >20% tổng chi phí dự án hàng năm), sẽ bị loại bỏ.
• Tiêu chí 3: Tác động Thấp / Rủi ro Cao
  Dự án nằm trong Nhóm D (Tác động thấp, Khả thi thấp) trên Ma trận Impact vs. Feasibility.
• Tiêu chí 4: Hệ thống Kế thừa (Legacy System)
  Nếu dự án là một nỗ lực “vá víu” hoặc mở rộng một hệ thống cũ kỹ (Legacy System) đã được lên kế hoạch thay thế hoàn toàn trong vòng 12-18 tháng tới, thì dự án đó phải bị loại bỏ để tập trung nguồn lực vào dự án thay thế lõi.

Việc thiết lập và công bố các “Kill Criteria” này tạo ra sự minh bạch và công bằng, giúp giảm sự kháng cự từ các bên liên quan khi quyết định loại bỏ được đưa ra.

C. Giai đoạn 3: Phân bổ lại Nguồn lực (Resource Reallocation)

Mục đích cuối cùng của việc loại bỏ dự án không phải là để tiết kiệm tiền (mặc dù đó là một kết quả tích cực), mà là để Tái Phân bổ Nguồn lực (Resource Reallocation) sang các dự án Nhóm A và C.

Khi một dự án bị “khai tử”, cần phải làm rõ:

1. Nhân sự: Nhóm IT, Vận hành, Kế toán đang tham gia dự án đó sẽ được chuyển sang các dự án ưu tiên. Đảm bảo rằng nhân sự chủ chốt không bị quá tải.
2. Ngân sách: Phần ngân sách chưa sử dụng phải được chuyển vào quỹ dự phòng cho các dự án chiến lược, hoặc dùng để gia cố hạ tầng công nghệ lõi (ví dụ: cải thiện Data Governance, nâng cấp Cloud adoption).
3. Dữ liệu: Nếu dự án đã tạo ra dữ liệu, phải đảm bảo dữ liệu đó được lưu trữ và tích hợp an toàn vào Data Lake/Data Warehouse chính của doanh nghiệp, trước khi đóng hệ thống.

V. Sai lầm tư duy và quản trị khi loại bỏ dự án

Mặc dù việc tối ưu hóa danh mục dự án nghe có vẻ hợp lý trên giấy tờ, thực tế, đây là một trong những thử thách chính trị và văn hóa khó khăn nhất trong quá trình Chuyển đổi số.

A. Hội chứng “Sunk Cost Fallacy” và Nỗi sợ Thất bại

Sunk Cost Fallacy (Sai lầm Chi phí Chìm) là sai lầm tư duy phổ biến nhất. Đó là khi Ban Lãnh đạo hoặc Người quản lý dự án tiếp tục đầu tư vào một dự án thất bại chỉ vì “chúng ta đã chi quá nhiều tiền và thời gian rồi, bỏ ngang thì uổng”.

Ví dụ: Dự án phát triển một hệ thống CRM tự viết (in-house CRM) đã tiêu tốn 10 tỷ đồng trong 2 năm và chỉ hoạt động được 30% chức năng. Hệ thống này quá cồng kềnh và khó bảo trì. Đáng lẽ ra phải dừng lại và chuyển sang mua một giải pháp thương mại (ví dụ: Salesforce, Microsoft Dynamics), nhưng vì sợ mất mặt và sợ phải thừa nhận 10 tỷ đồng đó là lãng phí, lãnh đạo vẫn quyết định “cố gắng thêm 6 tháng nữa”.

Thực tế: 10 tỷ đồng đã chi là chi phí chìm, không thể lấy lại được. Quyết định tiếp tục đầu tư phải dựa trên Giá trị Tương lai (Future Value), chứ không phải Chi phí Quá khứ. Nếu dừng lại, doanh nghiệp mất 10 tỷ. Nếu tiếp tục 6 tháng nữa (thêm 3 tỷ), nhưng cuối cùng vẫn thất bại, doanh nghiệp mất 13 tỷ và 6 tháng quý giá.

Kinh nghiệm cho thấy, việc chấp nhận thất bại một dự án là dấu hiệu của sự trưởng thành trong quản trị và khả năng ra quyết định dựa trên số liệu.

B. Kháng cự từ các bộ phận (Organizational Resistance)

Việc loại bỏ dự án không chỉ là một quyết định kỹ thuật, mà còn là một quyết định chính trị.

• Người đề xuất dự án: Họ sẽ cảm thấy mất thể diện hoặc bị coi là làm việc kém hiệu quả.
• Bộ phận Vận hành/Sản xuất: Họ đã quen với quy trình mới (dù dở) và sợ phải thay đổi lần nữa.
• Nhóm IT/Developer: Họ có thể đã dành nhiều công sức để phát triển hệ thống đó và sẽ kháng cự việc “đập đi xây lại”.

Giải pháp:

1. Minh bạch hóa lý do loại bỏ (dựa trên Kill Criteria đã công bố).
2. Tái định vị nhân sự: Đảm bảo những người có năng lực sẽ được chuyển sang các dự án quan trọng hơn, xem đó là một sự “thăng cấp” về mặt chiến lược.
3. Luôn nhấn mạnh Tầm nhìn: Quyết định loại bỏ là để tập trung nguồn lực vào việc đạt được Mục tiêu Chiến lược lớn hơn, mang lại lợi ích chung cho toàn bộ công ty.

C. Sai lầm trong Quản trị Dữ liệu (Data Governance)

Khi một dự án bị loại bỏ, thường kéo theo việc ngừng hoạt động của một hệ thống, dẫn đến rủi ro lớn về dữ liệu.

Sai lầm phổ biến là khi loại bỏ hệ thống cũ, doanh nghiệp không có kế hoạch rõ ràng để trích xuất, chuẩn hóa, và lưu trữ dữ liệu lịch sử.

Ví dụ: Loại bỏ một hệ thống CRM cũ, nhưng không đảm bảo rằng dữ liệu tương tác, lịch sử mua hàng, và các ghi chú quan trọng của khách hàng được tích hợp vào Data Warehouse hoặc được di chuyển sang hệ thống CRM mới theo chuẩn mực Quản trị Dữ liệu (Data Governance).

Hệ quả: Mất mát dữ liệu lịch sử, làm giảm chất lượng phân tích kinh doanh, và đôi khi vi phạm các quy định về lưu trữ hồ sơ tài chính/khách hàng.

VI. Case Study Thực chiến: Khi việc loại bỏ là bước tiến lớn

Kinh nghiệm trong nhiều dự án cải tổ vận hành và tái cấu trúc công nghệ cho thấy, việc “giết” dự án là bước đi đầu tiên để đạt được hiệu suất thực sự.

A. Case 1: Tái cấu trúc chuỗi cung ứng (Supply Chain) cho Doanh nghiệp Sản xuất – Phân phối (Đánh giá Hệ thống ERP thừa/thiếu)

Bối cảnh doanh nghiệp: Một công ty sản xuất và phân phối hàng tiêu dùng (FMCG) quy mô trung bình (khoảng 300 nhân viên, 4 nhà máy nhỏ, hệ thống phân phối đại lý).

Vấn đề/Điểm nghẽn: Công ty đã triển khai một dự án ERP vào 5 năm trước, nhưng chỉ sử dụng được 40% tính năng (chủ yếu là Tài chính/Kế toán). 8 tháng trước, công ty bắt đầu triển khai thêm 3 dự án độc lập:

1. Dự án Báo cáo BI/Analytics: Dùng PowerBI để phân tích dữ liệu bán hàng.
2. Dự án Quản lý Bảo trì Thiết bị (CMMS): Dùng phần mềm chuyên biệt cho 4 nhà máy.
3. Dự án Tự động hóa Mua hàng: Xây dựng cổng Portal nội bộ cho quy trình PR-PO.

Tổng chi phí ba dự án này đã vượt 3 tỷ đồng, nhưng không dự án nào tích hợp được với module Sản xuất/Kho vận của ERP lõi. Kết quả: Số liệu BI sai lệch do phải tổng hợp thủ công, và nhóm IT bị quá tải vì phải duy trì 4 hệ thống rời rạc.

Cách tiếp cận và Giải pháp triển khai:
Áp dụng DPPO, chúng tôi tiến hành Thẩm định (Audit) toàn bộ danh mục và áp dụng Kill Criteria:

1. Phân tích TCO: Chi phí bảo trì 3 hệ thống nhỏ lẻ (license, phí tích hợp, nhân sự IT chuyên trách) cao hơn 50% chi phí kích hoạt và cấu hình lại các module tương đương trong hệ thống ERP lõi.
2. Phân tích Chiến lược: Mục tiêu chiến lược là Giảm Chi phí Sản xuất (Cost of Goods Sold – COGS) 10%. Điều này yêu cầu tính toán giá thành chính xác và tối ưu hóa quy trình bảo trì, mà chỉ có thể đạt được nếu dữ liệu Sản xuất, Kho, và Tài chính đồng bộ trên một nền tảng ERP duy nhất. Ba dự án nhỏ không giúp đạt được mục tiêu này.

Quyết định:

• Loại bỏ hoàn toàn Dự án CMMS (Quản lý Bảo trì) và Dự án Tự động hóa Mua hàng.
• Tạm dừng Dự án BI/Analytics cho đến khi dữ liệu đầu vào (từ ERP) được làm sạch.
• Tái phân bổ nguồn lực (Nhân sự IT và 2.5 tỷ đồng ngân sách còn lại) vào việc Kích hoạt và Tái cấu trúc Module Sản xuất, Mua hàng, và Kho vận trên ERP hiện có.

Kết quả định lượng (Sau 12 tháng):

• Giảm chi phí IT vận hành (OPEX): Giảm 35% chi phí license/bảo trì do loại bỏ 2 hệ thống thừa thãi.
• Tăng hiệu suất tính giá thành: Thời gian đóng sổ và tính giá thành (Costing Cycle Time) giảm từ 5 ngày làm việc xuống còn 1.5 ngày, giúp Ban Lãnh đạo đưa ra quyết định giá bán và chiết khấu nhanh hơn.
• Cải thiện Kiểm soát và Tuân thủ: Doanh nghiệp đạt tiêu chuẩn về kiểm soát nội bộ Tài chính/Sản xuất (tiền đề cho việc áp dụng các chuẩn mực như SOC), nhờ tất cả giao dịch được ghi nhận tập trung và theo quy trình chuẩn của ERP.

Bài học: Việc cố gắng “vá” lỗi của một hệ thống lõi (ERP) bằng cách mua thêm các ứng dụng rời rạc là chiến lược sai lầm. Quyết định loại bỏ các dự án thừa là cách nhanh nhất để buộc doanh nghiệp phải đối diện và tối ưu hóa nền tảng lõi.

B. Case 2: Tối ưu hóa trải nghiệm khách hàng và quản lý rủi ro tín dụng (Tổ chức Tài chính)

Bối cảnh doanh nghiệp: Một tổ chức tài chính/ngân hàng bán lẻ quy mô vừa, đang tìm cách mở rộng thị trường cho vay tiêu dùng thông qua kênh trực tuyến.

Vấn đề/Điểm nghẽn: Chiến lược là tăng tốc độ xét duyệt khoản vay lên 50% và giảm tỷ lệ nợ xấu (Non-Performing Loan – NPL). Doanh nghiệp đang triển khai 4 dự án liên quan đến khách hàng:

1. Nền tảng Cho vay P2P (thử nghiệm).
2. Dự án Big Data để xây dựng mô hình chấm điểm tín dụng (Credit Scoring Model).
3. Dự án Tự động hóa Quy trình Bán hàng (Sales Automation) bằng phần mềm mới.
4. Dự án Phát triển App Mobile để tra cứu thông tin khoản vay.

Vấn đề cốt lõi là Dự án 2 (Big Data/Credit Scoring) đã bị đình trệ vì thiếu dữ liệu đầu vào sạch, trong khi Dự án 1 (P2P) đang tiêu tốn ngân sách lớn mà không có quy trình kiểm soát rủi ro rõ ràng, vi phạm các quy tắc cơ bản về tính tuân thủ (Compliance). Dự án 3 và 4 chỉ là “bề nổi” không giúp giải quyết rủi ro tín dụng.

Cách tiếp cận và Giải pháp triển khai:
Phân tích cho thấy sự không tương thích giữa các dự án với mục tiêu giảm NPL và tăng tốc độ xử lý:

• Mục tiêu Chiến lược: Tăng trưởng an toàn, kiểm soát rủi ro.
• Rủi ro cốt lõi: NPL tăng do quy trình thẩm định thủ công và chậm chạp.

Quyết định:

• Loại bỏ hoàn toàn Dự án Nền tảng Cho vay P2P vì nó không liên quan đến mục tiêu chiến lược cốt lõi hiện tại (kiểm soát rủi ro trong mô hình kinh doanh truyền thống) và tiềm ẩn rủi ro tuân thủ cao. Nguồn lực phải được rút ra ngay lập tức.
• Tái cấu trúc và Ưu tiên lại Dự án Big Data/Credit Scoring. Thay vì xây dựng mô hình quá phức tạp, tập trung vào việc chuẩn hóa nguồn dữ liệu giao dịch nội bộ và tích hợp với các hệ thống báo cáo tín dụng quốc gia (External APIs) để tạo ra mô hình chấm điểm cơ bản (Foundational Model) nhanh chóng.
• Giảm quy mô Dự án App Mobile (từ phát triển Full-featured App sang bản MVP – Minimum Viable Product – chỉ tập trung vào tra cứu trạng thái xét duyệt và nhắc nhở thanh toán).

Kết quả định lượng (Sau 9 tháng):

• Tốc độ xét duyệt: Thời gian xét duyệt khoản vay tiêu dùng (Loan Approval Time) giảm từ trung bình 48 giờ xuống còn 4 giờ (tăng 90% hiệu suất). Điều này đạt được nhờ việc dừng các dự án phân tán và tập trung nguồn lực IT vào việc xây dựng đường ống dữ liệu (Data Pipeline) cho mô hình chấm điểm cơ bản.
• Kiểm soát rủi ro: Tỷ lệ Nợ xấu mới phát sinh (New NPL Rate) giảm 8% trong 6 tháng đầu tiên sau khi mô hình chấm điểm mới được áp dụng, nhờ quyết định tập trung vào dữ liệu sạch và quy trình tự động.
• Tập trung Nguồn vốn: Giải phóng khoảng 4 tỷ đồng ngân sách của dự án P2P để đầu tư vào hạ tầng bảo mật dữ liệu và tuân thủ (Compliance Infrastructure).

Bài học: Khi danh mục dự án bị phân tán, ngay cả các tổ chức tài chính cũng dễ mắc sai lầm. Việc loại bỏ dự án không chỉ tiết kiệm tiền, mà còn là hành động phòng thủ rủi ro chiến lược và tuân thủ (Compliance) quan trọng nhất.

VII. Khung quản trị và chuẩn mực giúp duy trì sự tập trung

Để đảm bảo việc tối ưu hóa danh mục dự án là một hoạt động thường xuyên, chứ không phải là một chiến dịch “dọn dẹp” khẩn cấp, doanh nghiệp cần thiết lập các khung quản trị (Governance Frameworks) vững chắc.

A. Vai trò của SOC (Service Organization Control) trong lựa chọn giải pháp

Khi đánh giá các dự án phần mềm hoặc nền tảng Cloud (SaaS/PaaS), tính tin cậy và tuân thủ là yếu tố sống còn. Một trong những sai lầm dẫn đến việc phải loại bỏ dự án sau này là lựa chọn nhà cung cấp không đạt chuẩn.

SOC (Service Organization Control) là một bộ tiêu chuẩn kiểm soát nội bộ cho các nhà cung cấp dịch vụ. Khi làm việc với các hệ thống lõi (ERP, CRM, Cloud Infrastructure), việc yêu cầu nhà cung cấp có báo cáo SOC 1 Type 2 hoặc SOC 2 Type 2 là tối quan trọng.

• SOC 1: Liên quan đến kiểm soát nội bộ đối với báo cáo tài chính của khách hàng. Nếu triển khai hệ thống kế toán hoặc tính lương, cần nhà cung cấp có SOC 1.
• SOC 2: Liên quan đến tính bảo mật, tính khả dụng, tính toàn vẹn xử lý, tính bảo mật và quyền riêng tư của dữ liệu khách hàng.

Nếu một dự án được đề xuất sử dụng một phần mềm giá rẻ, mới nổi, không có bất kỳ chứng nhận kiểm soát nào (như SOC), thì dù giá có hấp dẫn đến mấy, rủi ro pháp lý và vận hành (Operational Risk) sau này sẽ cực kỳ cao. Chi phí để khắc phục sự cố tuân thủ hoặc bảo mật có thể vượt xa chi phí tiết kiệm ban đầu. Đây là một tiêu chí loại bỏ dự án rất mạnh mẽ: Nếu dự án nền tảng không đảm bảo tính tuân thủ cơ bản, nó phải bị loại bỏ trước khi ký hợp đồng.

B. Áp dụng tinh thần Agile ở cấp độ Chiến lược (Strategic Agility)

Nhiều doanh nghiệp áp dụng Agile (Linh hoạt) ở cấp độ phát triển phần mềm, nhưng lại quản lý danh mục dự án theo kiểu thác nước (Waterfall Portfolio Management).

Strategic Agility yêu cầu khả năng điều chỉnh và loại bỏ dự án nhanh chóng khi bối cảnh kinh doanh thay đổi.

1. Đánh giá Định kỳ (Quarterly Review): Danh mục dự án phải được rà soát hàng quý bởi Ban Lãnh đạo, không phải chỉ hàng năm.
2. Ngân sách Dựa trên Kết quả: Thay vì phân bổ 100% ngân sách cho một dự án trong 2 năm, hãy phân bổ ngân sách theo từng giai đoạn (Phase Gate). Sau mỗi giai đoạn (ví dụ: sau 6 tháng xây dựng MVP), dự án phải chứng minh được Tác động Định lượng (Quantifiable Impact) đã được cam kết. Nếu không đạt, dự án sẽ không được cấp vốn cho giai đoạn tiếp theo (Kill Criteria áp dụng ngay trong quá trình chạy).

Việc áp dụng nguyên tắc Agile vào quản trị danh mục dự án giúp doanh nghiệp không bị mắc kẹt quá lâu vào các dự án không hiệu quả, bảo vệ nguồn vốn và sự tập trung.

***

VIII. Hành động then chốt (Actionable Takeaways) và Rủi ro nếu trì hoãn

Việc tối ưu hóa danh mục dự án không phải là một sự lựa chọn, mà là yêu cầu bắt buộc để đảm bảo Chuyển đổi số mang lại giá trị thực. Đây là những hành động cụ thể có thể bắt đầu triển khai ngay:

1. Thiết lập Văn phòng Quản lý Chuyển đổi (TMO/PMO) với Quyền Lực Rõ ràng
   PMO/TMO không chỉ là đơn vị theo dõi tiến độ. Họ phải là “người gác cổng chiến lược”, có quyền lực và thẩm quyền để thách thức (Challenge) sự liên kết chiến lược của bất kỳ dự án mới nào được đề xuất, và đề xuất loại bỏ (Recommend Kill) các dự án đang chạy mà không đạt KPI.
2. Yêu cầu Minh bạch về TCO và ROI
   Mọi đề xuất dự án công nghệ (trên ngưỡng 500 triệu hoặc 1 tỷ đồng) phải trình bày đầy đủ bảng phân tích TCO 3 năm và cam kết ROI/ROA định lượng, liên kết trực tiếp với 3-5 KPIs Vận hành/Tài chính cốt lõi. Nếu không có bảng phân tích này, đề xuất không được đưa lên Ban Lãnh đạo.
3. Triển khai Quy trình Audit Danh mục Sáu tháng một lần
   Thực hiện Thẩm định độc lập toàn bộ danh mục dự án 6 tháng/lần, sử dụng Ma trận Tác động vs. Khả thi. Trong mỗi lần Audit, đặt mục tiêu loại bỏ ít nhất 15-20% các dự án Nhóm D (Loại bỏ) và Nhóm B (Xem xét lại) để liên tục giải phóng nguồn lực.
4. Xây dựng Ngân sách “Rút lui” (Decommissioning Budget)
   Mỗi năm, trích một phần ngân sách nhỏ (ví dụ: 5% tổng ngân sách IT) cho việc “giết” các hệ thống cũ và dự án thất bại. Việc loại bỏ một dự án tốn kém chi phí (trích xuất dữ liệu, đào tạo lại nhân sự, đóng hợp đồng), nhưng nếu không có ngân sách này, doanh nghiệp sẽ ngại loại bỏ và hệ thống rác rưởi sẽ tiếp tục tồn tại.
5. Công bố Chiến thắng từ việc Loại bỏ
   Khi một dự án bị loại bỏ thành công và nguồn lực được chuyển sang dự án chiến lược tạo ra kết quả (ví dụ: giảm 8% NPL như Case Study 2), hãy công bố kết quả đó. Điều này giúp thay đổi văn hóa, từ sợ hãi thất bại sang chấp nhận loại bỏ như một hành động quản trị ưu việt.

Rủi ro nếu trì hoãn việc Tối ưu hóa Danh mục

Nếu doanh nghiệp tiếp tục cho phép các dự án không liên quan chiến lược sinh sôi nảy nở, hệ quả sẽ là sự lãng phí tài chính và vận hành chồng chất.

1. Thất bại của Dự án Cốt lõi: Các dự án chiến lược (Nhóm A và C) sẽ không bao giờ đạt được tiềm năng, vì nguồn lực tốt nhất luôn bị chia nhỏ cho các dự án “Nice-to-Have” không quan trọng.
2. IT Complexity tăng vọt: Kiến trúc công nghệ trở nên chắp vá, khó bảo trì, chi phí vận hành tăng không kiểm soát (nhân sự, license, Cloud).
3. Mất uy tín Lãnh đạo: Sự thất bại liên tiếp của các dự án nhỏ khiến nhân viên mất niềm tin vào khả năng dẫn dắt Chuyển đổi số của Ban Điều hành.

Chuyển đổi số không phải là việc làm thêm thật nhiều, mà là làm đúng thứ, với sự tập trung cao nhất. Việc học cách nói KHÔNG và Loại bỏ những dự án không liên quan chiến lược chính là bước chuyển đổi tư duy đầu tiên và khó khăn nhất mà Ban Điều hành phải vượt qua.

Nếu doanh nghiệp đang đối mặt với một danh mục dự án hỗn loạn, chi phí IT tăng cao mà không thấy hiệu quả chiến lược rõ ràng, hoặc cần một cái nhìn khách quan từ bên ngoài để xác định các dự án cần “khai tử” và tái cấu trúc nguồn lực, việc trao đổi sâu hơn về Khung Quản trị Danh mục Dự án (DPPO) là bước đi cần thiết ngay lúc này.