Chúng ta đã hiểu rằng giá, giao hàng là những hấp dẫn ban đầu với khách hàng, nhưng để giữ được khách hàng lâu bền thì chất lượng mới là vấn đề đáng bàn. Bài này nói về mối liên hệ giữa “Chất lượng và giá” (Quality and Price), và “Chất lượng và chi phí” (Quality and Cost):
1. Mối liên hệ giữa “Chất lượng và giá” (Quality and Price): Hầu hết mọi người vấn đề quan tâm đầu tiên về một sản phẩm/dịch vụ là giá, rồi mới đến chất lượng. Nếu giá quá cao so với khả năng chi trả, chúng ta thậm chí sẽ chẳng quan tâm đến sản phẩm/dịch vụ đó dù chất lượng của nó tốt thế nào đi nữa. Chúng ta cũng dựa vào giá để so sánh các sản phẩm/dịch vụ với nhau với hy vọng là chúng ta có thể mua được những thứ cùng tính chất (hoặc chất lượng tương đương) với giá rẻ hơn. Khi một mặt hàng/dịch vụ nào đó trở nên khan hiếm, thì giá của nó cũng có xu hướng bị đẩy lên cao, trong khi nếu quá nhiều, giá sẽ thấp hơn bất kể chất lượng của chúng thế nào. Cùng là một mặt hàng, bán ở những cửa hàng khác nhau thì giá bán cũng có thể khác nhau – giảm 50% ở chỗ này, tăng hơn 10% ở chỗ khác. Mua sỉ thì bạn có thể nhận được discount, do vậy bạn hãy trở thành khách buôn chứ đừng thành khách mua lẻ. Nếu bạn là du khách, bạn sẽ dễ dàng nhận thấy mua một món quà lưu niệm tại sân bay sẽ đắt hơn nhiều là ở một cửa hàng tại điểm du lịch, tuy nhiên, bạn cũng sẽ chấp nhận một thực tế là món quà mua được ở cửa hàng có thể là một món đồ bị lỗi hoặc là đồ second hand, còn khi mua ở sân bay, chúng là những mẫu tốt nhất. Có một thực tế là thường là giá cả tăng thì sẽ bao hàm dịch vụ tốt hơn, ví dụ các dịch vụ đi kèm khi một sản phẩm tăng giá là bảo hành tại chỗ, giao hàng miễn phí... Tất cả những điều trên cho thấy mối liên hệ giữa chất lượng và giá còn phụ thuộc vào rất nhiều yếu tố bên ngoài như địa điểm, thời gian, nhu cầu, và giá có thể thương lượng được… nhưng bỏ qua yếu tố thị trường thì giá sẽ tỉ lệ thuận với chất lượng, do vậy, để Fsoft tăng giá thì chúng ta hãy tăng chất lượng? Hoặc chúng ta chấp nhận chất lượng vẫn thế, muốn tăng giá chúng ta sẽ cần thêm các yếu tố thương lượng?
Giá niêm yết trên một sản phẩm / dịch vụ sẽ là cho sản phẩm / dịch vụ đó không có lỗi. Nếu có lỗi nào đó, trên niêm yết cần nói càng chi tiết càng tốt, nếu không thì nhà cung cấp có thể đang vi phạm luật pháp hoặc đạo luật quốc gia. Nếu nhìn theo khía cạnh này, giá của Fsoft có thực sự là đang cho sản phẩm / dịch vụ của chúng ta là không có lỗi, hoặc là vì dịch vụ của chúng ta vẫn đang deliver cho khách hàng các package có lỗi, nên họ thực sự không có ý muốn tăng giá mua với Fsoft?
Sẽ có người tranh luận rằng mua hàng chất lượng thì sẽ đắt, nhưng trên thực tế, việc tiết kiệm được một số tiền bằng cách mua hàng giá thấp là việc bạn bị che mắt với các dịch vụ kém hoặc sự chênh lệch về chi phí duy trì của người sở hữu. Tựa như việc bạn mua hàng giảm giá thì thường sẽ đi kèm điều kiện “mua rồi miễn đổi trả” dù có đúng là hàng lỗi hay không, hoặc mua một xe ô tô kém chất lượng về thì chi phí sửa chữa, bảo dưỡng, tỷ lệ hỏng vặt cũng sẽ khiến khoản tiền bạn tiết kiệm trước đó trở thành vô nghĩa. “Tiền nào của nấy” là tâm lý nên có của người tiêu dùng thông thái. J
2. Mối liên hệ giữa “Chất lượng và chi phí” (Quality and Cost): Đa số các nhà quản trị tin rằng, việc tìm và xử lý lỗi (removal of defects) là chi phí của việc tạo ra các sản phẩm/ dịch vụ, để đạt được chất lượng mong muốn, công ty phải trả cho những người tìm và xử lý lỗi. Vì thế, nếu chúng ta xử lý được hết lỗi (free of defects/ zero defects) thì chúng ta có thể không giảm được chi phí, nhưng chúng ta có cơ hội tăng được sự hài lòng khách hàng và somehow chúng ta sẽ được đền đáp bằng các đơn hàng lớn hơn. Thông thường, phương châm chất lượng của các nhà sản xuất sẽ là:
- Doing the right thing: Làm đúng những gì mà khách hàng yêu cầu, mong muốn -> Fsoft Leakage
- Doing it the right way: Làm đúng cách, theo thứ tự, không cắt xén, bỏ bớt các bước thực hiện -> Fsoft PCV rate
- Doing it the right at the first time: Làm đúng ngay từ đầu, hạn chế rework, sửa lỗi phát sinh -> Fsoft Correction cost
- Doing it ontime without exceeding cost: Làm đúng hạn mà không phát sinh chi phí vượt định mức (budget) -> Fsoft EE, Timeliness
Hiển nhiên, Fsoft cũng đang thực hiện theo phương châm này bằng các công thức QCDP của công ty mà mình đã nêu ở trên. Tất cả những điều trên đều nằm trong chi phí sản xuất của công ty. Tuy nhiên, mình nghĩ rằng có ít người để ý đến chi phí phải bỏ ra khi không làm các điều trên, đó là chi phí phát sinh mà chúng ta phải gánh chịu bởi vì các sai hỏng có thể phát sinh sau đó. Tại thời điểm chúng ta làm dự án, chúng ta không thể biết trước chi phí sau này sẽ là bao nhiêu, chúng ta chỉ có thể biết và dự đoán rủi ro thông qua các bài học vấp ngã trong quá khứ, và tận tâm bỏ công sức để thực hiện đúng phương châm của công ty mà thôi. Mình biết đã có trường hợp dự án stop giữa chừng và khách hàng không trả cho mình một đồng nào mà nguyên nhân là mình đã không “Doing the right thing” (hoặc không hiểu làm thế nào cho đúng), hoặc trường hợp thường thấy bị phạt hợp đồng vì không “Doing it ontime”,… cái mà các PM cần biết là chi phí phát sinh chúng ta phải bỏ ra là như thế nào nếu không đạt chất lượng cam kết để chuẩn bị sẵn hết các trường hợp rủi ro, kể cả việc tính chi phí phát sinh sẽ thế nào và công ty sẵn sàng chấp nhận chi phí đó để keep cam kết chất lượng?
Đối với chi phí trong dự án, chúng ta có thể phân thành chi phí phải chi (unavoidable cost) và chi phí có thể phát sinh (avoidable cost), giống như công ty có chi phí cố định và chi phí dự phòng. Chi phí phải chi bao gồm lương member dự án, các loại tài nguyên, công cụ, máy móc, vận chuyển,... những thứ mà bắt buộc phải chi để vận hành dự án, cái này PM có thể estimate trước, hoặc có khung để chuẩn bị trước. Bên cạnh đó, chúng ta cũng phải bỏ thêm các chi phí để ngăn ngừa (prevention), phát hiện (detection) và xử lý lỗi (removal) – gọi chung là quality cost. Vậy Quality cost là chi phí phải chi hay chi phí phát sinh? Mình muốn đưa ra một số dự toán để chúng ta consider:
- Dự toán 1: Giả sử chi phí phải chi để vận hành dự án được dự toán là 100 đồng, trong đó chi phí ngăn ngừa lỗi là 8 đồng, chi phí phát hiện lỗi là 15 đồng, chi phí xử lý lỗi là 8 đồng, dự toán phát sinh là 10 đồng ngoài chi phí vận hành. -> tổng chi phí dự án có thể phải chi là 110 đồng.
- Dự toán 2: Giả sử chi phí vận hành dự án dự toán là 92 đồng không có dự toán chi phí ngăn ngừa, trong đó chỉ có chi phí phát hiện lỗi là 15 đồng, chi phí xử lý lỗi là 8 đồng, dự toán phát sinh 0 đồng (do PM suy nghĩ là mình sẽ làm tốt nên ko có phát sinh chi phí).
Giả sử bạn là BUL và review và approve 2 bản dự toán trên, bạn sẽ phê duyệt bản nào? Nếu bạn là PM lâu năm, chắc chắn bạn sẽ nghĩ kiểu gì cũng phải phát sinh chi phí sau khi bàn giao sản phẩm cho khách hàng, nên bản dự toán 2 là không thể phê duyệt. Với bản dự toán 1, bạn cũng sẽ có băn khoăn là liệu thực sự mình có cần bỏ ra 8 đồng để ngăn ngừa lỗi hay không, rồi chi phí phát sinh 10 đồng có quá nhiều không khi mà OB chỉ cho mình 110 đồng bmm trong khi EE thì cấp trên giao cho mình là 95%, tức là mình chỉ dc quyền chi tiêu 104 đồng? Chúng ta luôn bị giằng xé giữa việc chịu bỏ ra chi phí chất lượng hay là không, và lập luận để bảo vệ với cấp trên là gì để được phê duyệt? Hãy lập luận với supervisor của chúng ta: Chấp nhận bỏ ra quality cost để làm đúng ngay lần đầu tiên mà chúng ta có thể plan, monitor và adjust chi phí đó, hay bỏ ra chi phí phát hiện và sửa lỗi (bản chất vẫn là quality cost) phát sinh mà chúng ta không lường hết được sau khi đã giao hàng? Ở đây chỉ có một notes nho nhỏ: Vấn đề là chúng ta đang ở level: Không biết sai ở đâu để thay đổi, hay là biết sai nhưng không biết thay đổi thế nào? Câu trả lời cho 2 câu hỏi khác nhau chắc chắn sẽ khác nhau.
Thêm một điều nữa về quality cost mà mình muốn sharing là: Nếu bạn thiết lập cơ chế ngăn ngừa lỗi, bạn sẽ tốn ít chi phí để phát hiện và sửa lỗi. Minh họa của mình là coding convention. Bản chất hoạt động thiết lập, đào tạo, thực hiện và kiểm soát coding convention là một cơ chế để ngăn ngừa lỗi phát sinh trong tương lai cho hoạt động code hiện tại của dự án. Thử tưởng tượng 10 người cùng code 1 hệ thống, tùy tiện mỗi người một phong cách, tự define, tự tạo cơ chế kiểm soát memory riêng, không có cách define biến global, biến private thì mạnh ông nào ông ấy define,… thì chắc các bạn biết hệ thống nó sẽ thế nào rồi nhỉ? Vậy tại sao chúng ta không ngăn ngừa các chi phí phát sinh khi phải đi fix sai hỏng của hệ thống đó ít nhất thông qua coding convention? Thêm nữa, chắc bạn nào học Testing foundation, chắc nhớ đến biểu đồ chi phí phát sinh để sửa lỗi sẽ tăng dần theo từng công đoạn phát triển và phát hiện lỗi, nếu lỗi được tìm thấy ở requirement analysis chúng ta mất 200$ để sửa lỗi đó, thì nếu mãi đến khi vận hành để sửa lỗi thì lỗi đó đã lên đến 15k$, vậy tại sao chúng ta không bỏ các chi phí để ngăn ngừa lỗi ở các công đoạn đầu tiên của dự án?
Ở góc nhìn của kinh doanh, mình đề xuất Fsoft nên coi chi phí ngăn ngừa lỗi là chi phí đầu tư, vì nếu một khách hàng gắn bó với Fsoft lâu dài, bạn có thể thỏa mãn yêu cầu của khách hàng với chi phí thấp hơn (nhiều hoặc ít) so chi phí trước đó bạn đã bỏ ra ở các dự án trước đó, kể cả khách hàng có yêu cầu chúng ta giảm chi phí nội bộ để họ có thể mua hàng với giá thấp hơn, chúng ta vẫn có thể đáp ứng được yêu cầu đó mà vẫn có lãi.
Chất lượng chắc chắn là điều mà mỗi chúng ta đều hướng tới, nhưng làm nó như thế nào, chấp nhận bỏ chi phí thế nào thì chưa chắc mỗi chúng ta đều hiểu. Mình chỉ mong các PM khi thực hiện internal estimation hãy coi Quallity cost là một phần phải có để thực hiện estimating, và hãy estimate thêm các chi phí phát sinh nếu chúng ta không đạt vấn đề chất lượng, chi phí phát sinh đó có thể xảy ra trong quá trình dự án và/hoặc cuối dự án khi chúng ta giao hàng, nếu không được công nhận thì hãy đưa vào risk list để quản lý, sau này chẳng may có các dấu hiệu (trigger của risk) thì giải thích được tại sao chúng ta phải OT, phải thêm resouces, bị khách hàng complain và thậm chí bị stop dự án luôn.
No comments:
Post a Comment