Mở đầu — vì sao bài này quan trọng
Trong cả hành trình DMAIC (Define – Measure – Analyze – Improve – Control), hai phase đầu tiên — Define (Xác định) và Measure (Đo lường) — chính là phần quyết định một dự án Lean Six Sigma sẽ thành công hay thất bại. Lý do rất đơn giản: nếu bạn xác định sai vấn đề ở phase Define, mọi nỗ lực phía sau dù tốn kém đến đâu cũng chỉ là "giải sai bài toán". Và nếu bạn đo lường thiếu chính xác ở phase Measure, bạn sẽ không bao giờ biết được vấn đề thật sự lớn cỡ nào, cũng như sau này có thể chứng minh được mình đã cải thiện thật hay chưa.
Tôi vẫn thường nói với học viên rằng: một Green Belt giỏi dành 50% thời gian dự án cho Define và Measure. Nghe có vẻ nhiều, nhưng đây là khoản đầu tư đáng giá nhất. Một vấn đề được định nghĩa rõ ràng đã là một nửa lời giải. Trong bài này, chúng ta sẽ đi sâu vào "khung xương" của hai phase này: làm sao biến một lời than phiền mơ hồ ("khách hàng phàn nàn nhiều quá") thành một phát biểu vấn đề có số liệu cụ thể, và làm sao thu thập dữ liệu đáng tin cậy để làm nền tảng cho phân tích về sau.
Lưu ý: bài này tập trung vào tư duy và quy trình của Define và Measure. Các công cụ chi tiết như SIPOC, VoC/CTQ, MSA, sample size, hay process capability sẽ được mổ xẻ riêng ở các bài chuyên sâu sau. Ở đây, bạn sẽ nắm được bức tranh tổng thể để hiểu các công cụ đó "lắp" vào đâu trong dòng chảy dự án.
Khái niệm cốt lõi
Define Phase — Xác định vấn đề và phạm vi
Mục tiêu của phase Define là trả lời ba câu hỏi: Chúng ta đang giải quyết vấn đề gì? Tại sao nó quan trọng? Phạm vi dự án tới đâu? Sản phẩm đầu ra cốt lõi của phase này là Project Charter (Bản hiến chương dự án) — tài liệu một trang đóng vai trò "hợp đồng" giữa đội dự án và lãnh đạo.
Một Project Charter tốt gồm các thành phần:
Problem Statement (Phát biểu vấn đề) — Mô tả điều gì đang sai, dựa trên dữ liệu. Đây là phần quan trọng nhất và cũng dễ làm hỏng nhất. Một phát biểu vấn đề tốt phải trả lời được: cái gì sai, sai ở đâu, từ khi nào, lớn cỡ nào, và tác động ra sao — nhưng tuyệt đối không được nêu nguyên nhân hay giải pháp. Ví dụ phát biểu kém: "Nhân viên làm việc cẩu thả nên giao hàng trễ." 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 mục tiêu nội bộ 5%, gây phát sinh 320 triệu đồng chi phí bồi thường và mất 12 khách hàng B2B."
Goal Statement (Phát biểu mục tiêu) — Cụ thể, đo lường được, theo nguyên tắc SMART. Công thức thường dùng: "Giảm/tăng [chỉ số] từ [mức hiện tại] xuống/lên [mức mục tiêu] trước [thời hạn]." Ví dụ: "Giảm tỷ lệ giao trễ tại kho Hà Nội từ 18% xuống còn 5% trước ngày 31/10/2026."
Business Case (Lý do kinh doanh) — Tại sao dự án này đáng làm? Thường gắn với tiền: tiết kiệm chi phí, tăng doanh thu, giảm rủi ro. Scope (Phạm vi) — Cái gì nằm trong, cái gì nằm ngoài. Đây là "hàng rào" bảo vệ dự án khỏi hiện tượng scope creep (phình to phạm vi). Team & Timeline — Ai làm, mốc thời gian từng phase. Metrics — Chỉ số đầu ra (Y) mà dự án sẽ tác động.
Phase Define cũng thường đi kèm hai công cụ hỗ trợ: SIPOC (sơ đồ tổng quan quy trình Supplier–Input–Process–Output–Customer, giúp vẽ ranh giới quy trình) và VoC/CTQ (lắng nghe tiếng nói khách hàng và chuyển thành các yêu cầu chất lượng đo được). Chúng ta sẽ học kỹ ở bài sau, ở đây chỉ cần hiểu chúng nằm trong Define.
Measure Phase — Đo lường hiện trạng
Sau khi đã biết "giải bài toán gì", phase Measure trả lời: Hiện trạng thật sự tệ đến mức nào, và ta đo nó bằng cách nào cho đáng tin? Đây là phase biến cảm tính thành con số. Các bước cốt lõi:
Operational Definition (Định nghĩa thao tác) — Trước khi đo bất cứ thứ gì, cả đội phải thống nhất chính xác cách hiểu chỉ số đó. "Giao trễ" nghĩa là trễ so với ngày hẹn khách, hay so với ngày dự kiến nội bộ? Tính theo ngày làm việc hay ngày lịch? Nếu khách dời lịch thì có tính trễ không? Không có định nghĩa thao tác rõ ràng, hai người đo cùng một thứ sẽ ra hai kết quả khác nhau.
Data Collection Plan (Kế hoạch thu thập dữ liệu) — Đo cái gì, ai đo, đo bằng công cụ nào, tần suất ra sao, lấy mẫu bao nhiêu. Phân biệt rõ dữ liệu rời rạc (discrete/attribute — đếm được như số lỗi, đạt/không đạt) và dữ liệu liên tục (continuous — đo được như thời gian, nhiệt độ, chi phí), vì loại dữ liệu quyết định công cụ phân tích sau này.
Measurement System Analysis (MSA) — Trước khi tin vào dữ liệu, phải kiểm tra hệ thống đo lường có đáng tin không. Nếu chính cái thước của bạn bị sai thì mọi con số đều vô nghĩa. MSA kiểm tra độ lặp lại (repeatability) và độ tái lập (reproducibility) — thường gọi tắt là Gage R&R.
Baseline Capability (Năng lực cơ sở) — Cuối phase Measure, ta tính được mức sigma hiện tại, DPMO, hoặc Cp/Cpk để biết chính xác điểm xuất phát. Đây là "ảnh chụp trước" — cực kỳ quan trọng để sau này so sánh và chứng minh dự án thực sự tạo ra cải thiện.
Tình huống thực tế
Tình huống 1: Chuỗi cà phê tại TP.HCM — Define cứu một dự án khỏi đi sai hướng
Một chuỗi cà phê giả định, "Highland-style", có 40 cửa hàng tại TP.HCM, nhận được nhiều phàn nàn rằng "khách phải chờ lâu". Ban đầu, quản lý vận hành định ngay giải pháp: mua thêm máy pha cà phê cho mỗi cửa hàng, chi phí dự kiến 2 tỷ đồng.
Đội Green Belt được giao xác minh trước khi chi tiền. Họ viết lại phát biểu vấn đề dựa trên dữ liệu: "Trong tháng 4–5/2026, thời gian chờ trung bình từ lúc đặt món đến lúc nhận là 6,8 phút vào khung giờ cao điểm (11h–13h), so với cam kết thương hiệu là 4 phút. 35% đơn vượt ngưỡng 5 phút." Khi vẽ SIPOC và quan sát thực tế, họ phát hiện điểm nghẽn không nằm ở khâu pha chế (máy chạy chưa hết công suất) mà ở khâu thanh toán và truyền order — order viết tay rồi mới nhập máy tính tiền, gây trễ trung bình 2,5 phút.
Bài học: Nếu nhảy thẳng vào giải pháp "mua máy", chuỗi đã đốt 2 tỷ đồng mà không giải quyết vấn đề. Một phát biểu vấn đề trung lập (không gài sẵn nguyên nhân) đã mở đường cho việc tìm đúng điểm nghẽn.
Tình huống 2: Nhà máy linh kiện điện tử ở Bắc Ninh — Measure phơi bày "thước đo dối"
Một nhà máy sản xuất linh kiện cho ngành điện tử tại Bắc Ninh chạy dự án giảm tỷ lệ lỗi hàn (solder defect). Báo cáo nội bộ cho thấy tỷ lệ lỗi 2,3%. Đội dự án đặt mục tiêu giảm xuống 1%.
Nhưng khi làm MSA ở phase Measure, họ phát hiện vấn đề lớn: ba nhân viên QC khác nhau khi kiểm cùng một lô 50 sản phẩm lại đưa ra ba kết quả lệch nhau đáng kể — người thì báo 3 lỗi, người báo 7, người báo 5. Gage R&R cho thấy hệ thống đo lường "ăn" tới 40% biến thiên — nghĩa là phần lớn sự khác biệt trong số liệu đến từ cách người kiểm khác nhau, chứ không phải từ sản phẩm. Con số 2,3% kia hoàn toàn không đáng tin.
Đội phải dừng lại, xây operational definition rõ ràng cho từng loại lỗi (kèm ảnh mẫu chuẩn), đào tạo lại QC, rồi đo lại. Baseline thật sau khi sửa là 3,1% — cao hơn báo cáo cũ.
Bài học: Nếu bỏ qua MSA, đội đã "cải thiện" dựa trên một con số sai. Phase Measure không chỉ là thu thập dữ liệu — nó là đảm bảo dữ liệu đáng tin. Số liệu sai còn nguy hiểm hơn không có số liệu, vì nó tạo cảm giác an toàn giả tạo.
Tình huống 3: Phòng khám tư tại Đà Nẵng — Goal Statement SMART tạo sự đồng thuận
Một phòng khám đa khoa tư nhân tại Đà Nẵng muốn "cải thiện trải nghiệm bệnh nhân". Đây là mục tiêu mơ hồ điển hình — không thể biết bao giờ đạt được. Đội Green Belt làm việc với ban giám đốc, qua khảo sát VoC xác định điều bệnh nhân bức xúc nhất là thời gian chờ khám.
Họ chuyển hóa thành Goal Statement SMART: "Giảm thời gian chờ trung bình từ lúc check-in đến lúc gặp bác sĩ từ 47 phút xuống dưới 25 phút, vào ca sáng các ngày trong tuần, trước 30/9/2026." Vì mục tiêu cụ thể và đo được, ban lãnh đạo dễ dàng phê duyệt nguồn lực, và mọi thành viên đều biết chính xác đích đến.
Bài học: Mục tiêu càng cụ thể và đo lường được, dự án càng dễ được phê duyệt và càng dễ tạo đồng thuận. "Cải thiện trải nghiệm" thì ai cũng gật đầu nhưng không ai chịu trách nhiệm; "giảm xuống dưới 25 phút trước 30/9" thì có người chịu trách nhiệm thật.
Hướng dẫn từng bước
Bước 1 — Viết Problem Statement dựa trên dữ liệu. Trả lời: cái gì sai, ở đâu, từ khi nào, lớn cỡ nào, tác động gì. Kiểm tra lại: phát biểu của bạn có vô tình nêu nguyên nhân ("vì nhân viên...") hay giải pháp ("cần mua thêm...") không? Nếu có, hãy xóa đi — đó là việc của phase Analyze và Improve.
Bước 2 — Chuyển thành Goal Statement SMART. Lấy đúng chỉ số trong problem statement, gắn mức hiện tại, mức mục tiêu và thời hạn. Mục tiêu nên thách thức nhưng khả thi (thường giảm 50–70% khoảng cách tới mức lý tưởng là hợp lý cho một dự án Green Belt).
Bước 3 — Xác định Business Case và Scope. Quy đổi vấn đề ra tiền nếu có thể. Vẽ rõ ranh giới: quy trình bắt đầu ở đâu, kết thúc ở đâu; cửa hàng/nhà máy/phòng ban nào nằm trong dự án. Ghi rõ cả những gì nằm ngoài phạm vi.
Bước 4 — Hoàn thiện Project Charter và xin phê duyệt. Gộp các phần trên thành một trang, bổ sung đội ngũ và timeline. Trình Champion/lãnh đạo ký. Đây là "tấm vé" chính thức để dự án khởi động.
Bước 5 — Lập Operational Definition cho mọi chỉ số. Viết ra chính xác cách đo từng chỉ số, sao cho hai người bất kỳ đo cùng đối tượng sẽ ra cùng kết quả.
Bước 6 — Lập Data Collection Plan. Xác định loại dữ liệu (rời rạc hay liên tục), nguồn, người thu thập, tần suất, cỡ mẫu, và biểu mẫu ghi chép (check sheet).
Bước 7 — Kiểm tra hệ thống đo lường (MSA). Đảm bảo "cái thước" đáng tin trước khi tin vào số liệu. Sửa hệ thống đo nếu cần rồi mới thu thập chính thức.
Bước 8 — Thiết lập Baseline. Tính mức hiệu năng hiện tại (DPMO, sigma level, Cp/Cpk hoặc đơn giản là tỷ lệ %). Lưu lại làm "ảnh chụp trước" để sau này chứng minh cải thiện.
Lỗi thường gặp & mẹo
Lỗi 1 — Gài sẵn giải pháp vào Problem Statement. Đây là lỗi phổ biến nhất. "Vì thiếu nhân viên nên xử lý chậm" đã khóa cứng tư duy đội vào một nguyên nhân chưa được chứng minh. Mẹo: viết problem statement xong, đọc lại và gạch bỏ mọi từ chỉ nguyên nhân/giải pháp.
Lỗi 2 — Mục tiêu mơ hồ, không đo được. "Cải thiện", "nâng cao", "tối ưu" mà không có con số là dấu hiệu của một dự án sẽ trôi dạt. Mẹo: nếu không gắn được số vào goal statement, nghĩa là bạn chưa hiểu vấn đề đủ sâu — quay lại phase Define.
Lỗi 3 — Phạm vi quá rộng. "Cải thiện toàn bộ chuỗi cung ứng" là dự án của cả một năm với cả Black Belt. Green Belt nên chọn phạm vi gọn, làm được trong 3–6 tháng. Mẹo: thà giải quyết trọn vẹn một quy trình nhỏ còn hơn động vào mười quy trình mà không xong cái nào.
Lỗi 4 — Bỏ qua MSA, tin ngay vào dữ liệu sẵn có. Như tình huống Bắc Ninh, số liệu có thể sai mà bạn không hề biết. Mẹo: luôn hỏi "ai đo cái này, bằng cách nào, có nhất quán không?" trước khi xây cả dự án trên một con số.
Lỗi 5 — Không chốt baseline trước khi cải thiện. Nếu không có "ảnh chụp trước", cuối dự án bạn không thể chứng minh mình đã tạo ra giá trị gì. Mẹo: baseline phải được đo bằng đúng operational definition sẽ dùng để đo kết quả cuối — nếu không, so sánh sẽ khập khiễng.
Mẹo chung: Đừng vội. Áp lực thường khiến đội muốn "nhảy vào sửa ngay". Nhưng thời gian bỏ ra cho Define và Measure luôn được hoàn vốn gấp nhiều lần ở các phase sau, vì bạn sẽ không phải làm lại từ đầu.
Bài tập thực hành
Bài 1 — Sửa Problem Statement. Cho phát biểu sau: "Bộ phận chăm sóc khách hàng làm việc thiếu chuyên nghiệp khiến khách hàng không hài lòng, cần tuyển thêm người và đào tạo lại." Hãy viết lại thành một problem statement đạt chuẩn (có dữ liệu giả định hợp lý, không nêu nguyên nhân và giải pháp).
Bài 2 — Viết Goal Statement. Từ problem statement bạn vừa sửa, viết một goal statement theo nguyên tắc SMART, đầy đủ chỉ số – mức hiện tại – mức mục tiêu – thời hạn.
Bài 3 — Operational Definition. Chọn một chỉ số trong công việc thực tế của bạn (ví dụ "đơn hàng xử lý đúng hạn", "cuộc gọi giải quyết thành công"). Viết operational definition chi tiết đến mức hai đồng nghiệp đo độc lập sẽ ra cùng kết quả. Liệt kê ít nhất ba điểm dễ gây hiểu nhầm mà bạn đã làm rõ.
Bài 4 — Phân loại dữ liệu. Với 5 chỉ số sau, hãy phân loại là dữ liệu rời rạc hay liên tục: (a) số khiếu nại/ngày, (b) thời gian giao hàng, (c) đạt/không đạt kiểm định, (d) chi phí mỗi đơn, (e) số lỗi trên một sản phẩm. Giải thích vì sao việc phân loại này quan trọng cho bước phân tích sau.
Tóm tắt
Phase Define trả lời câu hỏi "Ta giải bài toán gì và tại sao?" — với sản phẩm cốt lõi là Project Charter gồm Problem Statement (dựa trên dữ liệu, không gài giải pháp), Goal Statement (SMART), Business Case và Scope rõ ràng. Phase Measure trả lời "Hiện trạng tệ đến đâu và ta đo nó thế nào cho đáng tin?" — qua Operational Definition, Data Collection Plan, MSA (kiểm tra độ tin cậy của hệ thống đo), và thiết lập Baseline làm điểm so sánh.
Ba thông điệp cần khắc cốt ghi tâm: (1) Một vấn đề được định nghĩa rõ ràng đã là một nửa lời giải — đừng gài sẵn nguyên nhân hay giải pháp vào problem statement. (2) Mục tiêu phải đo được, nếu không bạn chưa hiểu vấn đề đủ sâu. (3) Dữ liệu sai còn nguy hiểm hơn không có dữ liệu — luôn kiểm tra hệ thống đo trước khi tin vào con số. Làm tốt Define và Measure, bạn đã đặt nền móng vững chắc cho toàn bộ phần Analyze, Improve và Control phía sau.