Làm thế nào để phân tích quy trình công việc khi chưa có kinh nghiệm thực tế?

[baonguyen]

Đây là nỗi lo khá phổ biến của sinh viên và intern khi bắt đầu học Solution Builder:

“Em chưa từng làm ở doanh nghiệp, chưa biết phòng thu mua, nhân sự hay vận hành làm gì. Vậy em lấy quy trình nào để phân tích?”

Bạn chưa cần hiểu toàn bộ cách một doanh nghiệp vận hành.

Hãy bắt đầu bằng những việc mình đã trực tiếp trải qua ở trường học, UBND phường, bệnh viện, ngân hàng, cửa hàng hoặc câu lạc bộ sinh viên.

Xin giấy xác nhận sinh viên, đăng ký môn học, mượn sách thư viện hay đăng ký tạm trú đều là những quy trình thật. Mỗi quy trình đều có người gửi yêu cầu, thông tin đầu vào, người xử lý, điểm cần ra quyết định và kết quả cuối cùng.

Ví dụ: Quy trình xin giấy xác nhận sinh viên

Giả sử bạn cần giấy xác nhận sinh viên để làm hồ sơ thực tập.

Đừng vội vẽ flowchart. Trước tiên, hãy quan sát tình huống qua các câu hỏi sau.

1. Ai đang cần điều gì?

Người bắt đầu quy trình là sinh viên.

Nhu cầu cụ thể là nhận được giấy xác nhận sinh viên trước thời hạn nộp hồ sơ thực tập.

Hai thông tin cần xác định ngay:

• Ai là người đưa ra yêu cầu?

• Họ muốn nhận được kết quả gì?

Nếu chưa trả lời rõ hai câu này, bạn rất dễ sa vào việc mô tả các bước xử lý nhưng quên mất mục tiêu ban đầu của quy trình.

Trong ví dụ này:

• Người yêu cầu: Sinh viên

• Mục tiêu: Nhận giấy xác nhận hợp lệ để hoàn thiện hồ sơ thực tập

2. Người yêu cầu phải cung cấp thông tin gì?

Một yêu cầu thường cần dữ liệu để người tiếp nhận có thể xử lý.

Với giấy xác nhận sinh viên, thông tin có thể gồm:

• Họ và tên

• Mã số sinh viên

• Lớp hoặc khoa

• Loại giấy cần cấp

• Mục đích sử dụng

• Số lượng bản

• Ngôn ngữ của giấy xác nhận

• Thời hạn cần nhận

• Địa chỉ email hoặc cách nhận kết quả

Đây là đầu vào của quy trình.

Khi quan sát đầu vào, hãy hỏi thêm:

• Thông tin nào bắt buộc?

• Thông tin nào có thể lấy sẵn từ hệ thống?

• Thông tin nào sinh viên thường điền sai?

• Có giấy tờ nào cần đính kèm không?

• Nếu thiếu dữ liệu thì ai liên hệ lại?

Ví dụ, trường đã có họ tên, mã sinh viên và khoa trong hệ thống. Nếu biểu mẫu vẫn yêu cầu sinh viên nhập lại toàn bộ, quy trình có thể phát sinh dữ liệu sai và khiến cán bộ phải kiểm tra thêm.

Đây chính là một điểm mà người học Solution Builder nên chú ý.

3. Ai tiếp nhận và xử lý?

Sau khi sinh viên gửi yêu cầu, hồ sơ có thể được chuyển đến Phòng Công tác sinh viên hoặc bộ phận một cửa.

Người tiếp nhận sẽ kiểm tra:

• Sinh viên có đang theo học không?

• Thông tin trên đơn có trùng với dữ liệu nhà trường không?

• Loại giấy được chọn có phù hợp với mục đích sử dụng không?

• Hồ sơ có đầy đủ không?

• Yêu cầu có cần chuyển cho người khác xác nhận không?

Khi phân tích một quy trình, đừng ghi chung chung là “nhà trường xử lý”.

Hãy cố gắng xác định rõ vai trò:

• Ai tiếp nhận yêu cầu?

• Ai kiểm tra dữ liệu?

• Ai có quyền xác nhận?

• Ai ký hoặc phát hành kết quả?

• Ai hỗ trợ khi có vấn đề?

Một phòng ban có thể tham gia nhiều bước, nhưng mỗi bước vẫn cần một người hoặc một vai trò chịu trách nhiệm.

4. Quyết định xuất hiện ở đâu?

Quy trình thường có những điểm mà người xử lý hoặc hệ thống phải đưa ra lựa chọn.

Trong ví dụ này, một số quyết định có thể là:

• Hồ sơ đã đầy đủ chưa?

• Thông tin có chính xác không?

• Sinh viên có đủ điều kiện được cấp giấy không?

• Yêu cầu có cần bổ sung tài liệu không?

• Kết quả có thể phát hành ngay hay cần người có thẩm quyền ký?

Mỗi quyết định sẽ dẫn quy trình sang một hướng khác.

Nếu hồ sơ hợp lệ, yêu cầu được tiếp tục xử lý.

Nếu thiếu thông tin, hồ sơ được trả lại cho sinh viên bổ sung.

Nếu yêu cầu không hợp lệ, sinh viên cần nhận được lý do cụ thể.

Đây là phần quan trọng khi bạn chuyển một công việc đang làm bằng lời nói hoặc tin nhắn thành workflow rõ ràng.

5. Kết quả cuối cùng là gì?

Một quy trình cần có điểm kết thúc có thể nhận biết được.

Với quy trình xin giấy xác nhận sinh viên, kết quả có thể là:

• Giấy xác nhận bản cứng

• File điện tử có chữ ký

• Thông báo yêu cầu bổ sung hồ sơ

• Thông báo từ chối kèm lý do

Kết quả cần được bàn giao cho đúng người và qua một kênh rõ ràng, chẳng hạn nhận trực tiếp, gửi qua email hoặc tải xuống từ cổng sinh viên.

Bạn có thể hỏi:

• Ai nhận kết quả?

• Nhận bằng cách nào?

• Làm sao biết yêu cầu đã hoàn tất?

• Có lưu lại lịch sử xử lý không?

• Nếu thông tin trên giấy bị sai thì yêu cầu chỉnh sửa thế nào?

6. Điều gì xảy ra khi quy trình không chạy đúng?

Quy trình thực tế hiếm khi chỉ có một đường đi thẳng từ lúc gửi yêu cầu đến lúc nhận kết quả.

Hãy thử đặt thêm các tình huống:

• Sinh viên nhập sai mã số

• Chọn nhầm loại giấy

• Thiếu tài liệu đính kèm

• Người xử lý đang nghỉ phép

• Yêu cầu nằm quá lâu mà chưa được tiếp nhận

• Giấy đã phát hành nhưng có thông tin sai

• Sinh viên cần kết quả gấp hơn thời gian xử lý thông thường

Những trường hợp này giúp bạn nhìn ra phần còn thiếu trong quy trình.

Ví dụ, nếu người phụ trách nghỉ phép và không ai thấy yêu cầu mới, vấn đề nằm ở cách phân công. Nếu sinh viên không biết hồ sơ đang ở đâu, quy trình đang thiếu khả năng theo dõi trạng thái. Nếu cán bộ phải hỏi lại cùng một thông tin nhiều lần, biểu mẫu đầu vào có thể chưa được thiết kế tốt.

Từ tình huống trên, có thể phác thảo quy trình như sau

1. Sinh viên chọn loại giấy cần cấp.

2. Sinh viên điền thông tin và gửi yêu cầu.

3. Bộ phận tiếp nhận kiểm tra hồ sơ.

4. Nếu thiếu thông tin, yêu cầu được trả lại để bổ sung.

5. Nếu hồ sơ hợp lệ, yêu cầu được chuyển đến người có thẩm quyền xác nhận.

6. Giấy xác nhận được phát hành.

7. Sinh viên nhận kết quả và quy trình kết thúc.

Khi đã có các bước cơ bản, bạn mới bắt đầu vẽ flowchart hoặc nghĩ đến cách số hóa.

Cách tự luyện với một quy trình bất kỳ

Hãy chọn một việc bạn từng làm:

• Đăng ký môn học

• Xin nghỉ học

• Mượn sách thư viện

• Đăng ký tạm trú tại phường

• Đặt lịch khám bệnh

• Đổi hoặc trả một món hàng

• Đăng ký tham gia câu lạc bộ

• Gửi đề nghị thanh toán chi phí cho một hoạt động sinh viên

Sau đó trả lời theo mẫu:

Bối cảnh

Việc này xảy ra ở đâu và nhằm giải quyết nhu cầu gì?

Người tham gia

Ai gửi yêu cầu, ai tiếp nhận, ai kiểm tra và ai quyết định?

Đầu vào

Người gửi phải cung cấp những thông tin hoặc giấy tờ nào?

Các bước xử lý

Yêu cầu đi qua những bước nào từ lúc bắt đầu đến lúc kết thúc?

Điểm quyết định

Ở bước nào yêu cầu có thể được duyệt, từ chối hoặc trả lại?

Đầu ra

Kết quả cuối cùng là gì và được bàn giao cho ai?

Trường hợp phát sinh

Điều gì xảy ra nếu thiếu thông tin, quá hạn hoặc người phụ trách vắng mặt?

Điểm cần cải thiện

Bước nào đang mất thời gian, dễ sai hoặc khiến người tham gia phải hỏi lại?

Chưa biết quy trình có đúng thực tế hay không thì làm sao?

Bạn có thể kiểm tra bằng ba cách:

• Tự thực hiện quy trình và ghi lại từng bước

• Hỏi một người đã từng làm công việc đó

• Tìm biểu mẫu, hướng dẫn hoặc quy định đang được sử dụng

• Đưa quy trình cho một người bạn và hỏi họ những câu hỏi cần thiết

Mục tiêu ban đầu chưa cần là vẽ ra một quy trình hoàn hảo. Hãy luyện cách quan sát, đặt câu hỏi và nhận ra những thông tin còn thiếu.

Đó cũng là tư duy quan trọng của một Solution Builder: hiểu công việc đang diễn ra thế nào trước khi thiết kế giải pháp cho nó.