Process model là gì

Một quy trình nghiệp vụ (business process) được bắt đầu bởi một business event và bao gồm 5 thành phần chính : các tasks làm nên tiến trình, process flow, điểm quyết định, actors thực hiện các tasks và outcome (kết quả) của tiến trình nghiệp vụ. Không may, không có một sự thống nhất nào về các thuật ngữ sử dụng trong business process cả. Nhưng ở đây chúng ta quy ước :

• Process : một tập hợp các hành động bắt đầu bằng các sự kiện khởi xướng và kết thúc với một số kết quả được chuyển giao.
• Task : Một hoạt động riêng lẻ trong toàn bộ process; thường được tiến hành bởi các actors trong cách thời điểm riêng.
• Step : các công việc tiến hành trong từng task.

3 loại :

• External : bên ngoài tổ chức.
• Internal : bên trong tổ chức.
• Time-based : diễn ra trong thời điểm nhất định.

Có nhiều tiêu chuẩn để mô hình hóa các tiến trình nghiệp vụ. Hai cái phổ biến nhất là ULM và BPMN. Business process models thường được gọi là các swimlane diagrams bởi các swimlanes cho thấy tất cả các task được làm bởi 1 actor. Ở đây chúng ta sử dụng các ký tự và cấu trúc theo kỹ thuật UML activity diagram để dựng swimlane diagrams.

Kỹ thuật bao gồm các yếu tố :

• Bố cục tổng thể (overall layout)
• Các ký tự (symbols)
• Sắp xếp các ký hiệu

Để xây dựng một BPM, trước tiên ta xác định ai tham gia vào tiến trình. Điều này giúp chúng ta xác định được các actor của nghiệp vụ. Actors có thể là cá nhân hoặc một nhóm người trong tổ chức hoặc là một hệ thống IT. Tasks được thực hiện bởi mỗi actor được thể hiện độc lập trong một swimlane và các mũi tên dùng để chỉ dòng chảy công việc giữa các swimlane với nhau. Các swimlane xuất hiện tuần tự theo sự tham gia của các actors vào tiến trình (có quy ước không chính thức cho rằng swimlane của customer sẽ ở đầu). Kết quả là các hành động của model tiến hành từ trái sang phải trong một layout theo chiều dọc, theo trục thời gian từ trên xuống khi các actor khác tham gia vào. Hướng từ trái sang phải, từ trên xuống dưới tương tự như cách đa số mọi người đọc văn bản và mang tính trực giác.

Ví dụ :

Nên dùng có giới hạn các symbols cho BPM. Điều này sẽ giúp đỡ phải giải thích nhiều thứ khi thảo luận với các stakeholders và tránh bị rối. Cần quan tâm tới việc đặt tên cho các tiến trình nghiệp vụ và tasks. Nên dùng theo cấu trúc động từ đi với danh từ (verb-noun) để ngắn gọn và mô tả được nhiệm vụ của tiến trình. Dùng các động từ đặc trưng, rõ ràng, tránh dùng các từ như manage hoặc handle do chúng quá chung chung, không rõ ràng. Find book là một ví dụ tốt, nó ngắn gọn, rõ ràng và mô tả được hoạt động nào diễn ra.

Nhà phân tích nghiệp vụ có thể rơi vào bẫy phổ biến khi mô hình hóa các tiến trình là thêm vào quá nhiều chi tiết quá nhanh. Actor thực hiện task thường muốn nói với người BA về công việc của họ trong lần đầu tiên. Mặc dù chi tiết này quan trọng, nên cố gắng ghi lại sớm phòng tránh các vấn đề về sau. Kết quả của process model có thể vượt kiểm soát và trở nên khó khăn cho bất cứ ai có thể hiểu được. Nên thể hiện một cấu trúc tổng thể của tiến trình trước và đem các mô tả chi tiết vào sau. Khi lần đầu trao đổi với actor, nhà phân tích quan tâm tới :

• Họ lấy thông tin đầu vào từ đâu ?
• Họ làm gì với các thông tin đó ?
• Nơi họ chuyển tiếp nó sau khi họ đã hoàn thành công việc của họ ?

Một khi chúng ta đã tài liệu hóa dòng chảy tổng quát của tiến trình, chúng ta có thể trở lại và điền các task chi tiết vào.

Lợi ích chính từ BPM là mỗi actor có thể dễ dàng thấy được sự đóng góp của họ vào tiến trình tổng quát. Nhà phân tích cố gắng đưa ra các tóm tắt về tiến trình nghiệp vụ trong giai đoạn phân tích này. Kết quả là, các task cho thấy ít chi tiết. Nguyên tắc chung là thể hiện task riêng biệt cho một công việc thực hiện bởi một actor tại một thời điểm nhất định. Mỗi task nên được thể hiện bởi một hành động đơn, nhận input từ actor trước và chuyển giao tới các actor sau; dòng chảy công việc từ một actor tới một actor khác gọi là hand-off.

Swimlane diagram cho thấy công việc được tiến hành trong quy trình nghiệp vụ bao gồm actors và dòng chảy công việc (flow of the work). Có thể xác định các vấn đề với as is process nhưng thường chúng ta cần đi sâu vào chi tiết hơn để thực sự hiểu tiến trình đang hoạt động ntn và vấn đề đang diễn ra. Cách tiếp cận chi tiết hơn là phân tích từng task (box) trong BPM. Chúng ta có thể xem xét những mặt sau của mỗi task :

• Trigger hoặc business event khởi đầu task.
• Inputs của task.
• Outputs của task.
• Chi phí liên quan.
• Tiêu chuẩn và đo lường.
• Breakdown chi tiết (chia nhỏ).
• Business rules cần tuân theo.

Tài liệu lại các mặt này sẽ giúp việc phân tích các task và xác định các vấn đề hoặc cơ hội cải thiện. Một mô tả bằng văn bản có thể đủ cho nhiều tasks nhưng khi các steps và business rules phức tạp hơn, một diagram ví dụ như flowchart hoặc ULM activity diagram (không có swimlanes) sẽ hữu ích hơn.

Cách đơn giản nhất thể hiện người khởi đầu tiến trình (initiator) như ví dụ mượn item đã minh họa ở ví dụ trên là nguwoif đi mượn (borrower), bắt đầu tiến trình bằng cách cung cấp một sự kiện mở đầu (event) hoặc trigger. Nghiệp vụ nhận và xử lý yêu cầu của borrower xem borrower là một external stakeholder. Nó không biết gì về việc borrower tạo ra yêu cầu khởi tạo như thế nào nhưng chỉ đơn giản phản ứng ngay khi nhận được đầu vào.

Trong trường hợp khác, nghiệp vụ có thể làm việc gần hơn với người khởi đầu (initiator) Ví dụ như một KH gọi tới trung tâm để đặt order. KH và nhân viên sales của tổng đài làm việc với nhau để ghi nhận chi tiết order. Điều này có thể được thể hiện dưới dạng một nhiệm vụ duy nhất liên quan đến cả hai bên và do đó thể hiện trên ranh giới giữa khách hàng và nhân viên bán hàng. Ví dụ minh họa dưới đây.

Kết thúc tiến trình được thể hiện bởi biểu tượng .