Tháng Một 18

Nghiên cứu điển hình: Cải thiện quy trình đặt hàng

OPERATIONS SIX SIGMA

0  comments

mở toTrung tâm dịch vụ chia sẻ tài khoản phải trả (SSC) của một hệ thống chăm sóc sức khỏe lớn có trụ sở tại Ohio đã hoàn thành dự án báo cáo và nâng cao hoạt động Six Sigma. Nghiên cứu điển hình này đánh giá quá trình của dự án đã cố gắng thiết lập thời gian xử lý hóa đơn tiêu chuẩn và phát triển một hệ thống liên tục để giám sát mức độ đáp ứng các tiêu chuẩn đó.

Trong ba năm qua, UBCKNN xử lý trung bình 738.000 hóa đơn thanh toán mỗi năm. Phân khúc lớn nhất trong các hoạt động của nó là và tiếp tục là, hóa đơn dựa trên đơn đặt hàng (PO). Năm 2013, hóa đơn PO chiếm 56% tổng khối lượng xử lý cho UBCKNN.

Để giúp giải quyết khối lượng lớn hóa đơn PO đang được xử lý, SSC đã thiết lập hạn ngạch sản xuất hàng ngày. Việc phân bổ được xác định bằng cách lấy tổng số hóa đơn PO ước tính được xử lý trong một tháng nhất định chia cho số ngày làm việc trong tháng đó. Con số này sau đó được chia cho số lượng nhân viên được giao. Công thức được sử dụng để tính hạn ngạch là một phàn nàn thường xuyên của nhân viên SSC và nhân viên giám sát vì nó không thể nhận ra sự thay đổi trong thời gian xử lý khi có nhiều mục hàng trên một hóa đơn PO.

Mục tiêu dự án

Giữa những lời kêu gọi thay đổi, SSC đã bắt tay vào một dự án Six Sigma vào giữa năm 2013 bao gồm ba mục tiêu.

  1. Thiết lập phạm vi thời gian chuẩn để hoàn thành dựa trên tổng số mục hàng trên hóa đơn PO.
  2. Xác định thời gian xử lý cho một hóa đơn và liệu thời gian đó có thấp hơn, trong hoặc trên phạm vi thời gian tiêu chuẩn đã thiết lập hay không (cũng dựa trên số lượng mục hàng trên mỗi hóa đơn PO).
  3. Phát triển một báo cáo hoạt động toàn diện hiển thị thời gian xử lý của nhân viên được đo theo phạm vi thời gian tiêu chuẩn.

Đánh giá cơ sở dữ liệu

Trong những ngày kể từ khi dự án khởi động, chuyên viên phân tích hệ thống của UBCKNN đã đánh giá ứng dụng tài khoản phải trả được sử dụng với hóa đơn PO. Các phát hiện cho thấy thiết kế cơ sở dữ liệu của ứng dụng không thể phân tách các hóa đơn PO theo tổng số mục hàng hoặc để nắm bắt tổng thời gian xử lý của các nhân viên làm việc trên hóa đơn. Các cuộc thảo luận giữa nhóm dự án SSC và các nhà phát triển ứng dụng đã dẫn đến kết luận rằng giải pháp dài hạn tốt nhất là thực hiện sửa đổi cơ sở dữ liệu. Các nhà phát triển bên ngoài đã được ký hợp đồng và cơ sở dữ liệu đã được sửa đổi để lấy tất cả các dữ liệu cần thiết và làm cho nó dễ dàng truy cập.

Phân tích dữ liệu

Dữ liệu quý 4 năm 2013 được xuất từ ​​cơ sở dữ liệu sang Microsoft Excel bằng mã ngôn ngữ truy vấn có cấu trúc (SQL) được viết vào Microsoft Access. Dữ liệu đã xuất, được nhóm dự án gọi là dữ liệu thô, được trình bày trong ba cột. Các cột này chứa tên của nhân viên, tổng số mục hàng và tổng thời gian, tính bằng giây, cho mỗi hóa đơn PO được xử lý. Nhóm dự án đã sao chép nội dung của các cột vào Minitab để thực hiện phân tích dữ liệu. Mặc dù tự tin rằng dữ liệu thô của giao dịch sở hữu phân phối không chuẩn, nhóm dự án đã thực hiện một bản tóm tắt đồ họa về biến phản hồi, thời gian xử lý.

Hình 1: Tóm tắt thời gian xử lý, Q4 2013

Hình 1: Tóm tắt thời gian xử lý, Q4 2013

Thống kê Anderson-Darling, với p-giá trị thấp hơn mức ý nghĩa đã chọn là 0,05, xác nhận giả định rằng dữ liệu không tuân theo phân phối chuẩn. Điều này giúp nhóm dự án đánh giá các bài kiểm tra phi tham số khác nhau và xác định bài kiểm tra nào trong số các bài kiểm tra này là thích hợp nhất trong tương lai. Một yếu tố quan trọng trong quyết định này là sự khác biệt lớn trong thời gian xử lý. Bản tóm tắt đồ họa hiển thị phạm vi từ 3 giây đến 3,875 giây. Nhóm dự án cần một bài kiểm tra phi tham số có hiệu quả chống lại các ngoại lệ và lỗi trong dữ liệu. Sau khi xem xét kỹ lưỡng, quyết định sử dụng Bài kiểm tra Trung bình của Tâm trạng đã được đưa ra.

Với lựa chọn kiểm tra phi tham số hiện đang ở phía sau, nhóm dự án tập trung sự chú ý vào việc có được sự hiểu biết chính xác về ảnh hưởng của tổng số mục hàng đối với thời gian xử lý thực tế của hóa đơn PO. Một lần nữa sử dụng dữ liệu thô của quý 4 năm 2013, nhóm dự án đã thực hiện Kiểm tra Trung bình của Tâm trạng. Kết quả của cuộc kiểm tra cho thấy 33.567 hóa đơn PO bao gồm 77 nhóm hóa đơn riêng biệt có cùng số lượng mục hàng. Hơn nữa, nhóm dự án nhận thấy rằng 33,924, hay 98 phần trăm, hóa đơn PO bao gồm mười nhóm hóa đơn đầu tiên.

Hình 2: Số lượng mục hàng trên mỗi hóa đơn PO

Hình 2: Số lượng mục hàng trên mỗi hóa đơn PO

Do tỷ lệ hóa đơn trong mười nhóm hóa đơn đầu tiên cao, Ban lãnh đạo SSC quyết định rằng phạm vi thời gian tiêu chuẩn sẽ chỉ bao gồm mười nhóm đầu tiên đó. Tiếp theo, nhóm dự án cần một công cụ thống kê để giúp xác định phạm vi thời gian xử lý tiêu chuẩn cụ thể cho từng nhóm hóa đơn. Do khả năng cung cấp giới hạn trên và giới hạn dưới, khoảng tin cậy là công cụ được lựa chọn. Tuy nhiên, việc thu được khoảng tin cậy hữu ích trong các công cụ phi tham số có sẵn của Minitab đã đặt ra cho nhóm dự án một thách thức bổ sung. Mặc dù Kiểm tra trung bình của Mood tạo ra thông tin trung bình bắt buộc cho mỗi nhóm hóa đơn, khoảng tin cậy tương ứng không cung cấp phạm vi có thể sử dụng vì nó không bao gồm giới hạn dưới và giới hạn trên.

Hình 3: Thời gian xử lý tiêu chuẩn - 1

Hình 3: Thời gian xử lý tiêu chuẩn – 1

Giải pháp là macro bootstrap của Minitab. Macro tính toán khoảng tin cậy không tham số bằng cách sử dụng mã phương thức bootstrap, là một kỹ thuật thống kê được sử dụng để đưa ra một số loại suy luận thống kê và liên quan đến một quy trình tương đối đơn giản được lặp đi lặp lại nhiều lần đến mức kỹ thuật này phụ thuộc nhiều vào tính toán máy tính. Để áp dụng macro, nhóm dự án phải xác định dữ liệu đầu vào, số lần lặp được sử dụng để ước tính khoảng tin cậy và mức ý nghĩa. Với thời gian xử lý dữ liệu đầu vào, khối lượng lặp là 1.000 và mức ý nghĩa là 0,05, macro bootstrap đã được thực hiện trên nhóm hóa đơn đầu tiên – hóa đơn PO với một mục hàng.

Hình 4: Bootstrap Macro - 1

Hình 4: Bootstrap Macro – 1

Với 24.923 điểm dữ liệu, macro bootstrap không thể cung cấp bất kỳ sự phân tách nào giữa giới hạn trên và giới hạn dưới. Để giải quyết vấn đề này, nhóm dự án đã phải giảm khối lượng các điểm dữ liệu đang được tính toán. Điều này được thực hiện trong một quy trình gồm hai bước:

  1. Tính cỡ mẫu thích hợp. Số liệu điểm dữ liệu là 24,923, thay thế dưới dạng số dân số, được nhập vào một máy tính cỡ mẫu trực tuyến. Kết quả là cỡ mẫu là 378.
  2. Chọn ngẫu nhiên và tách riêng 378 lần xử lý của nhóm hóa đơn đầu tiên. Để đạt được chức năng này Bộ lấy mẫu ngẫu nhiên của Microsoft đã được sử dụng. Nhóm dự án sau đó đã sao chép 378 lần xử lý vào Minitab và thực hiện lại macro bootstrap.
Hình 5: Bootstrap Macro - 2

Hình 5: Bootstrap Macro – 2

Macro bootstrap đã được sử dụng trên chín nhóm hóa đơn còn lại. Để mở rộng thêm khoảng cách giới hạn trên và dưới cho các nhóm hóa đơn từ 2 đến 4, nhóm dự án lại sử dụng quy trình hai bước tương tự.

Hình 6: Thời gian xử lý tiêu chuẩn - 2

Hình 6: Thời gian xử lý tiêu chuẩn – 2

Khi kết thúc phân tích này, phạm vi thời gian xử lý tiêu chuẩn cho từng nhóm hóa đơn riêng biệt đã được tạo thành công. Điều này có nghĩa là nhóm dự án đã đạt được mục tiêu đầu tiên trong ba mục tiêu của dự án (thiết lập phạm vi thời gian chuẩn để hoàn thành dựa trên tổng số mục hàng của hóa đơn PO).

Hai mục tiêu còn lại – khả năng xác định thời gian xử lý đã trôi qua của một nhân viên và liệu thời gian đó có giảm xuống dưới, trong hoặc trên phạm vi thời gian tiêu chuẩn đã thiết lập và việc phát triển báo cáo hoạt động toàn diện – được xác định là phụ thuộc lẫn nhau. Kết luận này đã hướng dẫn nhóm dự án tìm kiếm sự hỗ trợ thêm từ nhà phân tích hệ thống.

Xây dựng báo cáo phân tích thời gian

Khi các cuộc thảo luận bắt đầu, nhóm dự án đặt ra các yêu cầu cho một báo cáo phân tích thời gian. Nội dung của báo cáo cần bao gồm phạm vi thời gian tiêu chuẩn theo nhóm hóa đơn, bao gồm số trung bình, tên của nhân viên, thời gian xử lý trung bình của từng nhân viên theo nhóm hóa đơn và bảng màu được áp dụng cho thời gian xử lý của nhân viên khi so sánh với thời gian chuẩn phạm vi. Ngoài ra, nhóm dự án muốn người dùng báo cáo có thể chỉ định phạm vi ngày và chạy báo cáo hoặc xuất dữ liệu thô sang Microsoft Excel. Các cuộc trò chuyện sau đó bao gồm tranh luận về nội dung, định dạng, mã hóa, điểm mạnh và điểm yếu của ứng dụng và ngày hoàn thành. Cuối cùng, các thỏa thuận đã đạt được và việc phát triển báo cáo bắt đầu.

Để đáp ứng nhu cầu của báo cáo phân tích thời gian, nhà phân tích hệ thống không chỉ xây dựng báo cáo mà còn cả một trang menu lệnh để phù hợp với chức năng. Việc xem xét mở rộng các mối quan hệ giữa các sản phẩm phân phối đã ảnh hưởng đến quyết định đầu tiên xây dựng trang menu lệnh. Sử dụng SQL và cơ bản trực quan cho các ứng dụng (VBA) mã hóa trong Microsoft Access và phần mềm máy chủ SQL, trang menu lệnh đã được xây dựng.

Hình 7: Trang menu lệnh

Hình 7: Trang menu lệnh

Để tạo báo cáo phân tích thời gian, nhà phân tích hệ thống đã sử dụng cùng một công cụ mã hóa và phần mềm được sử dụng để tạo trang menu lệnh. Tuy nhiên, do sự phức tạp của báo cáo, một mô-đun tùy chỉnh sử dụng mã VBA đã được phát triển và định dạng báo cáo có điều kiện được thiết lập. Cuối cùng, các liên kết giữa trang menu lệnh và báo cáo phân tích thời gian đã được tạo.

Với báo cáo phân tích thời gian đầy đủ chức năng, nhóm dự án đã chạy báo cáo để thu được các số liệu hiệu suất cơ bản quý 4 năm 2013.

Phi công

Hình 8: Các số liệu cơ bản

Hình 8: Các số liệu cơ bản

Nhóm dự án đã gặp gỡ các nhân viên của SSC để trình bày báo cáo và các con số cơ bản. Một thí điểm kéo dài 4 tuần đã kiểm tra lý thuyết nội bộ rằng những nhân viên có kết quả hoạt động được chia sẻ công khai và thường xuyên giữa các thành viên trong nhóm làm việc của họ (như một ứng dụng của văn phòng trực quan Lean) cố gắng nhiều hơn để đáp ứng hoặc vượt qua các tiêu chuẩn hoạt động hiện tại. Phản hồi từ nhân viên là có thể dự đoán được – những nhân viên đạt hoặc vượt tiêu chuẩn không quan tâm đến việc chia sẻ thông tin trong khi những người nhận thấy mình không đạt tiêu chuẩn không hoàn toàn nhiệt tình với ý tưởng. Điều cuối cùng đã bán khái niệm cho tất cả các cộng sự là hiệu suất của mọi người được chia sẻ. Ngoài ra, hiệu quả của nhân viên được cải thiện sẽ được phản ánh trong dữ liệu thô khi phạm vi thời gian xử lý tiêu chuẩn được tính toán lại. Điều này sau đó sẽ tạo ra một xu hướng giảm tích cực trong thời gian xử lý. Trong suốt thời gian thí điểm, một báo cáo phân tích thời gian được lập hàng tuần và gửi qua email.

Các kết quả

Mặc dù kết quả thí điểm cho thấy sự cải thiện có thể đo lường được trong năng suất, nhưng thí điểm tiết lộ rằng động lực của nhân viên không chỉ chịu trách nhiệm duy nhất về hiệu quả đạt được. Những nhân viên gặp khó khăn trong việc đáp ứng các khoảng thời gian xử lý tiêu chuẩn đã tìm kiếm và nhận được sự huấn luyện từ các nhân viên giám sát. Không thể xác định được mức độ ảnh hưởng của hướng dẫn bổ sung đến kết luận của phi công. Một phát hiện bất ngờ là các nhân viên thiếu kiến ​​thức về các nhiệm vụ cần thiết để xử lý chính xác hóa đơn PO. Dù vậy, cuộc thử nghiệm đã được nhóm dự án và ban quản lý chung coi là một thành công chung.

Sau khi thí điểm và các tiết lộ của nó, SSC đã tập hợp và tiến hành một loạt các buổi đào tạo lại nhân viên nhằm giải quyết cụ thể các khu vực có vấn đề. Các chính sách hoạt động đã được cập nhật để ngăn chặn khả năng thao túng thời gian xử lý. Phạm vi thời gian xử lý tiêu chuẩn mới, dựa trên dữ liệu thử nghiệm, đã được thiết lập. Nhân viên tiếp tục nhận được báo cáo phân tích thời gian hàng tuần và năng lực của họ để đáp ứng các yêu cầu xử lý hóa đơn PO được gắn với đánh giá hai năm một lần và hàng năm. Nhìn chung, UBCKNN đã vượt qua một cách sáng tạo mọi trở ngại gặp phải và dự định sẽ áp dụng tích cực phương pháp luận thành công này cho tất cả các dự án trong tương lai.

Nguồn: www.isixsigma.com

Rate this post

Chủ đề liên quan:

Hệ điều hành dành cho IoT tương lai

Hệ điều hành dành cho IoT tương lai

Trí tuệ nhân tạo AI

Trí tuệ nhân tạo AI

Tìm hiểu lịch sử hình thành và phát triển của API

Tìm hiểu lịch sử hình thành và phát triển của API
{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}
>