Trong phương thức sản xuất hàng loạt, nhà sản xuất dựa trên khảo sát thị trường rồi dự đoán sản lượng rồi tiến hành sản xuất, rồi đẩy ra thị trường tiêu thụ.
Trước khi lượng hàng này tiêu thụ hết, chúng nằm ở chỗ nào đấy, thường là trên đường đi hoặc trong kho lưu trữ. Vì thế tồn kho lớn.
Trong kinh doanh, tồn kho là nỗi kinh hãi của nhà sản xuất khi thị trường đi xuống hoặc biến động. Nếu như khách không mua nữa, toàn bộ hàng hóa thành ra “của nợ”. Tồn kho khi đó là dấu hiệu rõ ràng của lỗ to, và thậm chí .. phá sản.
Thế thì làm sao để tránh tồn kho lớn? Có ít nhất hai cách:
1. Làm tốt khâu dự báo, để có số lượng sản xuất khớp với lượng tiêu thụ. Đồng thời phải có hệ thống tiêu thụ tốt để làm ra hao biêu tiêu thụ hết bấy nhiêu.
2. Đừng sản xuất hàng loạt nữa, để giảm thiểu tồn kho ngay từ đầu
Cách thứ nhất thì đòi hỏi phải có hệ thống dự báo tốt (dữ liệu, chuyên gia). Nhưng điều này thường là bất khả khi hệ thống (thị trường) phức tạp (complex). Khi đó, mọi dự đoán dài hạn thường trật lất. Đặc biệt trong hoàn cảnh thị trường luôn biến động (như thời kì chúng ta đang sống đây chẳng hạn).
Cách thứ hai loại bỏ tư duy hướng-nhà-sản-xuất (manufacture-centric) để cho khách hàng quyết định lượng hàng cần sản xuất (customer-centric). Có bao nhiêu đơn đợt đặt hàng thì sản xuất bấy nhiêu, sẽ không tồn kho.
Vận hành theo kiểu thứ nhất, ta có một hệ thống đẩy (Push System); theo kiểu thứ hai, ta có một hệ thống kéo (Pull system).
***
Thử xem một ví dụ về hệ thống kéo trong một nhóm phát triển phần mềm sử dụng Scrum và một bảng công việc kiểu Kanban.
Như bạn đã biết, các yêu cầu phần mềm được đặt trong một danh sách ưu tiên: Product Backlog, người được ưu tiên là Product Owner, tức là người thuộc “phe khách hàng”
Scrum Framework, ảnh: Bas Vodde et al.
Nhóm Scrum sẽ căn cứ năng lực hiện tại của mình (capacity) để lựa chọn số lượng yêu cầu cho phù hợp để đưa vào sản xuất trong một Sprint để có chức năng chạy tốt ở cuối Sprint đó. Tại thời điểm Sơ kết Sprint (Sprint Review), chức năng đó có thể dùng ngay được (potentially shippable increment). Vậy là không hề có chức năng nào là “tồn kho”. Khách hàng (PO) trực tiếp đặt hàng, với số lượng vừa phải để nhóm Scrum sản xuất.
Trong cách làm truyền thống, toàn bộ các yêu cầu sẽ được “giao” cho nhóm sản xuất, làm xong tất cả các chức năng rồi mới đóng gói lại (trong toàn bộ thời gian phát triển của dự án), tức là khách hàng (thực ra là cấp quản lí) ĐẨY yêu cầu cho đội sản xuất, còn ở đây, đội sản xuất KÉO các “đơn đặt hàng” từ khách hàng.
Việc KÉO cũng được áp dụng trong công việc nội bộ của đội sản xuất (Development Team). Sau buổi Họp kế hoạch Sprint, các công việc được đặt trong Sprint Backlog. Căn cứ vào yêu cầu công việc và năng lực cá nhân, các developer (có thể có chuyên môn khác nhau: coder, designer, tester …) sẽ KÉO công việc từ SprintBacklog để hoàn thành nhiệm vụ chứ không đợi cấp quản lý ĐẨY việc cho mình. Nói thêm, vì yêu cầu công việc, các nhân sẽ phải thực hiện việc kéo rất thông mình trong tinh thần cộng tác. Ví dụ như, cả nhóm sẽ phải tạo ra LUỒNG MỘT SẢN PHẨM để cùng nhau kéo các công việc sao cho giải quyết dứt điểm từng yêu cầu (tức là đánh dấu DONE cho nó) trước khi kéo các công việc khác để làm.
Thực tế đã cho thấy, một hệ thống kéo - một trong những kĩ thuật chủ chốt trong sự thành công của các phương pháp tinh gọn và Agile (như Lean Software Development, Lean Manufacturing, Kanban, Scrum, v.v.), giúp cho các nhóm làm việc đạt hiệu quả cao hơn nhờ tinh giảm được lãng phí, giới hạn luồng công việc (WIP) để đạt được chất lượng cao hơn cho sản phẩm, thích ứng tốt hơn với sự biến động khó lường của môi trường.
Tìm hiểu thêm: 14 nguyên lý tinh gọn