จากตอนก่อนๆที่เล่าไว้ เราพอจะรู้ว่าว่า workflow เป็นสิ่งที่สำคัญที่ทั้ง developer และ business owner ควรจะใช้เพื่อให้เข้าใจระบบเป็นภาพเดียวกัน แต่ก็เกิดปัญหากันมาบ่อยๆ เพราะ developer มันจะเอาสิ่งที่ business บอกมา ไปตีความต่อเอาเอง แล้วก็วาด diagram ในแบบตัวเอง ทำไปทำมาก็จะเกิดปัญหาว่าคุยกันคนละภาษา เข้าใจกันไปคนละแบบ
และเราก็คงพอจะรู้แล้วว่าปัญหานี้แก้ได้ด้วยการใช้ workflow diagram ที่เป็นมาตรฐานกลาง เพื่อให้นำเอกสารไปใช้งานต่อได้ทั้งฝาก developer และ business
แต่ก่อนจะไปต่อกับ BPMN อยากจะขอเล่าย้อนกลับไปในอดีตสักหน่อย ว่าจริงๆแล้วเราเคยมี standard อื่นที่น่าสนใจนอกเหนือจาก bpmn ด้วย เนื่องจากในสมัยก่อนจะมี 2 ค่ายเด่นๆ ที่ออกมาตรฐานมาให้เราได้ใช้กัน ได้แก่ xpdl และ bpmn โดยที่ทั้งคู่ต่างก็พัฒนามาจาก business process management (BPM) ซึ่งทางฝั่ง xpdl นั้นเป็น open standard จากกลุ่ม WfMC (ประกาศยุบกลุ่มไปแล้วเมื่อ 2019) ส่วน bpmn นั้นยังได้รับการผนวกเข้าไปใช้ใน ISO ด้วยเราจึงจะยังเห็นมันถูกใช้อธิบาย flow การทำงานของธุรกิจอยู่ในเอกสารตามมาตรฐาน ISO-15000 ด้วย
สำหรับ xpdl นั้นเราจะพบรายละเอียดที่ใกล้เคียงวิธีคิดแบบ programmer มากกว่า (อย่างเช่นการระบุตัวแปรที่ใช้ตัดสินใจใน business หรือการระบุ script ในการเลือกเส้นทางของ flow เป็นต้น) และ xpdl ก็สามารถบอก flow ของ business ได้เป็นอย่างดี แต่ก็ทำให้ฝ่าย business อาจจะเหนื่อยในการลงรายละเอียดปลีกย่อยที่ค่อนข้างจะเยอะเอาเรื่อง
ในขณะที่ bpmn นั้นสามารถอธิบายในมุม business ได้ง่ายกว่า เขียนได้กระชับกว่า แต่ก็ยังสามารถบอกส่วนที่จำเป็นให้ dev ได้ไม่ขาดตกบกพร่องเช่นกัน
และเนื่องจาก xpdl นั้น กลุ่ม WfMC ที่สร้างมันขึ้นมาก็ได้ประกาศยุบกลุ่มกันไปแล้วเมื่อปี 2019 ซึ่งก่อนที่จะยุบกลุ่มนั้น ตัวมาตรฐาน xpdl 2.2 เองก็เคยได้ผนวกเอา bpmn บางส่วนเข้าไปใส่ในมาตรฐานมาแล้วด้วย ดังนั้น bpmn ก็น่าจะเรียกได้ว่า เป็นตัวเลือกเพียงหนึ่งเดียวที่เหลืออยู่ให้เรายึดเป็นมาตรฐานเพื่อนำไปใช้กันแล้ว
สำหรับเนื้อหาต่อไป จะเป็นการแนะนำให้รู้จักส่วนประกอบ และรายละเอียดต่างๆที่จะปรากฎใน bpmn diagram ซึ่งเราสามารถนำสิ่งที่ได้ไปวาดเป็นรูกภาพ bpmn diagram ได้เองแม้จะไม่มี tool สำเร็จรูป แต่หากใจร้อนอยากไปเล่น tool สำเร็จรูปที่ได้รับการ implement จากมาตรฐาน bpmn ให้แล้วก็สามารถข้ามเนื้อหาไปยัง link ที่อยู่ด้านล่างสุดเพื่อเข้าไปลองเล่นดูได้เช่นกัน
ส่วนประกอบหลักใน Workflow Diagram
ใน workflow diagram สามารถแบ่งส่วนประกอบสำคัญๆได้ 3 ส่วน คือ
1. participant หรือผู้เกี่ยวข้อง หรือผู้กระทำกิจกรรม
2. activity ซึ่งจะบอกว่าจะเกิดกิจกรรมอะไร เมื่องานไหลไปถึงจุดนั่น
3. route ซึ่งจะบอกว่า flow งานจะต้องไหลไปที่ไหนต่อ
การแบ่งแบบนี้นอกจากจะช่วยให้เรารู้ว่า ใครทำกิจกรรมอะไร ใน flow แล้ว มันยังช่วยให้เราออกแบบระบบโดยแยก participant ให้เป็น layer ของระบบ user หรือ profile ออกมาจาก business logic ได้ด้วย
เช่น participant “ผู้ขอสร้างงาน” คือ user ที่มีค่า ldap_attribute5 ตรงกับอันใดอันหนึ่งใน [“call center”, “crm”, “crm mgr”] เท่านั้น, หรือ participant “ผู้อนุมัติ” คือ user ที่มีค่า ldap_attribute5 ตรงกับอันใดอันหนึ่งใน [“process mgr”] เท่านั้น เป็นต้น
ส่วนด้าน activity เรายังสามารถออกแบบระบบให้เป็น layer ด้วย plugin interface เพื่อให้ config ได้ว่าใช้ class ไหน สำหรับกิจกรรมไหน เช่น activity “create_doc” ใช้ class callStoreProc ด้วย parameter user_id = current_uset, activity “edit_doc” ใช้ class openScreen ด้วย parameter screen_id = “edit_doc”, activity “send_mail” ใช้ class smtpUtil ด้วย parameter template_id = “report_all_participant” เป็นต้น
และด้านของ route เรายังออกแบบให้ระบบมาอ่าน flow ตามเอกสาร BPMN ทำให้สามารถแก้ไขที่เอกสารได้เลย แทนที่จะไปรื้อ code เพื่อให้เปลี่ยนแปลงไปตาม business
มาตรฐานสัญลักษณ์ต่างๆใน BPMN
ก่อนที่เราจะวาด diagram ได้ เราต้องมาทำความรู้จักสัญลักษณ์สำคัญต่างๆที่จะใช้งานกันก่อนด้วย แต่เนื่องจากตัวมาตรฐานนั้นมีรายละเอียดค่อนข้างเยอะ และไม่จำเป็นต้องใช้ทั้งหมดก็ทำงานได้ บทความนี้จึงขอพูดถึงเฉพาะส่วนหลักๆที่มักถูกนำไปใช้งาน
สัญลักษณ์ event หรือ เหตุการณ์
สัญลักษณ์นี้ก็อธิบายได้ตามชื่อของมันเลย แต่มันก็แบ่งย่อยได้อีกเป็น 3 เหตุการณ์ใหญ่ๆ คือ
- start ใช้บอกจุดที่ใช้เริ่มต้นของ flow
สัญลักษณ์ เป็นวงกลม (ในบาง tool มักจะใส่สีเขียวไว้ให้ด้วย) - intermediate คือ event ที่เกิดในระหว่าง flow
สัญลักษณ์จะเป็นวงกลมเส้นคู่ - end ใช้บอกว่าเป็นจุดสิ้นสุดของ flow
จะเป็นวงกลมเส้นหนาๆ (ในบาง tool มักจะใส่สีแดงไว้ให้ด้วย)
สัญลักษณ์ย่อยที่อยู่ใน event
จากที่เรารู้จักสัญลักษณ์ event แล้ว แต่ข้างในวง event ยังมีสัญลักษณ์จำแนกไปได้อีกว่าเป็น event แบบไหน ที่ทำให้ flow ย้ายเข้าไปสู่ activity ถัดไป
- message คือบอกว่า เกิดเพราะพวก messaging ต่างๆ ไม่ว่าจะเป็นการ call api หากันหรือ ส่ง message queue หากัน หรือ ส่ง email ก็ได้ เพราะตัว diagram ไม่ได้สนใจว่าทาง technical จะส่ง message แบบไหน เอาเป็นว่าส่ง message ก็พอ
- timer คือ บอกว่าเป็นเหตุการณ์ที่เกิดขึ้นตามเวลา จะเป็นการตั้งเวลา หรือยังไงก็ดูในรายละเอียดเอา (ถ้าออกแบบระบบให้ฉลาดๆ ตรงจุดนี้อาจระบุเป็น script เอาไว้ให้ระบบเอาไปทำงาน ควบคู่ไปกับคำอธิบายภาษามนุษย์ก็จะดีไม่น้อย) อย่างเช่น start flow ทุกๆวันที่ 2 ของเดือน เป็นต้น หรือ ใช้ activity ถัดไปโดยอัตโนมัติเมื่อเวลาผ่านไป 24 ชม.
- escalation คือ บอกว่าเป็น event ให้เข้าสู่ activity ถัดไปเพราะเกิดการยกระดับงานขึ้น เช่น มีลูกค้าระดับ vip เข้ามาเกี่ยวข้องในงาน, หรือมี user อำนาจสูงเข้ามามีส่วนร่วมในงาน
- conditional คือ บอกว่าเกิดจากการคำนวณแล้วผลลัทธ์ตรงตามเงื่อนไข (อย่าลืมว่ามุมมองหลักๆคือ business นะ) ถ้าเทียบกับ programming ก็คือ if หรือ case นั่นแหละ
- link คือ บอกว่า link ไป หรือ link มาจากไหน มันมีประโยชน์มากเวลา flow มันใหญ่ๆ จะได้ไม่ต้องลากเส้นทับกับไปมาจนเละเทะ
- error คือ บอกว่า event นี้เกิดจาก error โดยถ้าเอาไปใช้ใน sub process จะหมายถึง ให้หยุดการทำงานที่ process หลักที่เรียกใช้มันด้วย น่าจะเทียบได้กับ การ throw exception ของ java หรือ panic ของ golang
- cancel คือ บอกว่า event เกิดเพราะการยกเลิก จะเพราะกดปุ่มยกเลิกที่หน้าจอตอนอยู่ใน activity ก่อนหน้า หรือ automatic activity ก็แล้วแต่เลย จริงมันก็ค่อยไม่ต่างจาก condition หรอก มันแค่บอกให้เห็นชัดๆในเอกสารว่านี่คือการยกเลิก
- compensation คือ บอกว่าเกิด event ขึ้นเพราะ การทำงานไม่สมบูรณ์ เช่น ส่งของไม่สำเร็จจึงต้องเข้าสู่กระบวนการคืนเงินเป็นต้น
- signal จะคล้ายๆ message แต่อันนี้จะใช้ตอนส่งข้าม process เช่น เราพัฒนา platform ซื้อขาย A และเราต้องพูดถึงระบบจ่ายเงิน B ที่เราไม่ได้ implement แต่มันก็มี flow การทำงานของ B บางส่วนที่เราต้องพูดถึง เช่น เลือกส่ง signal ไป payment gateway B เกิด flow การชำระเงิน จนจบ B ก็ signal กลับมาให้ A เป็นต้น
- multiple คือ แตก multiple process ออกไปหาหลายๆ activity (ดูคู่กับ parallel multiple) , เหมือนการ fork ในภาษา C หรือ syscall.ForkExec golang หรือ multi thread ใน Java
- parallel multiple คือ เกิดการ รอจนกว่า parallel process ที่เกิดก่อนหน้านั้นจะทำงานจบทั้งหมด ถึงจะทำงานต่อ (programmer อาจจะคุ้นกับคำว่า join fork มากกว่า)
- terminate คือ บอกว่าเป็นการหยุดการทำงานทั้งหมดลง หรือการจบ flow นั่นเอง
สัญลักษณ์ของ activity
Activity หรือกิจกรรม จะมีสัญลักษณ์อยู 4 แบบ โดยจะเป็นการขยายจากแบบปกติพื้นฐาน คือ task ออกไปเป็นแบบย่อยอีก 3 แบบ เป็น Sub-process, Transaction, และ Call
- task คือ activity ปกติทั่วไป ซึ่งเป็นการบอกว่าเกิดกิจกรรมอะไรใน flow ณ จุดนั้น อาจจะเป็นการรอ user input อะไรที่หน้าจอไหน ก็แล้วแต่จะออกแบบ (บางระบบอาจจะออกแบบให้บาง activity เป็นกลุ่มของหน้าจอที่ user จะสามารถเข้าใช้งานได้ หรือเป็น default เวลาเปิดงานก็เป็นไปได้)
- sub-process คือการรวบ หลายๆ activity ย่อยๆ มาวาดเป็น activity เดียว เพื่อประหยัดพื้นที่จะได้มองภาพรวมได้ง่ายขึ้น
- transactional ก็คล้ายๆ sub-process แต่จะเป็นการทำงานแบบ transaction นั่นคือ ยกเลิกทั้ง process ได้หากไม่ได้ทำงานจนจบ process แบบสมบูรณ์ (เหมือนเรื่อง transactional ของ database)
- call ก็คล้ายๆ sub-process อีกนั่นแหละ แต่จะเป็นการบอกด้วยว่า activity นี้อาจจะถูก reuse ไปใช้อีกที่ไหนก็ได้ (จริงๆเราก็แค่วาดใหม่ใน diagram ก็ได้นะ แต่การระบุแบบนี้ คนสร้าง tool อาจจะออกแบบ parameter สำหรับ activity ชนิดนี้ให้ระบุ global id ไว้เรียกใช้ซ้ำๆได้ อันนี้ก็แล้วแต่ว่าจะพลิกแพลงกันยังไง)
สัญลักษณ์ Gateway
ต่อมาเป็นสัญลักษณ์ที่เกี่ยวข้องกับ direction ของ flow (จริงๆ มันมีทั้ง direction และ event symbol ผสมกันอยู่ในหัวข้อนี้ ) นั่นคือ gateway
- exclusive เป็นจุดที่ระบุว่ามีทางเลือกไหนให้ flow ไหลไปได้บ้าง โดยไหลไปได้แค่ทางใดทางหนึ่งเท่านั้น ณ จุดนี้มักจะระบุเงื่อนไข ว่าจะไปทางไหนด้วยเงื่อนไขอะไร แต่จริงๆแล้ว เราสามารถระบุที่ event ในแต่ละ direction ที่จะไปได้แทนก็ได้เหมือนกัน ซึ่ง flow อาจเกิดความสับสนได้ถ้าไม่ตรวจดูให้ดีๆ
- event based อันนี้จะคล้ายๆ exclusive คือเป็นการบอกว่า flow สามารถไหลไปไหนได้บ้างเหมือนกับสัญลักษณ์ exclusive แต่แทนที่จะพิจารณาจากเงื่อนไข if else ก็ไปพิจารณาที่ event แทน เช่น ส่ง mail หาผู้บริหารแล้ว ให้รอจนกว่าผู้บริหารจะได้รับและเข้ามาสั่งการอะไรบางอย่างถึงจะไปต่อ เป็นต้น
- parallel อันนี้เป็นการบอกว่า flow ที่แยกไปนั้นเกิดขึ้นอย่างอิสระพร้อมๆกัน เช่น สั่งสินค้า 3 บ. แต่ละ บ. ก็ดำเนินการติดต่อส่งของให้ลูกค้าไป ไม่ต้องรอ บ. อื่นส่งของให้เสร็จก่อน (เหมือนการ fork ในภาษา C หรือ new thread ใน Java แหละ แต่อันนี้มันเรื่องของ flow การทำงาน)
- inclusive อันนี้จะคล้ายๆกับ exclusive แต่ใช้เพื่อย้ำว่า activity ถัดไปมันคือ sub flow (หรือ sub-process นั่นแหละ)
- exclusive event based อันนี้คล้ายๆ event based แต่จะย้ำว่า activity ถัดไปจะเป็น sub flow นะ
- complex ตามความเข้าใจของผู้เขียน เข้าใจว่าถูกออกแบบมาไว้ใช้วาด flow ที่ level ต่ำๆ เพื่อให้สามารถยุบรายละเอียดเพื่อแสดงให้เห็นภาพกว้างๆ ของทั้ง flow โดยสัญลักษณ์นี้จะเป็นการบอกว่า มี gateway หลายๆแบบผสมอยู่ด้วยกัน
- parallel event based อันนี้คือ parallel gateway เลย แต่แค่บอกว่าแต่ละ route มันจะทำงานเพราะ event นะ ไม่ใช่เงื่อนไข if-else (เอาจริงๆถึงจะเขียนสลับกัน กับ parallel gateway ผลการเดิน flow มันก็ไม่น่าจะต่างกัน แต่อันนี้น่าจะออกแบบไว้สร้าง tool ในการวาด diagram มากกว่า)
สัญลักษณ์ connecting
ส่วนนี้เป็นเรื่องของ direction หรือ route ใน flow จริงๆละ โดยใน BPMN เรียกว่า connecting ซึ่งเราจะเห็นเป็นเส้นเชื่อระหว่าง event, activity, gateway เข้าด้วยกันโดยมีหัวลูกศรบอกทิศทางการไหลของ flow (ยกเว้นบางอันที่ไม่มีหัวลูกศร เพราะทำหน้าที่เชื่อมตัวขยายความให้รู้ว่าพูดถึง object ไหนใน flow เท่านั้นเอง)
- sequence flow อันนี้น่าจะเดาได้ไม่ยากเพราะมันคือตัวหลักในการบอกทิศทางการไหลของ flow เลย
- message flow อันนี้พิเศษหน่อย เพราะถ้าหากเราจะเชือม 2 flow เข้าหากัน เช่นเราสร้าง platform ซื้อขาย A และ flow ต้องไปเรัยกระบบจ่ายเงิน ซึ่งไม่ใช่ของเราแต่มันก็มี flow ในส่วนของมัน เราจะไม่ใช้ sequence flow ชี้ไปหากัน แต่จะใช้ message flow เพื่อบอกว่ามีการส่ง message ออกไปสร้าง event ใส่ flow อื่น หรือ flow อื่น ส่ง message เข้ามาสร้าง event ที่ flow เรา
- assosiation อันนี้ไม่ได้บอกทิศทางของ flow แต่เอาไว้เชื่อมให้รู้ว่าอะไรเกี่ยวข้องกัน (มันจะใช้กับตัวขยายความ หรือพวก artifact ต่างๆ อย่างเช่น annotation ว่าอธิบายถึง object ไหนของ flow)
สัญลักษณ์ Artifact
นอกจากนี้ยังมีสัญลักษณ์อีกประเภท ที่ถูกเรียกว่า artifact ซึ่งมันเป็นส่วนเสริมเพื่อใช้อธิบายเพิ่มเติมใน diagram เพื่อให้เข้าใจรายละเอียดมากขึ้น ไม่ได้มีผลกับ flow
- Annotation อันนี้เมือนเป็นโน๊ตอธิบาย อยากจะเขียนอะไรก็เขียน มันจะไม่มีผลใดๆกับ flow การทำงาน
- Group เป็นการวาดเส้นกรอบเพื่อล้อม object ให้รู้ว่ามันเป็นกลุ่มเดียวกันเฉยๆ ไม่มีผลใดๆกับ flow เช่นกัน
- Data objects เป็นสัญลักแทนข้อมูลต่างๆที่จะส่งเป็น input ใน process หรือ เป็นผลลัพท์ที่ได้มาจากการ process หรือ ข้อมูลที่ต้องไปตามเก็บมา หรือ ข้อมูลที่จะถูกจัดเก็บในระบบ ซึ่งยังมีกำหนดถึงสัญลักษณ์ย่อยแยกเอาไว้อีกด้วย
สัญลักษณ์ย่อยของ Data objects artifact
- Data input ใช้แสดงถึง ข้อมูลที่ต้องใช้ส่งเข้าไปในกระบวนการทาง business
- Data output ใช้แสดงให้เห็นถึง ข้อมูลที่เป็นผลลัพธ์จาก กระบวนการทาง business
- Data collection ใช้แสดงถึง ข้อมูลที่จะรวบรวมได้ในกระบวนการทาง business
- Data storage ใช้แสดงถึงพื้นที่ที่ใช้จัดเก็บหรือเข้าถึงข้อมูลในกระบวนการทาง business (โดยมากก็จะหมายถึง table ใน database , แต่จะหมายถึงแฟ้มเอกสาร หรือห้องที่จัดเก็บก็ได้เหมือนกัน)
สัญลักษณ์ Swimlane
นี่เป็นสัญลักษณ์ที่ไม่พูดถึงไม่ได้ จุดมุ่งหมายของ swimlane จะทำเพื่อจัดระเบียบของ process เป็นกลุ่มต่างๆ และถ้าเทียบกับ xpdl แต่ละ lane จะหมายถึง participant แต่ละกลุ่ม และของ xpdl จะมี pool ชุดเดียวสำหรับ flow เดียว ในหน้าเอกสาร แต่ว่าใน bpmn เราสามารถวาดหลายๆระบบ flow ในเอกสารหน้าเดียวกันได้เลย จึงสามารถเห็น pool หลายๆชุดในหน้าเอกสาร โดย 1 pool ต่อ 1 flow เช่นกัน
ดังนั้น swimlane ใน BPMN จึงสามารถใช้บ่งบอกผู้เกี่ยวข้องในแต่ละ process เช่นเดียวกับที่ XPDL ใช้ และการแบ่ง lane เป็น participant นั้นก็ดูสมเหตุสมผลมากกว่าที่จะจัดเป็นเพียงชื่อกลุ่มลอยๆโดยไม่มีความหมายกับผู้ทำงาน
ข้อสังเกตุ การกำหนดชื่อใน swimlane ไม่ควรกำหนดเป็นชื่อตำแหน่ง หรือกลุ่ม แต่ควรมองให้เป็นบทบาทต่างๆใน flow การทำงานเพราะถ้าจัดกลุ่มด้วยบทบาท เรายังสามารถแบ่ง layer ในการจัดกลุ่มได้ว่า ใครจะได้รับบทบาทนั้นบ้าง โดยสามารถกำหนดได้ทั้งแบบรายบุคคล หรือสังกัดตำแหน่งของบุคคล หรือจะเป็น property ต่างๆของบุคคลก็ได้ เช่น บทบาท “ผู้สร้างเอกสาร” มอบให้ฝ่าย crm, teller ในขณะที่บทบาท “ผู้ออกใบรับสินค้า” คือเจ้าหน้าที่คงคลังที่มีตำแหน่งระดับ 3 ขึ้นไป เป็นต้น ซึ่งการกำหนดแบบนี้ ยังช่วยให้เราออกแบบระบบให้ระบุเป็น script ได้อีกด้วย เช่น ระบุเป็น user.ldap_attr_03 in [‘inventory’] && user.level >= 3 เป็นต้น
มาถึงตรงนี้คงจะพอเห็นภาพมากขึ้นว่า BPMN นั้นถูกออกแบบให้รองรับการอธิบาย business workflow ได้อย่างยืดหยุ่นมาก และมันก็ใช้อธิบาย flow การทำงาน ให้กับ programmer ได้อย่างละเอียดด้วยเช่นกัน นั่นแปลว่าหากเราเขียนเอกสาร workflow ได้ดีพอ เราไม่จำเป็นต้องแยกเอกสารให้เป็นมุมมองของ business และมุมมองของ programmer เลย เพราะใน workflow มันก็บอก dataflow อยู่ในตัว
แล้ว บอก conditional logic อยู่แล้ว แถมยังบอกอีกด้วยว่า user access management ต้อง grant สิทธิ์ให้ใคร ณ activity ไหนบ้าง
ตอนหน้าจะมาแชร์การเขียน flow ด้วย tool ที่ชื่อ bpmn.js ซึ่งเป็น open source และมีให้ใช้ free แบบ online โดยที่เราสามาถ save เป็น xml file หรือ load ขึ้นไป edit ได้อย่างอิสระ และผู้เขียนก็ได้นำตัวอย่างการ implement ต่างๆจากที่นี่ bpmn-js-example มาทดลองพัฒนาต่อยอดให้ใช้งานลูกเล่นต่างๆได้เพิ่มขึ้น ซึ่งผู้อ่านก็สามารถเข้าไปลองเล่นดูได้ที่นี่ http://www.kodezon.ml/bpmn-js-app/
หมายเหตุ : ผู้เขียนเลือกสัญลักษณ์มาอธิบายเพียงบางส่วนที่เห็นว่าใช้งานบ่อย และควรรู้ โดยอิงจาก bpmn-symbol-explained แต่จริงๆแล้ว BPMN ยังมีรายละเอียดอื่นๆให้นำมาใช้งานได้อีก โดยผู้อ่านสามารถอ่าน BPMN Specification ตัวเต็มได้ที่ https://www.omg.org/spec/BPMN/2.0/PDF
