Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Bài 7 — Project charter và business case

Mở đầu — vì sao bài này quan trọng

Hãy tưởng tượng bạn được sếp giao nhiệm vụ: "Em xử lý giúp cái vụ giao hàng trễ đi, dạo này khách than nhiều quá." Nghe có vẻ rõ ràng, nhưng thực ra đây là một mệnh lệnh đầy cạm bẫy. Trễ là trễ bao nhiêu phần trăm? Khách nào, sản phẩm nào? Trễ làm công ty mất bao nhiêu tiền? Khi nào thì coi là "xong"? Ai là người đứng ra chịu trách nhiệm, và ai có quyền phê duyệt nguồn lực? Nếu không trả lời được những câu hỏi này trước khi bắt tay vào việc, dự án của bạn gần như chắc chắn sẽ trôi dạt: phạm vi phình to, các bên liên quan cãi nhau về mục tiêu, và sau ba tháng bạn không chứng minh được mình đã tạo ra giá trị gì.

Trong Lean Six Sigma, công cụ giải quyết đúng những rủi ro này chính là Project Charter (bản tuyên ngôn dự án) cùng với Business Case (luận cứ kinh doanh) nằm bên trong nó. Charter là tài liệu đầu tiên bạn tạo ra trong giai đoạn Define, là "hợp đồng" giữa nhóm dự án và ban lãnh đạo. Nó biến một lời than mơ hồ thành một bài toán cụ thể, có thể đo lường, có ranh giới rõ ràng và được cấp phép chính thức.

Một thống kê đáng suy ngẫm: phần lớn các dự án Six Sigma thất bại không phải vì người làm thiếu công cụ thống kê, mà vì charter ngay từ đầu đã sai — vấn đề định nghĩa lệch, mục tiêu phi thực tế, hoặc business case không ai tin. Viết charter tốt là kỹ năng nền tảng nhất của một Green Belt. Bài này sẽ dạy bạn cách làm chủ nó.

Khái niệm cốt lõi

Project Charter là gì và vì sao nó tồn tại

Project Charter là một tài liệu ngắn — lý tưởng là gói gọn trong một đến hai trang — tóm tắt toàn bộ thông tin nền tảng của dự án. Nó được tạo ra ở đầu giai đoạn Define của lộ trình DMAIC và thường được Champion (người bảo trợ dự án, thường là một quản lý cấp cao) cùng nhóm dự án ký duyệt.

Charter phục vụ ba mục đích sống còn:

  • Liên kết (Alignment): đảm bảo nhóm dự án, Champion và các bên liên quan hiểu giống nhau về việc đang giải quyết vấn đề gì.
  • Cấp phép (Authorization): chính thức cho phép nhóm sử dụng thời gian, con người và ngân sách.
  • Tập trung (Focus): ngăn dự án "trượt phạm vi" (scope creep) — hiện tượng dự án cứ phình to vì ai cũng muốn nhét thêm vấn đề của mình vào.
Charter không phải tài liệu viết một lần rồi cất tủ. Nó là tài liệu sống: khi đi sâu vào giai đoạn Measure và Analyze, bạn thường phải quay lại tinh chỉnh mục tiêu hoặc phạm vi dựa trên dữ liệu thực tế.

8 thành phần của một Project Charter

Một charter chuẩn gồm 8 phần. Hãy nắm thật chắc từng phần.

1. Problem Statement (Tuyên bố vấn đề). Đây là phần quan trọng nhất và cũng hay bị làm sai nhất. Một problem statement tốt phải cụ thể, đo lường được và có mốc thời gian (specific, measurable, time-bound). Nó mô tả "đau ở đâu" mà tuyệt đối không được nhắc tới nguyên nhân hay giải pháp. Công thức gợi ý: Trong khoảng thời gian [X], tại [quy trình/địa điểm], [chỉ số] đã [ở mức nào], so với mục tiêu/chuẩn [bao nhiêu], gây ra [tác động].

Ví dụ tốt: "Từ tháng 1 đến tháng 5/2026, tỷ lệ đơn hàng giao trễ tại kho Hà Nội là 18%, so với cam kết SLA là tối đa 5%, dẫn đến 42 khiếu nại khách hàng và 3 hợp đồng bị hủy."

Ví dụ tệ: "Khách hàng không hài lòng vì giao hàng chậm." (Không số liệu, không thời gian, không phạm vi.)

2. Business Case (Luận cứ kinh doanh). Trả lời câu hỏi "Tại sao phải làm dự án này, mà không phải dự án khác?" bằng ngôn ngữ tiền bạc. Đây là phần thuyết phục lãnh đạo bỏ nguồn lực. Business case lượng hóa tác động tài chính: chi phí hiện tại của vấn đề, khoản tiết kiệm tiềm năng, doanh thu được bảo vệ, hoặc rủi ro tránh được. Một business case mạnh thường liên hệ vấn đề với COPQ (Cost of Poor Quality — chi phí của chất lượng kém, sẽ học sâu ở Bài 10).

3. Goal Statement (Tuyên bố mục tiêu). Mục tiêu nên tuân theo nguyên tắc SMART (Specific, Measurable, Achievable, Relevant, Time-bound). Goal statement phản chiếu problem statement nhưng theo hướng tích cực và thường khiêm tốn về mức cải thiện. Quy tắc kinh nghiệm: đặt mục tiêu giảm 50–70% khoảng cách giữa hiện trạng và lý tưởng, chứ đừng hứa "đạt 100% hoàn hảo".

Ví dụ: "Giảm tỷ lệ giao trễ tại kho Hà Nội từ 18% xuống còn 6% trước ngày 31/12/2026."

4. Scope (Phạm vi). Xác định ranh giới: dự án bắt đầu ở đâu, kết thúc ở đâu (start/end points), bao gồm cái gì (in-scope) và không bao gồm cái gì (out-of-scope). Phần "out-of-scope" thường bị bỏ quên nhưng lại là tấm khiên mạnh nhất chống scope creep.

5. Timeline / Milestones (Mốc thời gian). Lịch trình theo các giai đoạn DMAIC, ví dụ: Define xong tuần 2, Measure xong tuần 6, Analyze tuần 10, Improve tuần 16, Control tuần 20.

6. Team & Roles (Nhóm và vai trò). Liệt kê Champion, Project Lead (thường là Green Belt), các thành viên nhóm, và Process Owner. Phân tích vai trò chi tiết hơn sẽ học ở Bài 11 (Stakeholder analysis và RACI).

7. Metrics (Chỉ số đo lường). Xác định chỉ số chính (primary metric) — thứ bạn cam kết cải thiện, và chỉ số đối trọng (secondary/counterbalance metric) — thứ bạn không được làm tệ đi trong khi tối ưu chỉ số chính.

8. Expected Benefits & Costs (Lợi ích và chi phí dự kiến). Ước tính lợi ích tài chính (hard savings và soft savings) và chi phí thực hiện dự án.

Phân biệt hard savings và soft savings

Khi viết business case, bạn phải hiểu rõ hai loại tiết kiệm, vì lãnh đạo tài chính (CFO) đánh giá chúng rất khác nhau:

  • Hard savings (tiết kiệm cứng): tác động trực tiếp lên bảng cân đối — giảm chi phí nguyên vật liệu, giảm số nhân sự cần thuê, giảm chi phí làm lại, tránh được khoản phạt. Đây là tiền CFO "tin" được.
  • Soft savings (tiết kiệm mềm): lợi ích thật nhưng khó quy ra tiền chắc chắn — tiết kiệm thời gian nhân viên (mà không sa thải ai), tăng sự hài lòng khách hàng, giảm rủi ro. Vẫn nên ghi nhận, nhưng đừng dồn hết kỳ vọng vào đó.
Nguyên tắc vàng: business case nên đứng vững chỉ dựa trên hard savings. Soft savings là phần thưởng cộng thêm.

Tình huống thực tế

Tình huống 1 — Chuỗi cà phê The Coffee House và đơn hàng app giao trễ

Một chuỗi cà phê lớn tại TP.HCM (gọi là tình huống dựa trên mô hình The Coffee House) nhận thấy đơn đặt qua app giao đến tay khách trễ hơn cam kết. Quản lý vận hành ban đầu viết charter với problem statement: "Cải thiện trải nghiệm giao hàng trên app."

Một Green Belt được đào tạo bài bản đã viết lại: "Từ Q1/2026, 23% đơn đặt qua app tại 40 cửa hàng khu vực trung tâm được giao trễ hơn 30 phút so với thời gian cam kết, dẫn đến điểm đánh giá app trung bình tụt từ 4.5 xuống 3.8 sao và ước tính mất 1,2 tỷ đồng doanh thu lặp lại mỗi quý."

Business case được xây như sau: mỗi đơn trễ làm giảm xác suất khách đặt lại trong 30 ngày tới khoảng 15%. Với 23% trên tổng 200.000 đơn/quý, hard savings từ việc giữ chân khách được ước tính ~900 triệu đồng/quý, cộng giảm chi phí voucher xin lỗi ~150 triệu. Goal statement: "Giảm tỷ lệ giao trễ trên 30 phút từ 23% xuống 8% trước cuối Q3/2026."

Bài học: chỉ riêng việc viết lại problem statement đã thay đổi cuộc chơi. Phiên bản đầu khiến nhóm dễ lao vào "làm lại giao diện app" — một giải pháp ngẫu nhiên. Phiên bản sau buộc nhóm tập trung đúng vào con số 30 phút và quy trình giao hàng. Chú ý charter không nói nguyên nhân là gì — đó là việc của giai đoạn Analyze.

Tình huống 2 — Nhà máy dệt may ở Bình Dương và business case bị CFO bác

Một nhà máy may xuất khẩu ở Bình Dương khởi động dự án giảm lỗi đường may. Green Belt viết business case rất hùng hồn: "Dự án sẽ tăng tinh thần công nhân, nâng cao uy tín thương hiệu và tiết kiệm khoảng 5 tỷ đồng mỗi năm." CFO đọc xong gạch bỏ, không duyệt.

Vấn đề: toàn bộ 5 tỷ là soft savings không có cơ sở. "Tinh thần công nhân" và "uy tín" không quy ra tiền được. Nhóm phải làm lại. Lần này họ bóc tách: tỷ lệ hàng phải may lại (rework) là 6%, mỗi sản phẩm rework tốn 18.000 đồng nhân công và nguyên liệu; với sản lượng 2 triệu sản phẩm/năm, riêng rework đã ngốn 2,16 tỷ đồng/năm. Thêm vào đó, lô hàng bị khách Mỹ trả về năm ngoái khiến công ty chịu phạt 800 triệu. Đây mới là hard savings thật.

Business case mới: "Giảm tỷ lệ rework từ 6% xuống 2% giúp tiết kiệm trực tiếp ~1,44 tỷ đồng/năm chi phí làm lại, cộng giảm rủi ro phạt hợp đồng ~800 triệu." CFO duyệt ngay.

Bài học: business case phải đứng vững trên hard savings có thể truy vết tới hóa đơn, bảng lương, hợp đồng. Soft savings chỉ nên là phần thưởng kèm thêm, không bao giờ là trụ chính.

Tình huống 3 — Bệnh viện tư và charter không có "out-of-scope"

Một bệnh viện tư tại Hà Nội triển khai dự án giảm thời gian chờ của bệnh nhân ngoại trú. Charter ban đầu chỉ ghi phạm vi là "quy trình khám ngoại trú", không nói rõ điểm đầu, điểm cuối, và không có mục out-of-scope.

Hậu quả: tuần thứ tư, một bác sĩ trưởng khoa yêu cầu nhóm "tiện thể" xử lý luôn cả vấn đề xếp lịch phẫu thuật; phòng dược muốn nhóm cải tổ kho thuốc. Phạm vi phình to gấp ba, nhóm 5 người quá tải, dự án trễ hai tháng và suýt bị hủy.

Champion phải can thiệp, viết lại scope: bắt đầu từ "bệnh nhân lấy số thứ tự" đến "bệnh nhân rời quầy thanh toán sau khám"; out-of-scope ghi rõ: không bao gồm phẫu thuật, không bao gồm quản lý kho dược, không bao gồm bệnh nhân nội trú.

Bài học: mục out-of-scope không phải thủ tục cho có. Nó là công cụ chính trị giúp Green Belt lịch sự từ chối những yêu cầu nằm ngoài dự án, với sự bảo trợ của charter đã được ký.

Hướng dẫn từng bước

Đây là quy trình thực tế để soạn một charter từ đầu:

  • Thu thập bối cảnh. Trao đổi với Champion và Process Owner để hiểu "nỗi đau" thực sự. Hỏi: vấn đề đã tồn tại bao lâu, ai chịu ảnh hưởng, đã có ai cố giải quyết chưa.
  • Viết nháp Problem Statement. Ép mình điền đủ bốn yếu tố: thời gian, địa điểm/quy trình, chỉ số định lượng, tác động. Đọc lại và tự hỏi: "Câu này có lén nhắc nguyên nhân hay giải pháp không?" Nếu có, xóa đi.
  • Lượng hóa Business Case. Lấy số từ phòng tài chính, không tự bịa. Tách riêng hard savings và soft savings. Kiểm tra: nếu bỏ hết soft savings, business case còn thuyết phục không?
  • Đặt Goal Statement theo SMART. Phản chiếu problem statement nhưng theo hướng cải thiện. Đừng hứa hoàn hảo — nhắm giảm 50–70% khoảng cách.
  • Vẽ Scope. Xác định điểm bắt đầu và kết thúc của quy trình. Liệt kê in-scope và đặc biệt là out-of-scope.
  • Lập Timeline theo DMAICxác định Team & Roles.
  • Chọn Metrics: một primary metric và ít nhất một counterbalance metric.
  • Trình Champion phê duyệt và ký. Charter chưa ký thì dự án chưa thực sự bắt đầu.

Lỗi thường gặp & mẹo

  • Lén đưa giải pháp vào problem statement. "Vấn đề là chúng ta cần một phần mềm CRM mới." Sai — đó là giải pháp giả định. Nếu đã biết giải pháp thì cần gì DMAIC? Chỉ mô tả triệu chứng đo được.
  • Problem statement không có số. Nếu không đo được hiện trạng, bạn sẽ không bao giờ chứng minh được cải thiện. Luôn có con số baseline.
  • Mục tiêu phi thực tế. Hứa "giảm lỗi về 0" trong 3 tháng là tự sát. Champion sẽ mất niềm tin khi bạn không đạt. Đặt mục tiêu tham vọng nhưng khả thi.
  • Business case toàn soft savings. Như tình huống 2 — CFO sẽ bác. Luôn có ít nhất một trụ hard savings.
  • Quên counterbalance metric. Nếu chỉ tối ưu tốc độ giao hàng mà không theo dõi chi phí, bạn có thể "cải thiện" bằng cách đốt tiền ship hỏa tốc. Counterbalance metric giữ bạn trung thực.
  • Scope quá rộng. Một dự án Green Belt nên giải quyết được trong 4–6 tháng. Nếu phạm vi quá lớn, hãy chẻ thành nhiều dự án nhỏ.
  • Mẹo một câu thử nghiệm: đọc problem statement cho một người ngoài bộ phận nghe. Nếu họ hiểu ngay vấn đề ở đâu, lớn cỡ nào, mà không cần hỏi lại — charter của bạn đạt.

Bài tập thực hành

Hãy chọn một vấn đề thực tế tại nơi bạn làm việc (hoặc tình huống giả định) và soạn một mini-charter:

  • Viết Problem Statement đầy đủ bốn yếu tố (thời gian, địa điểm/quy trình, chỉ số định lượng có baseline, tác động). Tự kiểm tra xem có lẫn nguyên nhân/giải pháp không.
  • Xây Business Case với ít nhất một con số hard savings có nguồn gốc rõ ràng (hóa đơn, bảng lương, hợp đồng) và một soft savings tách riêng.
  • Viết Goal Statement theo SMART, nhắm giảm 50–70% khoảng cách giữa hiện trạng và lý tưởng.
  • Xác định Scope gồm điểm bắt đầu, điểm kết thúc, ít nhất 2 mục in-scope và 2 mục out-of-scope.
  • Chọn 1 primary metric và 1 counterbalance metric.
Bài tập nâng cao: đưa problem statement của bạn cho một đồng nghiệp ngoài bộ phận đọc. Ghi lại những câu hỏi họ đặt ra — mỗi câu hỏi là một chỗ charter của bạn còn mơ hồ. Sửa lại cho tới khi không còn câu hỏi nào.

Tóm tắt

Project Charter là tài liệu nền tảng của giai đoạn Define, đóng vai trò "hợp đồng" giữa nhóm dự án và lãnh đạo. Tám thành phần cốt lõi là: Problem Statement, Business Case, Goal Statement, Scope, Timeline, Team & Roles, Metrics, và Expected Benefits & Costs.

Ba điều quan trọng nhất cần khắc cốt ghi tâm: (1) Problem statement phải cụ thể, đo lường được, có mốc thời gian — và tuyệt đối không chứa nguyên nhân hay giải pháp; (2) Business case phải đứng vững trên hard savings có thể truy vết tới tài chính thật, soft savings chỉ là thưởng thêm; (3) Scope, đặc biệt là phần out-of-scope, là tấm khiên chống scope creep.

Một charter tốt không đảm bảo dự án thành công, nhưng một charter tồi gần như đảm bảo thất bại. Đây là kỹ năng bạn sẽ dùng trong mọi dự án Lean Six Sigma suốt sự nghiệp. Ở các bài tiếp theo, chúng ta sẽ đào sâu từng công cụ trong giai đoạn Define — bắt đầu với SIPOC diagram (Bài 8) để vẽ bức tranh tổng thể quy trình.

Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi