Process model là gì

byỞ Đâu •November 01, 2021

0

BUSINESS PROCESS MODEL

mango1911

4 năm trước

X

Bảo mật & Cookie

This site uses cookies. By continuing, you agree to their use. Learn more, including how to control cookies.

Đã hiểu!

Quảng cáo

YouTube Poster

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.

Business events :

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.

Phát triển một business process model (BPM)

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ụ :

Source : BUSINESS ANALYSIS [James Cadle, Debra Paul, Paul Turner]Ví dụ minh họa nghiệp vụ mượn item (sách, tạp chí,) gồm có 2 actor là người mượn và thủ thư. Bắt đầu nghiệp vụ người mượn sẽ yêu cầu mượn item sau đó yêu cầu theo mũi tên tới thủ thư và họ sẽ kiểm tra tình trạng item (còn hay hết). Tiếp theo thủ thư sẽ gửi item tới người mượn và người mượn nhận item và nghiệp vụ kết thúc. 710

Source : BUSINESS ANALYSIS [James Cadle, Debra Paul, Paul Turner]Ở ví dụ này ta có các đường thay thế (alternative paths) thể hiện trong các trường hợp thì tiến hành hành động này hoặc hành động thay thế. Khi khách hàng yêu cầu item, người thủ thư sẽ kiểm tra xem item có sẵn hay không, lúc này sẽ có 2 trường hợp, nếu item còn thì sẽ gửi cho người mượn như ví dụ trên còn nếu không thì thủ thư sẽ dự trữ item và kết thúc. 711

Source : BUSINESS ANALYSIS [James Cadle, Debra Paul, Paul Turner]Ở ví dụ này ta có tiến trình liên kế với một tiến trình khác. Như khi người thủ thư nhận các item được trả lại, họ có thể gửi item đó tiếp đến cho người mượn hiện tại.

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.

Analysing tasks :

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.

Hierarchy of process models :

Source : BUSINESS ANALYSIS [James Cadle, Debra Paul, Paul Turner]Phương pháp tiếp cận đa cấp sẽ đòi hỏi một tiếp cận lặp đi lặp lại trong việc phân tích. Các task ở level thấp hơn thể hiện nhiều chi tiết hơn, vì vậy mà các tiến trình cấp cao hơn cũn phải tiếp tục lặp lại việc update.

Beginning and ending the process :

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.

Source : BUSINESS ANALYSIS [James Cadle, Debra Paul, Paul Turner]Cách tiếp cận thứ 3 , lấy ví dụ initiator là khách hàng, tự thực hiện order của mình. Trong trường hợp này, task create order chỉ nằm trong swimlane của customer. Nếu khách hàng sử dụng website của công ty để order, chất lượng website sẽ ảnh hưởng tới nhận thức của khách hàng về tiến trình. Vì vậy, task này cần xem xét như 1 phần không thể thiếu của tiến trình.

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