Xây dựng quy trình yêu cầu dịch vụ

Xác định nhân viên cần nhận được gì, rồi lập kế hoạch thông tin, phê duyệt, tác vụ thực hiện và xác nhận tiếp nhận để đạt kết quả đó.

Khám phá với dữ liệu mẫu. Điều chỉnh trường dữ liệu, chế độ xem và quy trình cho đội ngũ.

Viết rõ dịch vụ bạn định cung cấp

Ví dụ: thiết lập máy tính xách tay và bàn làm việc cho nhân viên
Quyết địnhChính sách mẫuSai lầm thường gặp cần tránh
Kết quảMáy tính xách tay và bàn làm việc đã sẵn sàng cho nhân viênKhông coi yêu cầu đã hoàn tất khi mới chỉ duyệt đơn mua hàng.
Thông tin cần thiếtNhu cầu công việc, địa điểm, ngày và yêu cầu thiết bịThu thập dữ kiện ảnh hưởng đến quyết định bàn giao, không hỏi mọi trường tài sản có thể có.
Phê duyệtNgười xét duyệt thiết bị được chỉ địnhQuyết định xét duyệt cho phép thực hiện cam kết; không chứng minh đã bàn giao thực tế.
Tác vụ thực hiệnChuẩn bị máy tính xách tay; giao đế kết nốiMỗi tác vụ cần người phụ trách và thông tin hoàn thành.
Xác nhận tiếp nhậnNhân viên xác nhận cả hai hạng mục bàn giaoTác vụ chưa hoàn thành hoặc bị vướng mắc sẽ chặn xác nhận tiếp nhận cuối cùng.

Xây dựng quy trình xoay quanh các quyết định

  1. Tách yêu cầu dịch vụ khỏi vấn đề ngoài dự kiến

    “Cấp máy tính xách tay khi đổi vị trí công việc” là dịch vụ đã xác định. “Máy tính xách tay hiện tại của tôi không sạc được” là vấn đề hỗ trợ. Người tham gia có thể giống nhau, nhưng thông tin đầu vào, quyết định và điều kiện kết thúc khác nhau.

  2. Chỉ định người chịu trách nhiệm về kết quả

    Giao một người phụ trách dịch vụ có thể làm rõ vướng mắc giữa các nhóm. Người phụ trách tác vụ làm phần việc của mình; người phụ trách dịch vụ chịu trách nhiệm toàn bộ yêu cầu và kết quả đã cam kết.

  3. Chỉ yêu cầu phê duyệt khi thực sự cần quyết định

    Chi tiêu, quyền truy cập hoặc ngoại lệ có thể cần người xét duyệt. Dịch vụ thông thường ít rủi ro có thể không cần. Tránh phê duyệt hình thức làm chậm công việc mà không tăng khả năng kiểm soát.

  4. Cho phép bổ sung thông tin thiếu

    Người xét duyệt cần cách trả lại bản gửi, giải thích thông tin thiếu và nhận bản đã sửa. Không xóa quyết định gốc hoặc biến việc từ chối thành chỉnh sửa trường âm thầm.

  5. Xác định thế nào là đã bàn giao

    Liệt kê tác vụ bắt buộc và minh chứng mỗi người phụ trách cần ghi. Nhân viên phải biết mình đang xác nhận nhận những gì. Một hạng mục đã xong không được che khuất phần việc phụ thuộc còn dở.

Yêu cầu khác nhau cần cách xử lý khác nhau

Quyền truy cập hệ thống nghiệp vụ

Thu thập hệ thống, vai trò đề nghị cấp, lý do công việc và ngày hết hạn nếu cần. Người xét duyệt phê duyệt quyền truy cập; quản trị viên có thẩm quyền cấp quyền trong hệ thống thực tế; kết quả được ghi cho người yêu cầu. Đổi trạng thái trong ứng dụng yêu cầu không phải cấp tài khoản.

Màn hình phòng họp bị hỏng

Đây là vấn đề ngoài dự kiến, không phải yêu cầu mua dịch vụ trong danh mục. Ghi phòng và mức ảnh hưởng, phân công người xử lý, ghi chẩn đoán cùng thời gian chờ và xác nhận màn hình hoạt động lại. Dùng ví dụ hỗ trợ nội bộ cho vòng đời này.

Triển khai hoàn chỉnh một dịch vụ trước

  1. Bắt đầu với một dịch vụ và vài trường hợp thực tế

    Thử yêu cầu thông thường, yêu cầu cần phê duyệt, bàn giao một phần, bản gửi bị trả lại và bàn giao đầy đủ. Hỏi người thực sự phụ trách dịch vụ xem mỗi trường hợp có dẫn đến hành động tiếp theo đúng hay không.

  2. Rà soát công việc đình trệ trước khi thêm bảng tổng quan

    Xem thông tin thiếu, tác vụ chưa có người phụ trách, vướng mắc và xác nhận tiếp nhận chậm. Tạo chế độ xem giúp người dùng giải quyết những tình trạng đó; một con số đếm không tự cho biết cần làm gì.

  3. Mở rộng với phạm vi rõ ràng

    Thêm dịch vụ khi mô tả được thông tin đầu vào và cách thực hiện. Giữ yêu cầu bảo mật, cấp phát kỹ thuật và ứng phó sự cố chuyên biệt trong các hệ thống có phân quyền được thiết kế cho chúng.

Hỏi đáp về thiết kế quy trình yêu cầu dịch vụ

Ai nên phụ trách quản lý yêu cầu dịch vụ?

Chỉ định người phụ trách dịch vụ hiểu kết quả đã cam kết và có thể giải quyết bàn giao liên nhóm. Mỗi tác vụ thực hiện vẫn cần người chịu trách nhiệm riêng; phụ trách bảng tổng quan không đồng nghĩa với phụ trách dịch vụ.

Có nên thiết kế chính sách trước khi chọn phần mềm không?

Trước hết, xác định tối thiểu kết quả dịch vụ, thông tin bắt buộc, người phê duyệt nếu cần, người phụ trách tác vụ và điều kiện xác nhận tiếp nhận. Sau đó kiểm tra ứng dụng có giúp thực hiện các quyết định và xử lý ngoại lệ đó thuận tiện hay không.

Nên xử lý yêu cầu thiếu thông tin ra sao?

Trả lại kèm câu hỏi cụ thể và giữ lịch sử. Nêu rõ ai phải sửa thông tin và khi nào yêu cầu có thể tiếp tục; không đánh dấu từ chối chỉ để đưa yêu cầu ra khỏi hàng đợi đang xử lý.

Nhóm nhỏ nên bắt đầu với chỉ số nào?

Bắt đầu từ quyết định cần đưa ra: yêu cầu nào chưa có người phụ trách, tác vụ nào bị vướng mắc, hay bàn giao nào đang chờ xác nhận? Chỉ thêm chỉ số thời gian thực hiện sau khi xác định mốc bắt đầu, kết thúc, lịch làm việc và chính sách chờ.

Ví dụ thực hiện dịch vụ và hỗ trợ có phải một ứng dụng đồng bộ không?

Không. Đây là các ví dụ riêng cho thực hiện dịch vụ đã xác định và xử lý vấn đề ngoài dự kiến của nhân viên. Nếu cần bàn giao giữa hai ứng dụng, hãy thiết kế liên kết và trách nhiệm thay vì mặc định chúng tự đồng bộ.

Biến một chính sách dịch vụ thành quy trình vận hành thực tế

Dùng yêu cầu và tác vụ thực hiện mẫu để thử các bước bàn giao của bạn trước khi mở rộng thêm dịch vụ.

Khám phá ứng dụng yêu cầu dịch vụ