Từ trang giấy đến thực tế: Lập kế hoạch thực thi (Execution Plan) cho một dự án chuyển đổi số từ 6-12 tháng.
DX

Từ trang giấy đến thực tế: Lập kế hoạch thực thi (Execution Plan) cho một dự án chuyển đổi số từ 6-12 tháng.

7/11/2026 · 13p đọc

Có một sự thật khó chịu mà ít bản chiến lược nào chịu ghi thẳng ra: phần lớn các sáng kiến chuyển đổi số không chết vì chiến lược sai. Chúng chết vì không ai biến được chiến lược thành một chuỗi hành động có thể thực thi, đo được và điều chỉnh được theo tuần. Bản slide tầm nhìn được vỗ tay ở hội đồng quản trị, rồi sáu tháng sau không ai trả lời được câu hỏi đơn giản: "Chúng ta đang ở đâu, đã tạo ra giá trị gì, và tuần tới ai làm gì?"

Khoảng cách giữa một tầm nhìn hay và một kết quả thật không phải là khoảng cách về ý tưởng. Đó là khoảng cách về thực thi — và nó là nơi tiền của bạn bốc hơi. Một dự án được cấp ngân sách chục tỷ nhưng trôi dạt trong mười hai tháng không đơn thuần mất phần chi phí đã tiêu; nó đốt luôn chi phí cơ hội của thị trường, làm mòn niềm tin nội bộ, và dạy cho tổ chức một bài học độc hại: "chuyển đổi số là thứ nói nhiều làm ít".

Bài viết này không bàn về chiến lược nữa — giả định bạn đã có. Nó bàn về thứ đứng giữa trang giấy và thực tế: một execution plan (kế hoạch thực thi) 6–12 tháng đủ chặt để dẫn đường, đủ mềm để không gãy khi thực tế va vào.

Vì sao chiến lược tốt vẫn thất bại ở khâu thực thi

Thất bại thực thi hiếm khi đến từ một sai lầm lớn. Nó đến từ sự tích tụ của những lỗi cấu trúc mà không ai chịu trách nhiệm trọn vẹn. Có bốn nguyên nhân gốc mà một lãnh đạo cấp cao cần nhận diện, vì cả bốn đều nằm ở tầng quyết định của bạn, không phải tầng thừa hành.

Thứ nhất, kế hoạch được viết ở độ cao 10.000 mét nhưng thực thi diễn ra ở mặt đất. "Số hóa quy trình bán hàng trong quý 3" không phải là kế hoạch — đó là một nguyện vọng. Không có phân rã thành các sản phẩm cụ thể, người chịu trách nhiệm, và mốc đo, câu đó vô nghĩa với người thực thi.

Thứ hai, kế hoạch đo tiến độ kỹ thuật thay vì đo giá trị. Đội dự án báo cáo "đã hoàn thành 70% tính năng" trong khi doanh thu, chi phí vận hành hay trải nghiệm khách hàng chưa nhúc nhích. Bạn đang trả tiền cho hoạt động (activity), không phải cho kết quả (outcome).

Thứ ba, nguồn lực được cam kết một lần đầu kỳ rồi bị các ưu tiên vận hành hàng ngày gặm nhấm dần. Nhân sự giỏi nhất bị kéo về "cứu hỏa" business-as-usual (BAU — công việc vận hành thường nhật), và dự án âm thầm thiếu máu.

Thứ tư, không có cơ chế quản trị nào đủ quyền lực để ra quyết định đánh đổi (trade-off) khi thực tế phát sinh. Mọi vướng mắc đều leo thang, nhưng không leo đến đâu.

GÓC NHÌN C-LEVEL

  • Nếu tôi hỏi ngẫu nhiên một trưởng nhóm dự án "tuần này việc quan trọng nhất là gì và nó nối với giá trị nào của công ty", họ có trả lời được trong 30 giây không?
  • Bản kế hoạch của chúng ta đang đo tiến độ bằng tính năng hoàn thành, hay bằng giá trị P&L (lãi/lỗ) đã hiện thực hóa?
  • Ai là người thực sự có quyền cắt phạm vi (scope) hoặc dời nguồn lực khi dự án gặp cản trở — và người đó có họp mỗi hai tuần không?
  • Khi một nhân sự chủ chốt của dự án bị kéo về việc vận hành, tôi có biết không, hay tôi chỉ biết ba tháng sau khi tiến độ đã trượt?

Nguyên tắc nền: Think big, start small, scale fast

Trước khi bàn về khung, cần đóng đinh một nguyên tắc chi phối toàn bộ cách chia giai đoạn: nghĩ lớn, khởi động nhỏ, mở rộng nhanh.

Nghĩ lớn (think big) là giữ tầm nhìn cuối cùng ở kích thước tham vọng — bạn không chuyển đổi số để cải tiến 5%, mà để thay đổi cách công ty tạo ra và giữ giá trị. Khởi động nhỏ (start small) là chọn một lát cắt đủ hẹp để chứng minh giả thuyết giá trị trong vài tháng, với rủi ro kiểm soát được, thay vì "big bang" toàn tổ chức. Mở rộng nhanh (scale fast) là khi lát cắt đó chứng minh được giá trị, đổ nguồn lực vào nhân rộng thật nhanh trước khi động lực nguội đi và đối thủ kịp phản ứng.

Sai lầm phổ biến của doanh nghiệp Việt quy mô vừa và lớn nằm ở hai đầu. Một số công ty "nghĩ nhỏ, làm nhỏ" — làm vài pilot rời rạc, không bao giờ chạm tới quy mô tạo ra khác biệt P&L. Một số khác "nghĩ lớn, làm lớn ngay" — triển khai ERP toàn tập đoàn trong một lần, để rồi sa lầy 18 tháng. Kỷ luật thực thi nằm ở việc giữ cả ba vế cùng lúc: tham vọng lớn ở đích, khiêm tốn ở bước đầu, và quyết liệt ở khâu nhân rộng.

Khung một execution plan 6–12 tháng: chia theo horizon và wave

Một kế hoạch thực thi tốt không phải một danh sách công việc dài. Nó là một kiến trúc có tầng. Cách hiệu quả nhất là chia theo horizon (chân trời thời gian) và bên trong mỗi horizon là các wave (đợt triển khai).

Ba horizon cho một chu kỳ 6–12 tháng thường được cấu trúc như sau:

  • Horizon 1 — Nền móng & Bằng chứng (tháng 1–3): thiết lập nền tảng tối thiểu (dữ liệu, hạ tầng, đội ngũ, cơ chế quản trị) và giao được một MVP — sản phẩm khả dụng tối thiểu (Minimum Viable Product) tạo ra giá trị thật, dù nhỏ, cho một nhóm người dùng thật. Mục tiêu của horizon này không phải hoàn hảo, mà là bằng chứng: chứng minh mô hình chạy được và có người dùng.
  • Horizon 2 — Mở rộng & Đào sâu (tháng 4–8): lấy cái đã được chứng minh và nhân rộng ra nhiều phòng ban/địa bàn/nhóm khách hàng hơn, đồng thời bổ sung chiều sâu tính năng. Đây là giai đoạn giá trị bắt đầu hiện lên trong con số P&L.
  • Horizon 3 — Thể chế hóa & Tối ưu (tháng 9–12): đưa cái mới thành cách làm mặc định (thể chế hóa), tối ưu chi phí vận hành, và chuyển giao quyền sở hữu từ đội dự án về đội vận hành. Kết thúc horizon này, sáng kiến không còn là "dự án" mà đã là "cách chúng ta làm việc".

Bên trong mỗi horizon, chia thành các wave 4–6 tuần. Mỗi wave có một mục tiêu giá trị rõ ràng, một sản phẩm bàn giao, và một điểm dừng để đánh giá "tiếp tục / điều chỉnh / dừng". Nhịp wave ngắn là cơ chế phòng thủ chống lại trượt tiến độ: bạn không đợi đến cuối quý mới biết mình sai.

Mốc giá trị, không chỉ mốc kỹ thuật

Đây là điểm phân biệt một kế hoạch trưởng thành với một kế hoạch ngây thơ. Mỗi mốc quan trọng phải được định nghĩa bằng giá trị chứ không chỉ bằng kỹ thuật.

Mốc kỹ thuật (chưa đủ) Mốc giá trị (đúng chuẩn C-Level)
"Hoàn thành tích hợp API thanh toán" "Rút ngắn thời gian đối soát thanh toán từ 3 ngày xuống dưới 4 giờ"
"Go-live module CRM" "80% đội sales dùng CRM hằng ngày và tỷ lệ lead thất lạc giảm một nửa"
"Triển khai dashboard báo cáo" "Ban điều hành ra quyết định tồn kho dựa trên số liệu ngày hôm qua thay vì tuần trước"
"Số hóa quy trình phê duyệt" "Thời gian phê duyệt trung bình giảm từ 5 ngày xuống 1 ngày, giải phóng vốn lưu động"

Nguyên tắc: nếu một mốc không thể diễn đạt bằng một thay đổi mà CFO hoặc COO quan tâm, đó chưa phải mốc — đó mới là một tác vụ. Mọi wave nên gắn với ít nhất một mốc giá trị, và mốc đó phải đo được trước khi wave được tuyên bố "xong".

Cơ chế quản trị: Steering Committee và Transformation Office

Kế hoạch không tự thực thi. Nó cần một bộ máy điều hành, và bộ máy này có hai lớp không được lẫn lộn.

Lớp thứ nhất là Steering Committee (hội đồng chỉ đạo) — nơi ra quyết định chiến lược và tháo gỡ vướng mắc vượt thẩm quyền dự án. Thành phần phải gồm những người thực sự nắm ngân sách và nguồn lực: một sponsor cấp C-Level làm chủ tịch, các lãnh đạo phòng ban bị tác động, và trưởng ban chuyển đổi. Điều quan trọng nhất về Steering Committee không phải nó tồn tại, mà là nó họp đều, họp ngắn, và ra quyết định thật. Một hội đồng họp mỗi hai đến bốn tuần, mỗi buổi 60–90 phút, tập trung vào ba câu hỏi: giá trị đã tạo ra đến đâu, đâu là vướng mắc cần tôi gỡ, và có nên thay đổi phạm vi hay nguồn lực không. Một hội đồng chỉ nghe báo cáo và gật đầu là một hội đồng vô dụng.

Lớp thứ hai là Transformation Office / PMO (văn phòng chuyển đổi / văn phòng quản lý dự án) — bộ máy vận hành hằng ngày biến quyết định thành hành động. Đây không phải một nhóm hành chính ghi biên bản. Vai trò thật của nó gồm bốn việc: (1) duy trì nhịp thực thi — cadence của wave, review, báo cáo; (2) quản lý phụ thuộc và rủi ro xuyên các luồng công việc; (3) giữ nguồn dữ liệu sự thật duy nhất về tiến độ và giá trị; (4) là nơi leo thang có địa chỉ khi luồng công việc mắc kẹt.

Với doanh nghiệp Việt quy mô vừa, không nhất thiết lập một PMO cồng kềnh. Nhưng nhất thiết phải có một người — một transformation lead — được trao quyền và thời gian đủ để làm bốn việc trên, thay vì kiêm nhiệm 20% bên cạnh công việc chính. Sự nửa vời ở vị trí này là một trong những chỉ báo sớm nhất của thất bại.

Phân bổ nguồn lực, ngân sách và quản lý phụ thuộc

Một kế hoạch thực thi trưởng thành phân bổ nguồn lực theo giai đoạn, không cam kết toàn bộ ngân sách một lần. Cách làm hiệu quả là gắn giải ngân với cổng giá trị (value gate): Horizon 1 được cấp đủ để chứng minh; chỉ khi bằng chứng đạt, Horizon 2 mới mở khóa phần ngân sách lớn hơn để nhân rộng. Đây chính là tư duy đầu tư mạo hiểm áp vào nội bộ — bạn rót vốn theo vòng, đổi lấy dữ liệu về khả năng thành công, thay vì đặt cược toàn bộ ngay từ đầu.

Cách phân bổ theo horizon có thể hình dung qua bảng lộ trình mẫu sau:

Chiều Horizon 1 (Q1) Horizon 2 (Q2–Q3) Horizon 3 (Q4)
Mục tiêu Bằng chứng giá trị qua MVP Nhân rộng & đào sâu Thể chế hóa & tối ưu
Phạm vi 1 luồng, 1 nhóm người dùng Nhiều luồng/phòng ban Toàn tổ chức, chuyển giao BAU
Nguồn lực Đội nhỏ, tinh nhuệ, toàn thời gian Mở rộng đội, thêm chuyên môn Thu hẹp đội dự án, tăng đội vận hành
Ngân sách ~15–20% (khám phá) ~50–60% (nhân rộng) ~20–30% (tối ưu, chuyển giao)
Mốc giá trị chính Giảm X% thời gian/chi phí ở 1 quy trình Giá trị hiện trong P&L, mở rộng phạm vi Giá trị bền vững, đội vận hành tự chủ
Rủi ro trọng tâm Giả thuyết giá trị có đúng không? Đội ngũ và dữ liệu có chịu được quy mô? Người dùng có duy trì thói quen mới?

(Tỷ lệ ngân sách chỉ mang tính minh họa cho tư duy phân bổ, cần hiệu chỉnh theo bối cảnh từng dự án.)

Về quản lý phụ thuộc (dependency): phần lớn dự án trượt không phải vì một luồng công việc chậm, mà vì một luồng chờ luồng khác. Đội xây tính năng chờ đội dữ liệu làm sạch; đội dữ liệu chờ phòng ban ký duyệt quyền truy cập; phòng ban chờ pháp chế. Transformation Office phải duy trì một bản đồ phụ thuộc rõ ràng và chủ động gỡ nút thắt trước khi nó thành đường tới hạn (critical path). Ở thị trường Việt Nam, phụ thuộc nguy hiểm nhất thường không phải kỹ thuật mà là quyết định — ai đó cấp trên chưa duyệt, và cả dây chuyền đứng chờ. Đó là lý do Steering Committee phải họp đủ đều để không trở thành nút thắt.

Về rủi ro: mỗi wave nên duy trì một danh mục rủi ro sống (không phải bản Excel lập một lần rồi quên), phân loại theo khả năng xảy ra và mức tác động, với người chịu trách nhiệm và hành động giảm thiểu cụ thể. Rủi ro lớn nhất của chuyển đổi số hiếm khi là công nghệ — nó là con người không đổi cách làm việc. Kế hoạch nào không dành nguồn lực rõ ràng cho quản lý thay đổi (change management) là kế hoạch đang giấu rủi ro lớn nhất của chính nó.

Dấu hiệu cảnh báo sớm: kế hoạch đang trượt trước khi báo cáo nói vậy

Báo cáo chính thức luôn là chỉ báo trễ. Đến lúc bảng tiến độ chuyển sang màu đỏ thì thường đã muộn vài tháng. Một lãnh đạo sắc bén đọc các chỉ báo sớm — những dấu hiệu xuất hiện trước khi con số trượt:

  • Ngôn ngữ chuyển từ giá trị sang hoạt động. Khi báo cáo bắt đầu nói nhiều về "đã làm gì" và ít dần về "đã tạo ra kết quả gì", giá trị đang tuột khỏi tầm ngắm.
  • Mốc bị dời nhưng phạm vi không đổi. Dời deadline mà giữ nguyên khối lượng là dấu hiệu kế hoạch phi thực tế đang được che đậy thay vì đối diện.
  • Nhân sự chủ chốt bắt đầu vắng ở các buổi review. Khi người giỏi nhất của dự án bận việc khác, họ đang bỏ phiếu bằng chân về mức ưu tiên thực sự.
  • Danh mục rủi ro đứng yên. Một danh sách rủi ro không thay đổi qua nhiều tuần không có nghĩa mọi thứ ổn — nó có nghĩa không ai còn thật sự quản lý rủi ro.
  • MVP liên tục bị lùi để "làm cho đủ". Xu hướng phình phạm vi trước khi ra mắt là biểu hiện của nỗi sợ đối mặt với người dùng thật — và nó giết chết nguyên tắc start small.
  • Steering Committee chuyển thành buổi nghe báo cáo. Khi hội đồng không còn ra quyết định đánh đổi nào, cơ chế quản trị đã chết dù vẫn họp đều.

Điểm chung của mọi dấu hiệu này: chúng xuất hiện trong hành vi trước khi xuất hiện trong con số. Nhiệm vụ của bạn ở tầng C-Level không phải chờ báo cáo, mà là thiết kế nhịp quản trị đủ dày để nhìn thấy hành vi.

Chốt lại

Chiến lược cho bạn hướng đi. Execution plan cho bạn khả năng thực sự đến đích — và quan trọng hơn, khả năng biết mình đang chệch hướng đủ sớm để chỉnh. Một kế hoạch thực thi 6–12 tháng tốt không phải một tài liệu dày; nó là một kiến trúc gồm ít yếu tố nhưng chặt: chia horizon và wave, gắn mọi mốc với giá trị chứ không chỉ kỹ thuật, một cơ chế quản trị dám ra quyết định, nguồn lực rót theo cổng giá trị, và một bộ radar đọc dấu hiệu trượt trước khi con số xác nhận.

Khoảng cách giữa trang giấy và thực tế không tự khép lại bằng nỗ lực chăm chỉ. Nó khép lại bằng kỷ luật thực thi — thứ mà chỉ người ngồi ở ghế cao nhất mới có đủ quyền lực thiết lập và bảo vệ. Câu hỏi cuối không phải "kế hoạch của chúng ta có hay không", mà là: nếu ba tháng nữa dự án trượt, tôi sẽ biết vào tuần nào — và tôi đã dựng sẵn cơ chế để can thiệp chưa?


Bài trước: Case study OKRs & KPIs · Bài tiếp theo: Nghệ thuật Alignment, phá vỡ Silos