Khi nào nên sử dụng công cụ xử lý công việc?

Tôi đã từng làm việc trong một số công cụ xử lý công việc với tư cách là lập trình viên nhưng chưa bao giờ hiểu rõ lý do tại sao chúng tôi chọn công cụ quy trình công việc ở vị trí đầu tiên. Và là một lập trình viên, tôi biết rằng có ít nhất 100 cách để làm bất cứ điều gì khi bạn viết mã nhưng chỉ có một vài cách là tốt nhất!

Tôi vẫn không hiểu trường hợp sử dụng nào được giải quyết tốt nhất bằng các công cụ xử lý công việc (hay đúng hơn là khái niệm của chúng) hơn là thiết kế một ứng dụng hỗ trợ DI tốt. Tôi đang tìm kiếm bất kỳ đặc điểm chung nào của các trường hợp sử dụng trung lập miền, trong đó công cụ dòng công việc là một trong những lựa chọn tốt nhất.

Vì vậy, câu hỏi của tôi là: các đặc điểm chung của một yêu cầu có thể được coi là một tín hiệu để lựa chọn một công cụ dòng công việc tốt và mã hóa xung quanh nó là gì?

Một công cụ dòng công việc là hữu ích khi bạn cần đi từ đầu đến cuối nhưng có nhiều đường dẫn / logic / quy tắc khác nhau để đạt được điều đó.

Ví dụ: giả sử tôi viết chương trình xuất bản nội dung. Vì vậy, trong trường hợp của tôi, việc xuất bản trải qua quá trình xem xét, hợp pháp và sau đó là phê duyệt cuối cùng. Tôi viết chương trình thực hiện logic và các bước của tôi. Bây giờ công việc này tuyệt vời cho tôi và công ty của tôi. Vì vậy, tôi quyết định những người khác nên sử dụng chương trình của tôi.

Thật không may, không phải ai cũng xuất bản nội dung bằng cùng một quy trình, vì vậy thay vì viết các quy trình riêng cho từng trường hợp khác nhau, chúng tôi sẽ thực hiện quy trình xử lý công việc để chương trình linh hoạt để chứa tất cả mọi người. Bất kể có bao nhiêu bước hoặc quy tắc hoặc logic giữa hai điểm đó, kết quả là như nhau.

Vì vậy, nếu bạn có các quy trình có thể thay đổi từ đầu đến cuối, hãy sử dụng quy trình làm việc. Nếu mọi người có thể sử dụng cùng một quy trình, thì bạn không cần một quy trình làm việc.

Tôi biết bạn đã yêu cầu các trường hợp sử dụng, nhưng việc liệt kê các ưu điểm dễ dàng hơn là tưởng tượng tất cả các trường hợp sử dụng có thể. Những lợi thế của khóa học phụ thuộc vào công cụ và ngôn ngữ bạn đang so sánh, nhưng nói chung:

1. Giữ quy tắc dưới dạng dữ liệu thay vì mã có nghĩa là bạn không phải biên dịch lại, do đó, bạn có thể kiểm tra các thay đổi nhanh chóng, thay đổi trong thời gian chạy, v.v. Tuy nhiên, không có nhiều lợi thế nếu bạn không phải biên dịch lại ở vị trí đầu tiên.

2. Người dùng hợp lý hơn có thể được dự kiến ​​sẽ chỉnh sửa các quy tắc. Họ có khả năng tinker với họ một cách tương tác theo những cách không khả thi khi có một lập trình viên viết mã cho họ.

3. Giữ quy tắc dưới dạng dữ liệu cho phép các công cụ được viết để trực quan hóa và thay đổi dữ liệu.

4. Giữ quy tắc dưới dạng dữ liệu cho phép lập trình meta dễ dàng hơn - bạn có thể viết mã để phân tích dữ liệu và chèn thêm theo một cách phức tạp, điều này sẽ rất khó đối với mã.

Tất cả những điều này có thể thực hiện trực tiếp với mã (ví dụ: viết trình phân tích cú pháp C # để tìm tất cả các quy tắc của một loại nhất định và tạo mã cho nhiều quy tắc hơn, chèn nó một cách linh hoạt vào một tổ hợp theo cách cho phép dỡ bỏ lắp ráp, viết các công cụ cho người dùng có thể thực hiện điều này cũng sử dụng visualizer và biên tập viên của bạn) nhưng có thể nhiều hơn khó khăn tùy thuộc vào ngôn ngữ của bạn (lập trình viên sử dụng một Lisp có thể tham khảo mục 1-4 như "lập trình").

IMHO trường hợp DUY NHẤT mà bạn nên sử dụng loại điều này là khi nó có thể được cấu hình bởi người dùng ít giá trị hơn. Nếu bạn có thể giải quyết vấn đề của mình bằng cách cung cấp cho họ một công cụ thì hãy quay lại làm việc với một thứ khác quan trọng hơn, sau đó sử dụng một công cụ.

Nếu bạn vẫn cần thiết lập nó cho họ thì tôi sẽ tưởng tượng bạn có thể nghĩ ra 10 cách khác nhau để có được kết quả tương tự với một công cụ mà bạn quen thuộc và việc hỗ trợ và tùy chỉnh sẽ dễ dàng hơn rất nhiều.

Điều này trông giống như một câu hỏi cũ, nhưng bề mặt nhiều lần trong tự nhiên. Tôi đồng ý với câu trả lời của Jon . Tôi đã tìm thấy các công cụ dòng công việc có năng suất cao trong các tình huống sau:

1. Có một quy trình kinh doanh cơ bản mà bạn đang cố gắng thể hiện / thực hiện thông qua phần mềm của mình.
2. Có một thực thể kinh doanh (có thể là tổng hợp) được thực hiện trong tất cả hoặc một số giai đoạn trong quy trình. Trong ví dụ Jon đưa ra, thực thể hoặc Mục luồng công việc này sẽ là nội dung hoặc một bài viết. Xem xét theo dõi lỗi như một ví dụ khác về quy trình làm việc, chuyển đổi lỗi giữa các trạng thái khác nhau, dựa trên hành động mà người dùng thực hiện.
3. Sử dụng quy trình công việc để mô hình hóa các quy trình của bạn, chỉ khi bạn mong muốn quy trình kinh doanh thay đổi, bằng cách thay đổi, tôi có nghĩa là chuỗi hoặc hành động được thực hiện do kết quả của hành động hoặc chuyển đổi của người dùng.

Hãy rất cẩn thận và quan trọng để xem liệu miền / vấn đề yêu cầu của bạn có quy trình kinh doanh hay không, đừng cố gắng "khớp" nó vào quy trình công việc.

Tôi có một vài hướng dẫn tôi sử dụng để đề xuất các công cụ xử lý công việc.

1) Khi các nhà phân tích kinh doanh không có nền tảng mã hóa nhưng có thể vẽ sơ đồ.

Các công cụ dòng công việc hiện đại sử dụng ký hiệu mô hình hóa quy trình nghiệp vụ hoặc các phiên bản ít khả năng hơn có sẵn trong SharePoint và các hệ thống tương tự. Điều này cho phép các thành viên có khả năng về kỹ thuật nhưng chưa được mã hóa trong nhóm thiết kế và phát triển nhiều luồng công việc.

2) Khi bạn cần theo dõi tiến độ công việc, hãy thực hiện các bước leo thang, lật qua lại giữa các quy trình do máy tính điều khiển và các quy trình do con người kiểm soát.

Giám sát và tự tham khảo là đặc điểm nổi bật của động cơ dòng công việc hiện đại.

Từ góc độ kinh doanh nhân sự, động cơ dòng công việc là rất quan trọng.

1. Họ cung cấp một quy trình có cấu trúc, ngay cả khi nó giống nhau mọi lúc.

2. Họ cung cấp sự minh bạch

   • Ai yêu cầu thay đổi,
   • Khi được yêu cầu,
   • Ai phê duyệt v.v.

   Sự minh bạch này giúp thúc đẩy quá trình và thúc đẩy quyền sở hữu.

Giả sử các hình thức được tích hợp và thông minh, hỗ trợ logic kinh doanh, nó cũng có tác động lớn đến dòng thời gian, hiệu quả xử lý và chất lượng dữ liệu. Bảo mật cũng là một sự cân nhắc và chứa thông tin nhạy cảm trong một hệ thống bảo mật sẽ tốt hơn nhiều so với việc có các biểu mẫu giấy nằm chờ đợi để được ký kết. Nó cũng di động hơn nhiều. Sau khi thực hiện gần đây, một người quản lý nói với tôi rằng nó đã giúp anh ấy tiết kiệm rất nhiều rắc rối khi gửi những thứ cho anh ấy để ký khi anh ấy đi du lịch rất nhiều.

Thay mặt nhân sự: Quy trình làm việc lâu dài !!!