Vì sao yêu cầu mua sắm trở thành điểm nghẽn
Trong một công ty sản xuất, hoạt động mua sắm hiếm khi bắt đầu từ một tài liệu được điền đầy đủ và chỉn chu. Nhu cầu có thể phát sinh từ quản đốc, kỹ thuật viên công nghệ, kỹ sư, bộ phận vận hành hoặc nhân viên lập kế hoạch. Người gửi email, người viết trong cuộc trò chuyện nội bộ, người lại trực tiếp truyền đạt thông tin cho cấp quản lý. Kết quả là cùng một nhiệm vụ có thể xuất hiện trên nhiều kênh, còn một số yêu cầu thậm chí không được ghi nhận.
Thoạt nhìn, vấn đề giống như một sự chậm trễ phê duyệt thông thường. Nhưng trên thực tế, nó ảnh hưởng đến toàn bộ chu kỳ cung ứng. Trong thời gian yêu cầu đang được kiểm tra, nhân viên mua sắm không thể yêu cầu báo giá một cách chính xác, nhà cung cấp chưa nhận được đơn hàng, kho không biết khi nào nguyên vật liệu sẽ đến, còn bộ phận sản xuất buộc phải điều chỉnh lại lịch trình. Vị trí càng quan trọng, cái giá của sự không rõ ràng càng cao.
Việc quản lý yêu cầu càng phức tạp khi công ty có nhiều cơ sở, bộ phận và cấp độ trách nhiệm. Với một danh mục, chỉ cần phê duyệt của cấp quản lý; với danh mục khác, cần kiểm tra ngân sách, kết luận kỹ thuật, xác nhận của bộ phận an ninh hoặc quyết định của nhiều người phê duyệt. Nếu các quy tắc không được quy định trong quy trình, mỗi người tham gia sẽ hành động theo logic riêng.
Những yếu tố thường làm chậm quá trình xử lý nhu cầu
- không có biểu mẫu thống nhất với các thông tin bắt buộc về mặt hàng, số lượng, thời hạn và mục đích sử dụng;
- không rõ ai chịu trách nhiệm cho bước tiếp theo và yêu cầu hiện đang ở đâu;
- người phê duyệt nhận thông báo qua nhiều kênh khác nhau và không thấy được ngữ cảnh;
- các thay đổi trong yêu cầu không đi kèm lịch sử rõ ràng;
- nhu cầu khẩn cấp bị trộn lẫn với nhu cầu theo kế hoạch;
- cấp quản lý chỉ biết về nguy cơ giao hàng không đúng hạn sau khi vấn đề đã xảy ra.
Trong môi trường như vậy, nhân viên thường bù đắp sự thiếu minh bạch bằng cách kiểm soát thủ công: gọi điện cho đồng nghiệp, chuyển tiếp email, lập bảng tính cục bộ và nhắc việc trong các cuộc trò chuyện. Điều này tạo cảm giác đang hoạt động tích cực nhưng không hình thành một quy trình có thể lặp lại. Khi nhân viên nghỉ việc, quản lý thay đổi hoặc khối lượng mua sắm tăng lên, hệ thống nhanh chóng mất đi tính ổn định.
Những hệ quả phát sinh đối với hoạt động sản xuất
Việc phê duyệt kéo dài không phải lúc nào cũng ngay lập tức dẫn đến dây chuyền dừng hoạt động. Thường thì trước tiên sẽ xuất hiện những dấu hiệu ít rõ ràng hơn: đơn hàng khẩn cấp thay cho đơn hàng theo kế hoạch, giao hàng từng phần, yêu cầu báo giá lặp lại với nhà cung cấp, mua hàng với điều kiện kém thuận lợi hơn, tồn đọng các yêu cầu chưa hoàn tất. Những tổn thất này có thể phân tán giữa nhiều bộ phận nên trong thời gian dài không có một chủ sở hữu duy nhất.
Lập kế hoạch sản xuất dựa trên khả năng cung ứng nguyên vật liệu, phụ tùng, công cụ và dịch vụ. Nếu thông tin về việc mua sắm không được cập nhật, nhân viên lập kế hoạch buộc phải dựa vào các giả định. Một số mặt hàng được đặt quá muộn, trong khi những mặt hàng khác lại được dự trữ quá mức. Trong cả hai trường hợp, công ty đều mất khả năng kiểm soát nguồn lực lưu động.
Hiệu ứng về mặt tổ chức cũng rất đáng kể. Người phê duyệt bắt đầu xem các yêu cầu như một loạt đề nghị phát sinh riêng lẻ, còn bộ phận mua sắm trở thành trung tâm điều phối phải thủ công tìm kiếm những thông tin còn thiếu. Trong khi đó, tranh luận xem ai làm chậm quy trình lại thay thế cho việc phân tích chính xác điểm nào trong quy trình đang được tổ chức chưa hiệu quả.
Quy trình thay đổi như thế nào trong OpenBox
Giải pháp «Quản lý yêu cầu» trong OpenBox giúp chuyển hành trình của nhu cầu mua sắm từ các kênh rời rạc vào một không gian làm việc thống nhất. Yêu cầu được tạo theo biểu mẫu rõ ràng, đi qua các giai đoạn đã định, được chuyển đến những nhân viên chịu trách nhiệm và lưu lại lịch sử thao tác. Điều quan trọng không chỉ là tự động hóa, mà còn là khả năng mô tả trước các quy tắc theo đó công ty muốn vận hành.
Thay vì đặt câu hỏi «email hiện đang ở chỗ ai?», người dùng có được thông tin cụ thể: ai tạo yêu cầu, yêu cầu thuộc bộ phận nào, cần gì, trong thời hạn nào, đã hoàn tất giai đoạn nào, ai phải thực hiện bước tiếp theo và những bình luận nào đã được để lại. Điều này làm giảm số lần phải уточ rõ thông tin và giúp nhanh chóng phân biệt các yêu cầu đầy đủ với những yêu cầu còn thiếu dữ liệu đầu vào.
Đăng ký nhu cầu thống nhất
Ở giai đoạn đầu tiên, công ty xác định danh sách trường thông tin. Thông thường, yêu cầu sẽ ghi nhận người đề xuất, bộ phận, khoản mục hoặc hướng chi phí, danh mục hàng hóa, số lượng, thời hạn mong muốn, địa điểm giao hàng, lý do và các tài liệu bổ sung. Bộ dữ liệu phụ thuộc vào đặc thù sản xuất: với một mặt hàng kỹ thuật, có thể cần thông số, bản vẽ hoặc yêu cầu về khả năng tương thích; với dịch vụ, có thể cần đề bài kỹ thuật và kết quả kỳ vọng.
Các trường bắt buộc không cho phép gửi một yêu cầu mà nhân viên mua sắm phải tiếp tục hỏi lại những thông tin cơ bản. Tuy nhiên, biểu mẫu cũng không nên quá tải. Nếu người dùng nhìn thấy hàng chục trường không liên quan đến nhiệm vụ của mình, họ sẽ bắt đầu tìm cách обход qua quy trình. Vì vậy, nên chia dữ liệu thành phần chung và phần có điều kiện: các trường bổ sung chỉ hiển thị với những danh mục hoặc loại mua sắm nhất định.
Định tuyến theo các quy tắc rõ ràng
Sau khi đăng ký, yêu cầu có thể được chuyển theo lộ trình dựa trên bộ phận, danh mục, giá trị, mức độ khẩn cấp hoặc khoản mục chi phí được chọn. Ví dụ, vật tư kỹ thuật sẽ được chuyên gia chuyên môn kiểm tra, còn yêu cầu có giới hạn tài chính sẽ cần phê duyệt ngân sách bổ sung. Với hoạt động mua sắm tiêu chuẩn, lộ trình có thể ngắn hơn; với nhu cầu không tiêu chuẩn, lộ trình có thể bao gồm bước thẩm định chuyên gia.
Lộ trình không nên được thiết lập một lần rồi bỏ mặc. Trong hoạt động sản xuất, cơ cấu bộ phận thay đổi, các danh mục mới xuất hiện và quyền hạn được phân bổ lại. Vì vậy, khi triển khai, điều quan trọng không chỉ là thống nhất trình tự các giai đoạn mà còn phải xác định chủ sở hữu quy trình, người chịu trách nhiệm duy trì tính актуальность của quy trình.
Kiểm soát thời hạn và trạng thái
Mỗi yêu cầu được gán một trạng thái dễ hiểu, chẳng hạn như «đã tạo», «đang kiểm tra», «đang phê duyệt», «đã chuyển sang bộ phận mua sắm», «chờ bổ sung thông tin», «đã thực hiện» hoặc «bị từ chối». Tên trạng thái cần phản ánh các hành động thực tế, thay vì những cách diễn đạt nội bộ chỉ một bộ phận hiểu được.
Nhân viên có thể xem giai đoạn hiện tại mà không cần gửi yêu cầu đến bộ phận mua sắm. Người chịu trách nhiệm nhận được thông báo về nhiệm vụ mới và các thay đổi. Quản lý có thể chú ý đến những yêu cầu nằm quá lâu ở một bước, còn nhân viên mua sắm có thể tập trung vào các yêu cầu đã sẵn sàng để xử lý tiếp. Cách tiếp cận này không loại bỏ nhu cầu ra quyết định, nhưng loại bỏ thời gian chờ đợi không cần thiết và việc tìm kiếm thủ công.
Kịch bản triển khai cho công ty sản xuất
Thực tế hơn là bắt đầu không phải bằng việc cố gắng tự động hóa mọi loại mua sắm cùng lúc, mà bằng một kịch bản có thể kiểm soát. Chẳng hạn, có thể chọn các yêu cầu mua nguyên vật liệu sản xuất, phụ tùng hoặc dịch vụ sửa chữa. Ở phạm vi này, việc xác định người tham gia, thu thập ví dụ thực tế và kiểm tra dữ liệu nào thực sự cần thiết cho việc ra quyết định sẽ dễ dàng hơn.
- Phân tích quy trình hiện tại. Nhóm ghi nhận cách nhu cầu phát sinh hiện nay, nơi nhu cầu được đăng ký, người kiểm tra dữ liệu, các bước phê duyệt bắt buộc và những giai đoạn thường phát sinh yêu cầu xử lý lại.
- Xác định vai trò. Xác định người đề xuất, trưởng bộ phận, chuyên gia kỹ thuật, người phê duyệt tài chính, chuyên viên mua sắm và những người tham gia khác. Với mỗi vai trò, cần mô tả không phải chức danh nói chung mà là hành động cụ thể trong yêu cầu.
- Thiết kế biểu mẫu. Các trường được nhóm theo ý nghĩa, bổ sung hướng dẫn và quy tắc bắt buộc. Đồng thời xác định riêng những tài liệu nào phải đính kèm ngay và tài liệu nào chỉ cần với một số loại nhu cầu nhất định.
- Thiết lập lộ trình. Xác định điều kiện chuyển giữa các giai đoạn, thứ tự phê duyệt, quy tắc trả lại để chỉnh sửa và hành động khi từ chối. Điều này giúp loại bỏ các bước phê duyệt «song song» không chính thức.
- Thí điểm trên một nhóm giới hạn. Quy trình mới được kiểm tra trên các yêu cầu thực tế của một bộ phận hoặc danh mục. Người dùng chỉ ra những trường khó hiểu, bước thừa và các tình huống chưa được dự tính trong sơ đồ ban đầu.
- Mở rộng và ban hành quy định. Sau khi điều chỉnh, kịch bản được triển khai cho các bộ phận khác. Quy định sẽ nêu rõ cách tạo yêu cầu, thời hạn phản hồi, cách xử lý yêu cầu khẩn cấp và trách nhiệm duy trì tính cập nhật của lộ trình.
Trình tự này giúp việc triển khai không biến thành một dự án CNTT trừu tượng. Trọng tâm vẫn là một nhiệm vụ cụ thể: làm cho hành trình của nhu cầu trở nên rõ ràng và có thể dự đoán đối với những người tham gia mua sắm hằng ngày.
Đánh giá kết quả mà không cần các báo cáo hình thức
Nên đánh giá hiệu quả tự động hóa dựa trên những dấu hiệu có thể quan sát được, không chỉ dựa vào số lượng yêu cầu được tạo. Trước khi triển khai, nên ghi nhận hiện trạng: đang sử dụng bao nhiêu kênh, những thông tin nào thường phải уточ lại, có bao nhiêu yêu cầu bị trả lại để bổ sung, ở đâu không có người chịu trách nhiệm và những nguyên nhân chậm trễ nào thường xuyên xuất hiện.
Sau khi chuyển sang quy trình thống nhất, có thể theo dõi các chỉ số sau:
- tỷ lệ yêu cầu được tạo theo biểu mẫu đã phê duyệt;
- thời gian lưu lại ở mỗi giai đoạn;
- số lần trả lại do dữ liệu chưa đầy đủ hoặc mâu thuẫn;
- số yêu cầu chưa được chỉ định người chịu trách nhiệm;
- tỷ lệ yêu cầu khẩn cấp và nguyên nhân phát sinh;
- số nhiệm vụ quá hạn theo từng bộ phận và vai trò;
- tần suất thay đổi lộ trình và các ngoại lệ lặp lại.
Các dữ liệu này không phải là mục tiêu tự thân. Chúng giúp hiểu vấn đề nằm ở biểu mẫu, quyền hạn hay việc lập kế hoạch nhu cầu. Ví dụ, số lần trả lại nhiều có thể không phản ánh sự thiếu chú ý của người đề xuất mà cho thấy yêu cầu mô tả mặt hàng được xây dựng quá chung chung. Còn các yêu cầu khẩn cấp xuất hiện thường xuyên có thể chỉ ra sự thiếu liên kết giữa kế hoạch sản xuất và lịch mua sắm.
Những điều cần lưu ý trước khi triển khai
Tự động hóa không thay thế các thỏa thuận giữa các bộ phận. Nếu công ty chưa xác định ai có quyền phê duyệt việc thay thế vật liệu, ai chịu trách nhiệm đưa ra kết luận kỹ thuật và thế nào được xem là mức độ khẩn cấp hợp lý, phần mềm chỉ chuyển sự không rõ ràng vào giao diện số. Vì vậy, nên bắt đầu cấu hình OpenBox từ các quy tắc làm việc, thay vì từ danh sách nút bấm.
Cũng cần thảo luận trước về các trường hợp ngoại lệ. Bộ phận sản xuất cần những kịch bản riêng cho sửa chữa khẩn cấp, dừng thiết bị, yêu cầu an toàn và các đơn hàng có thời hạn nghiêm ngặt. Tuy nhiên, «khẩn cấp» không nên trở thành cách né tránh phổ biến đối với lộ trình tiêu chuẩn. Tốt hơn là tạo một loại yêu cầu riêng, bắt buộc nêu lý do và tiến hành phân tích nguyên nhân sau đó.
Đối với người dùng, việc bắt đầu sử dụng đơn giản là yếu tố then chốt. Người đề xuất phải hiểu cần truy cập vào đâu, chọn biểu mẫu nào và điều gì sẽ xảy ra sau khi gửi. Người phê duyệt cần một hàng đợi nhiệm vụ có mức độ ưu tiên và đầy đủ ngữ cảnh. Nhân viên mua sắm cần các bộ lọc và khả năng nhanh chóng xem những yêu cầu đã sẵn sàng xử lý. Quản lý cần tổng quan về khối lượng công việc và các giai đoạn có vấn đề. Khi mỗi người chỉ nhận được thông tin liên quan, sự phản đối thay đổi sẽ giảm xuống.
Khi nào nên thảo luận về việc triển khai
Quyết định tự động hóa đặc biệt phù hợp nếu các yêu cầu thường xuyên phải tìm trong thư từ, quản lý không thể nhanh chóng nhận được danh sách cập nhật về những yêu cầu đang chờ, nhân viên mua sắm dành nhiều thời gian để bổ sung thông tin đầu vào, còn bộ phận sản xuất phát hiện nguy cơ chậm trễ quá muộn. Một dấu hiệu khác là quy trình phụ thuộc vào một điều phối viên duy nhất, người phải ghi nhớ thủ công cần nhắc ai và nhắc điều gì.
OpenBox có thể trở thành nền tảng cho quá trình chuyển đổi từng bước sang một quy trình có thể quản lý: trước tiên là đăng ký thống nhất, tiếp theo là lộ trình và kiểm soát thời hạn, sau đó là phân tích nguyên nhân sai lệch và phát triển các kịch bản. Cấu hình cụ thể phụ thuộc vào cơ cấu công ty, các danh mục mua sắm và những quy định phê duyệt hiện hành.
Nếu bạn muốn hiểu chính xác thời gian đang bị thất thoát ở đâu trong quy trình của mình, hãy bắt đầu bằng việc mô tả lộ trình hiện tại và một số yêu cầu thực tế. Trong buổi tư vấn về OpenBox, có thể phân tích các kịch bản này, xác định những vai trò bắt buộc và lựa chọn phạm vi hợp lý cho giai đoạn đầu tiên. Một đợt thí điểm được thực hiện thận trọng sẽ mang lại nhiều lợi ích hơn so với việc cố gắng ngay lập tức đưa tất cả ngoại lệ và thỏa thuận nội bộ vào hệ thống.