Trên trang này
Đồng bộ đề xuất có hai mươi ô. Ô bảy chép trạng thái sang bảng tính. Ô tám định dạng lại bảng cho nền tảng email. Ô chín gửi email nhờ quản lý duyệt nhập dữ liệu. Kế hoạch hỏi tác nhân nào nên làm ô bảy đến chín.
Câu hỏi đầu là vì sao các ô ấy tồn tại. Đây là ví dụ minh họa, không phải kiểm toán một nhóm thật.
Cuộc thảo luận thiết kế quy trình đề xuất bốn nhóm công việc: bỏ bước, dùng mã thường, dùng tác nhân hoặc để con người quyết. Bước hữu ích nằm trước chọn mô hình. Bỏ một bước có thể loại cả bộ máy quanh nó.
Bắt đầu từ kết quả khách hàng thấy được
Nêu kết quả quy trình phải tạo. Với kết nối cửa hàng tới email, có thể là “khách đã mua không còn nhận nhắc giỏ hàng”. Kết quả ấy cần trạng thái, thời điểm và quy tắc chặn. Nó không mặc định cần bảng tính, xuất toàn bộ mỗi đêm hay hộp thư quản lý.
Hình Tajo dưới đây tập trung phần xem lại vào ánh xạ đề xuất và ranh giới trước khi kích hoạt. Nó không triển khai việc chặn nhắc giỏ hàng. Để đạt kết quả đó, người vận hành cần xác định tín hiệu mua hàng và quy tắc chặn trước. Thêm một trường ánh xạ không thay thế được hai quyết định ấy.
Xem lại lượt đồng bộ trước khi chạy
Đồng bộ thông tin khách hàng mới lên nền tảng email của tôi.
Đồng bộ khách hàng
| Trường nguồn | Trường đích | Quy tắc |
|---|---|---|
email | EMAIL | Trực tiếp |
first_name | FIRSTNAME | Trực tiếp |
last_name | LASTNAME | Trực tiếp |
Xem trước bằng dữ liệu mô phỏng đạt
Đã ánh xạ 3 trường · Không ghi vào đích
Bố cục minh họa dựa trên công cụ ánh xạ của Tajo. Xem trước mô phỏng và bản nháp đã lưu không kích hoạt lượt đồng bộ.
Đi ngược đường hiện tại từ kết quả. Với từng bước, hỏi điều gì hỏng nếu nó biến mất. Kiểm soát thật có đáp án: mất trạng thái đồng ý, bỏ qua tranh chấp thanh toán hoặc gửi trái quyền. Bàn giao theo thói quen có thể chỉ có đáp án lịch sử: hệ thống cũ cần tệp.
Nhóm “bỏ” không cho phép xóa biện pháp bảo vệ. Xem mục đích mỗi bước trước khi xếp loại.
- Kết quả cần cókết quả cho kháchđi ngược
- Xem từng bướcmục đích và kiểm soátbỏ bước thừa
- Việc được giữcó chủ và thử được
Lượt rà xác định sản phẩm cần giao và phụ thuộc thật sự bảo vệ nó. Nếu bảng tính mang phán đoán nghiệp vụ không có ở đâu khác, phải giữ phán đoán ấy dù tệp biến mất.
| Loại bước | Câu hỏi | Ví dụ trong luồng giỏ hàng minh họa |
|---|---|---|
| Bỏ | Nó bảo vệ hoặc tạo kết quả cần có không? | Tệp xuất trùng không ai đọc |
| Mã thường | Quy tắc có chính xác và ổn định không? | Chặn nhắc khi có lần mua đã xác minh |
| Phán đoán mô hình | Bước cần diễn giải có giới hạn không? | Phân yêu cầu tự do tới đúng nhóm |
| Người hoặc chính sách đã duyệt | Lựa chọn có cấp quyền hay hậu quả đáng kể không? | Duyệt truy cập dữ liệu khách hàng |
Bảng là công cụ thiết kế. Nó không báo các bước thực của công ty nào đã được xếp thế nào.
Đặt quy tắc chính xác trong mã
Lệnh gọi API, kiểm trường, so thời gian hay kiểm quyền không tốt hơn vì mô hình ứng biến. Mã có thể diễn đạt bất biến, chạy giống nhau hai lần và tạo lỗi kiểm được. Hãy dùng nó nơi nêu được quy tắc.
Trong ví dụ giỏ hàng, sự kiện mua có thể đến muộn hoặc hai lần. Chương trình nên định danh đơn, so trạng thái hiện tại và từ chối nhắc khi đã biết có mua. Nếu không xác định được có mua hay chưa, hệ thống cần trạng thái bất định. Mô hình không thể tự cấp phép đoán khách chưa mua.
Một số việc không hợp quy tắc chính xác. Yêu cầu hỗ trợ có thể nói “Tôi mua hôm qua nhưng biên nhận hiện địa chỉ cũ.” Chuyển thông điệp ấy có thể dùng phán đoán ngữ nghĩa có giới hạn. Đầu ra nên là nhóm đã biết hoặc “chưa chắc”, không phải chỉ dẫn tự do để đổi đơn. Giữ quyết định mô hình tách khỏi mã thực thi quyền và ghi trạng thái.
Vì sao một tác nhân có thể che các bước
“Một tác nhân có thể đọc quy trình và làm hết.” Demo có thể làm nó trông đơn giản. Sản xuất vẫn cần ai đó giải thích vì sao tác nhân được xem bản ghi, được làm gì và đảo ngược hành động sai ra sao. Tác nhân quá rộng thường giấu cùng những bước vào prompt và bỏ nhãn vốn giúp kiểm toán.
Phản biện thứ hai là rà bốn nhóm cũng tốn thời gian. Đúng. Hãy làm ngắn. Chọn một kết quả khách hàng, liệt kê bước cần giao nó và hỏi mỗi bước đóng góp gì. Bài tập chỉ đáng khi nó thu gọn việc hoặc làm rõ sở hữu. Rà cầu kỳ mọi hệ thống kề bên lại thành một ô nữa.
Thử phân loại với ca thường và ca lỗi. Nếu bước bị bỏ hóa ra là kiểm soát, phép thử phải lộ ra. Nếu phán đoán mô hình không đánh giá được trên ví dụ, thu hẹp hoặc trả quyết định cho người. Nếu mã phải đổi theo từng ngoại lệ khách hàng, tách cơ chế ổn định khỏi quy tắc nghiệp vụ địa phương.
Lượt rà còn cần điểm dừng. Nhóm có thể cứ phân rã tác vụ đến khi chi phí phân loại lớn hơn việc tiết kiệm. Dừng khi mỗi bước giữ lại có chủ, yếu tố kích hoạt và lý do tồn tại kiểm được. Ghi một bất định có thể đổi thiết kế rồi thử trong phần chạy thật nhỏ nhất. Với đồng bộ, đó có thể là sự kiện mua đến đủ sớm để chặn lời nhắc đã xếp hàng không. Hướng dẫn tích hợp cho chuỗi lập kế hoạch rộng; bốn nhóm giúp chuỗi đó không giữ bước thừa. Xem lại phân loại khi quy trình hoặc quyền đổi.
Bước rẻ nhất là bước kết quả chưa bao giờ cần.
Câu hỏi Thường gặp
Nên bỏ gì trước khi tự động hóa?
Bước chỉ để bù cho bàn giao có thể bỏ, bản ghi trùng hoặc báo cáo không ai dùng là ứng viên. Kiểm người dùng đầu ra và kiểm soát phía sau trước khi xóa.
Khi nào bước cần mô hình?
Dùng mô hình cho phán đoán ngữ nghĩa hẹp không biểu đạt được bằng quy tắc chính xác ổn định, với đầu vào quan sát được, đầu ra có kiểu và đường xử lý bất định.
Quyết định nào nên để người?
Giữ lựa chọn đòi đồng ý, cấp quyền hoặc có hậu quả vượt phạm vi hệ thống được phép ở người chịu trách nhiệm hoặc chính sách rõ đã duyệt.