Giá trị của các công cụ quy trình công việc là gì? [đóng cửa]

Tôi chưa quen với việc phát triển quy trình làm việc và tôi không nghĩ mình thực sự có được "bức tranh lớn". Hoặc có lẽ để đặt nó khác đi, những công cụ này hiện không "nhấp" vào đầu tôi.

Vì vậy, có vẻ như các công ty muốn tạo ra các bản vẽ kinh doanh để mô tả các quy trình và đến một lúc nào đó, ai đó đã quyết định rằng họ có thể sử dụng một máy trạng thái như chương trình để thực sự kiểm soát các quy trình từ một dòng và hộp như sơ đồ. Mười năm sau, các công cụ này rất lớn, cực kỳ phức tạp (công ty của tôi hiện đang chơi xung quanh với WebSphere và tôi đã tham gia một số khóa đào tạo, một con quái vật, thậm chí còn được gọi là các phiên bản "tối giản" của các công cụ quy trình công việc như Activiti này to lớn và phức tạp mặc dù gần như không phức tạp như quái thú đó là WebSphere afaict).

Lợi ích lớn khi làm theo cách này là gì? Tôi có thể hiểu các sơ đồ đường và hộp đơn giản là hữu ích, nhưng những điều này, theo như tôi có thể nói, là ngôn ngữ lập trình trực quan tại thời điểm này, hoàn chỉnh với các điều kiện và vòng lặp. Các lập trình viên ở đây dường như đang thực hiện một khối lượng công việc đáng kể trong lớp đường và hộp, mà đối với tôi trông giống như một ngôn ngữ lập trình trực quan thực sự cơ bản, nhảm nhí.

Nếu bạn sẽ đi xa như vậy, tại sao không sử dụng một số loại ngôn ngữ kịch bản? Có người ném em bé ra ngoài với nước tắm này không? Có phải các dòng và hộp điều đã được đưa đến một mức độ vô lý, hoặc tôi chỉ không hiểu giá trị trong tất cả điều này?

Tôi thực sự muốn thấy những tranh luận để bảo vệ điều này bởi những người đã làm việc với công nghệ này và hiểu lý do tại sao nó hữu ích. Tôi không thấy giá trị của nó, nhưng tôi nhận ra rằng tôi cũng mới với điều này và có thể chưa hoàn toàn hiểu được nó.

Từ quan điểm của một nhà phát triển, bạn đã đúng khi nói rằng những môi trường "trực quan" này thực sự khó làm việc. SharePoint 2010 Workflows, mà tôi sử dụng, loại bỏ mọi thực tiễn tốt nhất xung quanh việc tạo phần mềm doanh nghiệp tốt - không kiểm tra tự động, không sử dụng lại mã, phần mềm không thể đọc được ... Bất kỳ điều gì phức tạp hơn một mẫu ngoài luồng đều có thể gây khó khăn để duy trì , như bạn đang trải nghiệm.

Nhưng theo quan điểm của doanh nghiệp, quy trình làm việc có lợi ích to lớn - ít nhất là về mặt lý thuyết. Để trích dẫn từ sách trắng này , Hiệu quả, Trách nhiệm, Kiểm soát và Dễ sử dụng quy trình làm việc tự động mang lại hiệu quả năng suất rất lớn. Hãy tưởng tượng một quá trình phê duyệt hoặc lên máy bay không hiệu quả sẽ như thế nào nếu không có sự tự động hóa này. Ngoài ra, chính hành động xác định quy trình công việc có giá trị đối với một tổ chức đang cố gắng kiểm soát các quy trình kinh doanh của họ.

Trạng thái hiện tại của phần mềm quy trình công việc không phải là lỗi của doanh nghiệp. Họ chỉ muốn làm cho cuộc sống của họ dễ dàng hơn, và quy trình làm việc là tuyệt vời cho điều đó. Tôi hầu hết sẽ đổ lỗi cho chúng tôi, bộ phận CNTT:

1. Không minh bạch hơn với doanh nghiệp về việc hệ thống thực sự phức tạp và dễ vỡ như thế nào. Chúng tôi che giấu tất cả sự phức tạp.
2. Để không thể "gãi ngứa" bằng các giải pháp công việc đơn giản, trực quan. Đây có lẽ là một cơn thịnh nộ chống lại các gói doanh nghiệp lớn như SharePoint và SAP, nhưng chúng tốt hơn các giải pháp tùy chỉnh ngoài kia

Chỉ có một lợi ích thực sự, nhưng nó rất lớn: Tách biệt mối quan tâm .

Vì vậy, thay vì logic xử lý phối hợp được nhúng trong hệ thống của chúng tôi, nó trở thành và cấu hình bên ngoài. Một bản đồ, về cơ bản. Bạn có thể thay đổi nó một cách độc lập (nhiều hơn nữa), bạn có thể có nhiều quy trình, nhiều phiên bản quy trình, nhiều phiên bản của nhiều quy trình đang chạy cùng một lúc và tất cả đều vượt trội trong bất kỳ giải pháp hợp lý nào.

Trong lịch sử, khái niệm về SoC đã chiến thắng nhiều lần - bắt đầu từ nguyên tắc Unix "làm một việc, nhưng làm tốt" và được áp dụng nhiều lần - như có các thành phần máy chủ chuyên dụng như ESB, các hệ thống bền bỉ khác nhau, bộ nhớ đệm, cân bằng tải , giám sát, như tách CSS khỏi HTML, v.v.

Quy trình kinh doanh của bạn và quy tắc luồng của nó thường trực giao với dữ liệu của bạn, "màn hình" UI hoặc "phân cấp" của người dùng. Vì vậy, nó có ý nghĩa hoàn hảo để phát triển và thay đổi nó tách biệt với các khía cạnh khác của hệ thống. Đó là tiền đề mà BPM đã xuất hiện vào đầu những năm 1990.

Kể từ đó, nhiều công cụ và ngôn ngữ đã được tạo ra để hỗ trợ khái niệm này, trong đó nổi tiếng nhất là BPMN - một ngôn ngữ đồ họa để tạo ra "sơ đồ" trực tiếp ánh xạ tới các quy trình. Trong khi mọi người phàn nàn rằng nó lớn và khó sử dụng (có hơn 100 ký hiệu trong từ vựng) và ủng hộ các phương pháp hiện đại như S-BPM (chỉ có 5 ký hiệu cơ bản), thì thực tế công nghiệp hiện nay là bám vào BPMN hoặc các dẫn xuất, tập con hoặc anh chị em của nó.

Bạn không hài lòng với BPMN:

Các lập trình viên ở đây dường như đang thực hiện một khối lượng công việc đáng kể trong lớp đường và hộp, mà đối với tôi trông giống như một ngôn ngữ lập trình trực quan thực sự cơ bản, nhảm nhí.

Nhưng nó không tệ) Có lý thuyết đằng sau nó. Và phiên bản 2.0 đã có một cái nhìn sâu sắc tốt từ những thiếu sót 1.0.

Nếu bạn sẽ đi xa như vậy, tại sao không sử dụng một số loại ngôn ngữ kịch bản?

Mô hình bắt buộc và ngôn ngữ kịch bản không phải lúc nào cũng là câu trả lời tốt nhất. Như bạn có thể thấy trong các ngôn ngữ khai báo (như HTML, CSS, SQL, Dropols hoặc nội bộ của Nginx, Graddle và Maven, Puppet, v.v.), mã kết quả có thể nhỏ hơn và gọn gàng hơn so với phiên bản được viết bằng " ngôn ngữ đàng hoàng " , như Java hoặc C ++ ".

Về điểm khác của bạn:

theo như tôi có thể nói, là các ngôn ngữ lập trình trực quan tại thời điểm này, hoàn chỉnh với các điều kiện và vòng lặp.

Bạn đã nhìn vào Sự kiện và Kích hoạt chưa? BPMN là một ngôn ngữ và bạn phải học nó trước khi sử dụng, hoặc ít nhất là làm quen với nó.

Trong phần mềm, BPMN là XML, do đó bạn có thể chỉnh sửa bằng tay hoặc tạo. Và bạn có thể kiểm soát phiên bản vì XML dựa trên văn bản. Tuy nhiên, chỉ cần có một XML có thể được dịch thành sơ đồ, nghe có vẻ không giúp ích gì cho bạn, và điều đó đúng - viết trình phân tích cú pháp hoặc trình soạn thảo của riêng bạn cho nó là một nhiệm vụ khó khăn và tốn kém với những lợi ích đáng ngờ.

May mắn thay, đã có các công cụ tại thị trường mà exaclty đó.

Activiti là miễn phí, và khá phổ biến đối với cả nhà phát triển và chủ sở hữu busines, vì giá ban đầu ( không ), tính sẵn có của thông tin và sự khiêm tốn. Điểm cuối cùng thực sự độc đáo, vì Activi chỉ tập trung vào việc quản lý các quy trình kinh doanh của bạn, mà không cố gắng ràng buộc bạn với các giải pháp trọn gói. Ngoài ra, nó mở - vì vậy bạn chỉ cần biết Java và REST để khởi động và chạy. Hạn chế là phía khách hàng, logic tích hợp và ứng dụng / doanh nghiệp và toàn bộ kiến ​​trúc được dành cho nhà phát triển, vì vậy nếu nhóm phát triển của bạn yếu - hãy chuẩn bị cho thất bại. Tổng chi phí sở hữu có thể cao đáng ngạc nhiên đối với một công cụ miễn phí ;)

Ở phía bên kia của quang phổ là Pega (Pega PRPC), vị vua trị vì của các hệ thống BPM (theo Gartner và Forester), có vẻ tốt đáng ngạc nhiên đối với tuổi của nó. Ứng dụng này có khả năng CRM, OCR và (nếu tôi không nhầm) khả năng nhận dạng giọng nói, phân tích dự đoán, quản lý quy tắc kinh doanh và trình soạn thảo UI WYSIWYG. Nó đi kèm với một thẻ giá nghiêm trọng, mặc dù. Không chỉ tốn kém, mà tất cả sự phát triển đang được thực hiện trong một ứng dụng web, điều đó có nghĩa là bạn phải sử dụng trình duyệt, đó là IE8 (cộng với một số plugin, cộng với các bản hack xấu xí, như sử dụng Excel để chỉnh sửa bảng dữ liệu). Ngoài ra, chỉnh sửa Java, Javascript hoặc HTML / CSS cũng đang được thực hiện với trình duyệt web - vì vậy hãy nói lời tạm biệt với các bài kiểm tra đơn vị, tô sáng mã IDE, tái cấu trúc và tất cả các đồ chơi lập trình của bạn mà bạn yêu thích.

Mặt tốt của nó? bạn có thể triển khai hệ thống phức tạp TRONG VÒNG TUẦN [ PDF , xem trang 22]. Và có, kết quả không được đảm bảo.

IBM gần đây (theo tốc độ thời gian của doanh nghiệp) đã mua lại Lombardi và hiện đang cung cấp giải pháp rất cạnh tranh (nhưng sau đó bạn sẽ phải mua mọi thứ ibm , bạn biết). Appian là nhà cung cấp trẻ, những người có những hiểu biết thú vị và phản hồi tích cực, nhưng cách họ viết (hai ngôn ngữ DSL bổ sung ngoài hình ảnh trực quan) chỉ không hấp dẫn tôi.

Có những người chơi khác, và giải pháp của họ. Hầu hết trong số họ là đồng bằng kinh khủng. Giống như - mắt, não và trái tim của bạn sẽ chảy máu theo nghĩa đen, khi bạn chỉ cần nhìn vào chúng. Vì vậy, hãy tin vào lòng can đảm của bạn và đừng khiến nhà phát triển và người dùng ghét bạn.

Lưu ý kết thúc:

Hệ thống BPM tương tự cho các quy trình, Photoshop là gì cho hình ảnh. Đừng sợ rằng nó trực quan. Đừng bắt nó làm công việc không phù hợp với nó (hãy nhớ các trang web được tạo hoàn toàn bằng Photoshop, bên cạnh không thể chỉnh sửa?). Giữ cho nó đơn giản và không tạo ra lỗi;)

Nhiều năm trước, trước khi hầu hết chúng ta được sinh ra, các nhà phát triển phần mềm phải tự viết mã để lưu trữ dữ liệu. Nếu bạn cần lưu trạng thái chương trình, thì, đó được coi là một phần chức năng của mã, vì vậy nhiều nhà phát triển phần mềm đã kết thúc việc viết mã để tổ chức dữ liệu và lưu và đọc nó.

Và rồi ai đó nhận ra rằng đây là điều đã xảy ra rất nhiều - rằng, logic để lưu, sắp xếp, đọc và tìm kiếm dữ liệu thực sự là một thành phần được sử dụng phổ biến đến mức nó phải là thành phần của chính nó. Và chúng tôi có cơ sở dữ liệu.

Trong 10 đến 15 năm qua, các bộ phận CNTT đã nhận ra rằng logic để biên đạo và / hoặc điều phối các quy trình kinh doanh rất phổ biến đến nỗi nó cũng phải là thành phần của chính nó, dẫn đến tất cả các loại công cụ quy trình công việc khác nhau.

Có 3 lợi ích chính của công cụ quy trình công việc:

1. Thời gian cần thiết để thực hiện và triển khai các thay đổi : bạn có thể phát triển và thay đổi logic của quy trình công việc mà không có rủi ro kỹ thuật giống như bạn gặp phải khi thay đổi một đoạn mã.
2. Tính minh bạch : logic nghiệp vụ trong hệ thống dựa trên BPM ngay lập tức có sẵn và có thể đọc được bởi nhà phân tích kinh doanh, trong khi chỉ có các nhà phát triển mới có thể đọc logic kinh doanh trong các hệ thống "dựa trên mã".
3. Tái sử dụng các thành phần kỹ thuật : Các công cụ BPM thường được sử dụng cùng với các hệ thống có Kiến trúc hướng dịch vụ. Bằng cách tách logic kinh doanh khỏi các thành phần kỹ thuật - đặc biệt đối với các hệ thống doanh nghiệp phải thực hiện hàng trăm hoặc hàng nghìn quy trình kinh doanh khác nhau - bạn có thể sử dụng lại các thành phần kỹ thuật trong khi dành khá ít thời gian để phát triển logic kinh doanh (với quy trình công việc dụng cụ).

Tuy nhiên, một trong những vấn đề phổ biến nhất mà tôi gặp phải với quy trình làm việc và sử dụng công cụ BPM, đó là các nhà phát triển vẫn cố gắng "chôn vùi" logic kinh doanh trong mã không minh bạch.

Những gì tôi thấy, mọi lúc , là các nhà phát triển vẫn cố gắng thêm logic kinh doanh theo những cách kỹ thuật nhất có thể, thay vì cách minh bạch nhất có thể. Điều này là tự nhiên, bởi vì các nhà phát triển, về bản chất, thoải mái hơn với mã so với công cụ quy trình công việc. Hơn nữa, bạn càng giữ logic theo cách kỹ thuật, bạn sẽ càng cần một nhà phát triển. Thật không may, đây là điều tồi tệ nhất mà nhà phát triển có thể làm đối với hệ thống BPM bởi vì anh ta hoặc cô ta đang trải qua những lợi ích chính của việc sử dụng BPM.

Cuối cùng, hầu hết các công cụ BPM không đủ xa để các nhà phân tích kinh doanh có thể tự phát triển quy trình công việc: tuy nhiên, đó là mục tiêu. Lý tưởng nhất, các nhà phân tích kinh doanh sẽ phát triển các sơ đồ quy trình công việc / quy trình kinh doanh và các nhà phát triển sẽ chỉ làm việc trên các thành phần kỹ thuật được gọi bởi công cụ dòng công việc.

Các tuyên bố dưới đây là kinh nghiệm cá nhân của tôi khi sử dụng các công cụ quy trình công việc, cụ thể là Oracle BPM Suite (10.3G & 11G). Trước tiên, để xác định, câu hỏi của bạn tập trung vào các công cụ quy trình công việc cho phép mô hình hóa các mô hình quy trình thực thi, các công cụ này là một phần của Hệ thống quản lý quy trình nghiệp vụ (BPMS). Mô hình quy trình cụ thể này chắc chắn đang phát triển và bạn có thể gọi nó là ngôn ngữ lập trình trực quan.

Lợi ích chính là sự nhanh nhẹn của sự hiểu biết và thay đổi logic quá trình

Với các mô hình quy trình nghiệp vụ, bạn bao gồm một giải thích trực quan về logic quy trình và đồng thời là một thành phần tích hợp có thể thực hiện được. Điều này cho phép các lập trình viên trên và ngoài nhanh hơn, bởi vì ít tài liệu về quá trình chuyển đổi, điều kiện (Cổng thông tin hoặc Quy tắc kinh doanh) và quy trình nói chung phải được ghi lại, vì là một phần của quá trình phát triển.

Ngoài ra, bạn đã đính kèm các khả năng báo cáo / giám sát, những gì bạn sẽ phải phát triển riêng cho từng ứng dụng, được bao phủ bởi hầu hết các BPMS.

Ngoài ra, trong hầu hết các môi trường phát triển BPM, các bộ điều hợp dịch vụ đã được dựng sẵn (ví dụ: JMS, Dịch vụ web, JDBC, v.v.), cho phép phát triển các giải pháp phần mềm trung gian nhanh hơn trong từng bước tích hợp tương tác, giảm lỗi của con người trong mã hóa.

Nền tảng tiến trình công việc tiếp theo đạt được rất nhiều lợi ích được đề cập ở trên - Cách tiếp cận dựa trên nền tảng để tự động hóa quy trình công việc

Giá trị

Đề xuất giá trị là quy trình công việc có thể được tạo ra hoặc thay đổi nhanh chóng và dễ dàng để phù hợp với tính chất thay đổi của một doanh nghiệp. Một phần quan trọng của việc hiện thực hóa đề xuất giá trị này, đó là bản thân các quy trình kinh doanh là các đơn vị tài nguyên trong hệ thống.

Quy trình làm việc dưới dạng đơn vị tài nguyên, có nghĩa là quy trình kinh doanh được xác định là một "đơn vị". Để hiểu những gì tôi muốn nói, hãy xem xét bất kỳ chương trình máy tính nào được viết cho một doanh nghiệp. Nó thực hiện một quy trình kinh doanh chắc chắn, nhưng logic cho quy trình đó có khả năng được lan truyền xung quanh mã nguồn ở một mức độ nhất định. Một công cụ quy trình công việc sẽ cho phép quy trình được xác định ở một nơi được chứa tốt. Nó có thể ở trong một tệp cấu hình duy nhất hoặc được trích xuất từ ​​một sơ đồ trực quan hoặc có thể có nghĩa là dòng công việc nằm trong một mô-đun mã duy nhất có thể được cắm, thậm chí có thể hoán đổi hoặc định cấu hình khi đang di chuyển.

Tại sao giá trị có thể không được nhận ra

Đề xuất giá trị này có thể bị làm suy yếu bởi những khó khăn trong việc bao gồm các trường hợp không phải là vanilla, tích hợp với công nghệ UI thay đổi rất nhanh, các thực tiễn xấu như chỉ sử dụng công cụ quy trình làm việc như một trình bao bọc và đưa logic thực sự vào mã.

Thiết kế kém của các công cụ có thể là một yếu tố hạn chế. Một ví dụ sẽ là một công cụ yêu cầu tất cả các tham số được truyền giữa các quy trình phải có trong Bản đồ Java, với các hạn chế về giá trị nào bạn thực sự có thể đặt trên bản đồ, thay vì chỉ là các tham số phương thức cũ đơn giản (Tôi đang nghĩ đến một trong những công cụ phổ biến đặc biệt làm điều này).

Tôi nghĩ có lẽ công bằng khi nói rằng IBM với tư cách là một người chơi lớn với hệ thống sinh thái công nghệ lớn, hội chợ tốt hơn những người khác. Nếu họ cũng kiểm soát công nghệ UI và cơ sở dữ liệu và công nghệ SOA được sử dụng cùng với công cụ quy trình công việc, họ sẽ có cơ hội tốt hơn để tạo ra một hệ thống sinh thái tích hợp độc đáo và tạo cơ hội để thực sự sử dụng ý tưởng này.

Điều chắc chắn là sự nỗ lực viết giao thoa giữa một công cụ quy trình công việc và các phần khác của hệ thống có thể phủ nhận hoàn toàn đề xuất giá trị. Nó luôn luôn đáng xem xét nếu có một cách tốt hơn để làm việc.

Lập trình là quy trình công việc

Sự thật là lập trình (ít nhất là bằng các ngôn ngữ bắt buộc) ĐÃ LÀM VIỆC. Bạn có thể có mã thực hiện quy trình công việc cần thực hiện với việc xử lý công nghệ hệ thống; truy cập các tệp và chạy các truy vấn SQL, v.v. Bạn có thể có mã thực hiện quy trình công việc; thiết lập trạng thái của tài liệu và chuyển nó cho người đánh giá chẳng hạn.

Nhận ra điều này và thiết kế mã của bạn để phân tách rõ ràng những mối quan tâm riêng biệt này rất khó để loại bỏ hoàn toàn, nhưng bạn chắc chắn có thể có một chặng đường dài với việc làm điều đó.

Tôi đồng ý với bạn, đôi khi chúng tôi kết thúc việc sử dụng các công cụ này bởi vì người khác quyết định đó là một ý tưởng tốt, và chúng quá phức tạp và khiến công việc của chúng tôi trở nên khó khăn hơn. Tôi không nghĩ rằng đó luôn là trường hợp, nó cần một số cân nhắc cẩn thận để quyết định xem nó có đáng hay không.

Nó không rõ ràng mà bạn đang sử dụng công cụ. Tôi đoán bạn có thể đang đề cập đến bộ công cụ chung gọi là công cụ Mô hình hóa quy trình nghiệp vụ. Có một lý do tốt để sử dụng các công cụ như vậy. Bất kỳ doanh nghiệp chất lượng nào cũng xác định chức năng của mình theo các quy trình và nhà phân tích cũng như các chuyên gia kinh doanh có thể rút ra các quy trình đó một cách thoải mái (cho đến khi bạn buộc chúng với các tiêu chuẩn ...). Bạn có thể tạo các quy trình như vậy ở cấp độ khái niệm mà không cần bất kỳ kiến ​​thức nào về lập trình web và nếu bạn có công cụ phù hợp, bạn cũng có thể chuyển đổi quy trình thành một ứng dụng hoạt động (những người có kinh nghiệm phải đưa ra phép thuật này để sản xuất tất nhiên). Vì vậy, ý tưởng là tốt.

Mục tiêu của các công cụ trực quan không chỉ là tài liệu của các quy trình. Việc sử dụng các công cụ này là để giúp các quy trình tái thiết kế chuyên nghiệp và đôi khi chạy mô phỏng để khám phá các điểm mà các quy trình kém hiệu quả hơn mong muốn để có thể đưa ra các kế hoạch để tháo gỡ các nút thắt cổ chai.

Có một cách tiêu chuẩn mà nhiều công ty sử dụng ngày nay gọi là BPMN 2.0 (Ký hiệu mô hình hóa quy trình kinh doanh). Tôi khuyên bạn nên hiểu về ký hiệu này nếu công cụ của bạn đang sử dụng nó.

Các Business Process Management Body of Knowledge là một nguồn lực nổi tiếng, mà bạn có thể muốn xem xét là tốt.

Trên đây bao gồm các mặt kinh doanh. Về mặt kỹ thuật đòi hỏi phải có SOA và BPEL, tôi không chắc mình có thể cung cấp lời khuyên về những người ở đây và bây giờ không.

Trong ví dụ đơn giản theo lịch sử.

Thời kì đồ đá

Lúc đầu, bạn có những công ty menhir nhỏ, nơi mọi người chỉ bảo phải làm gì và họ đã làm điều đó. Đôi khi mọi thứ sai, và Người X hoặc Y bị đổ lỗi (không bao giờ chắc chắn ai thực sự đã làm điều đó).

Internet và Email tiếp theo được phát minh.

Bây giờ mọi người đã viết cho người khác những việc cần làm và những người đó thường gặp vấn đề với Email của họ, đọc sai hoặc chỉ đơn giản là xóa một Email mà không bao giờ đọc nó; Vì vậy, những thứ thường không đổ lỗi cho Email xấu

Quy trình công việc phát triển ra khỏi quản trị Bằng cách tiêu chuẩn hóa các hành động, cuối cùng mọi người có thể thấy giai đoạn nào đã tạm dừng một quy trình, đồng thời, có được một cái nhìn tổng quan kỹ thuật số về những gì thực sự đã được thực hiện. Điều này hoạt động tốt cho đến khi mọi người muốn thay đổi các quy trình tiêu chuẩn hoặc cho đến khi một người XY không xác định nào đó gây ra yêu cầu cơ sở dữ liệu không phù hợp dẫn đến tham nhũng cơ sở dữ liệu, đưa sản xuất trở lại thời kỳ đồ đá ..