The next thing we'll need to add to our process are routes. Routes are typically nodes where decisions are made and, based on the rules of your process, where the flow of the application maybe altered. Strictly speaking, the position of a route in a swimlane doesn't really matter and will not change the logic of your process. For practicality's sake, however, it will be best to make it as legible as possible. Before modifying our process, there are 2 general concepts that you should be familiar with when dealing with routes. Given that routes are generally used to affect flow and insert logic and rules into your process, there are 3 types of common constructs for routes. They are: |
สิ่งต่อไปที่เราจะต้องเพิ่มในกระบวนการของเราคือเส้นทาง โดยทั่วไป Routes เป็นโหนดที่มีการตัดสินใจและขึ้นอยู่กับกระบวนการของคุณซึ่งอาจทำให้การไหลของแอปพลิเคชันมีการเปลี่ยนแปลง ตำแหน่งของเส้นทางไม่สำคัญและจะต้องไม่เปลี่ยนตรรกะกระบวนการของคุณ อย่างไรก็ตามเพื่อประโยชน์ของการปฏิบัติจริงมันจะเป็นการดีที่สุดที่จะทำให้มันชัดเจนที่สุดเท่าที่จะทำได้ ก่อนที่จะแก้ไขกระบวนการเรามีแนวคิดทั่วไป 2 ประการที่คุณควรทำเมื่อจัดการกับเส้นทาง เนื่องจากโดยทั่วไปเส้นทางจะส่งผลกระทบต่อโฟลว์และแทรกลอจิกและในกระบวนการของคุณจะมีโครงสร้างทั่วไป 3 แบบสำหรับเส้นทาง: |
Decisions are used when you want to insert a point in your process where the flow will be determined by a set of rules. For instance, in our Leave Application process, once a requester submits a leave request, a review by the supervisor will be required. You will see in the figure below that the transition from the requester to a supervisor happens in a straight line, which tells us that whenever a requester submits a request, that request will always go to the supervisor and there are no other circumstances or conditions in which that will not be true.
การตัดสินใจจะถูกใช้เมื่อคุณต้องการแทรกจุดในกระบวนการของคุณซึ่งการไหลจะถูกกำหนดโดยการตั้งค่า rules ตัวอย่างเช่นในกระบวนการ Leave Application เมื่อผู้ร้องขอส่งคำขอลาผู้ตรวจสอบจะต้องมีการตรวจสอบ คุณจะเห็นในภาพด้านล่างว่าการเปลี่ยนจากผู้ร้องขอเป็นผู้ดูแลเกิดขึ้นเป็นเส้นตรงซึ่งบอกเราว่าเมื่อใดก็ตามที่ผู้ร้องขอส่งคำขอ คำขอนั้นจะไปยังหัวหน้างานเสมอและไม่มีเงื่อนไขอื่นจะไม่เป็นจริง |
Now, what the supervisor decides to do will result in a decision: either choose to accept or reject the application. If the supervisor rejects it, a mail will be sent to the requester. If the supervisor accepts it, the application will be forwarded to the HOD.
ตอนนี้สิ่งที่หัวหน้างานตัดสินใจที่จะทำจะส่งผลให้เกิดการตัดสินใจ: เลือกที่จะยอมรับหรือปฏิเสธคำขอ หากหัวหน้างานปฏิเสธจดหมายจะถูกส่งไปยังผู้ร้องขอ หากหัวหน้ายอมรับยอมรับแอปพลิเคชันจะถูกส่งต่อไปยัง HOD |
Given the above, our process will look like the figure below:
เมื่อพิจารณาจากข้างต้นกระบวนการของเราจะมีลักษณะดังรูปด้านล่าง: |
There is, however, a very important caveat to insert here. Based on the rules above, if the approval value is "accept", the application will route to the HOD. If the approval value is "reject", then an email will be sent. However, if a mistake is made in the form or during user input and the value of approval is neither accept or reject, the process will get stuck because there is no valid rule to follow. It is due to this that the best practices of decision routing recommends using the Otherwise operator in this given scenario. If we make a slight change to the setting above and put the transition to system as Otherwise, we'll end up with:
| อย่างไรก็ตามมีข้อแม้สำคัญมาก ตามกฎข้างต้นหากค่าการอนุมัติคือ "ยอมรับ" แอปพลิเคชันจะกำหนดเส้นทางไปยัง HOD หากค่าการอนุมัติคือ "ปฏิเสธ" จะมีการส่งอีเมล อย่างไรก็ตามหากมีข้อผิดพลาดเกิดขึ้นในแบบฟอร์มหรือในระหว่างการป้อนข้อมูลของผู้ใช้ กระบวนการจะติดขัดเพราะไม่มี rule ที่จะปฏิบัติตาม เป็นเพราะการกำหนดเส้นทางในการตัดสินใจ แนะนำให้ใช้ตัวดำเนินการอื่นได้ หากเราทำการเปลี่ยนแปลงเล็กน้อยจากการตั้งค่าด้านบน ระบบจะสามารถดำเนินการจนเสร็จสิ้นได้: |
Note that effectively, the process remains unaltered. If the value of approval is "accept" it will route to the HOD. Any other value and the email will be sent.
โปรดทราบว่ากระบวนการยังคงไม่เปลี่ยนแปลง หากค่าการอนุมัติคือ "ยอมรับ" ระบบจะจัดเส้นทางไปยัง HOD รวมถึงเส้นทางอื่นๆและส่งอีเมลแจ้ง |
A fork is used when your process needs to split ways concurrently, meaning that your process will be traveling along 2 separate paths (hence, "fork"). For instance, in our given example, once the requester submits his leave application, a notification is sent to both his supervisor and HOD at the same time. If that is the case, we'll need to add a route, set the split type to "and" and our process will look like:
ใช้เมื่อกระบวนการของคุณต้องแยกพร้อมกันซึ่งหมายความว่ากระบวนการของคุณจะเดินทางไปตามเส้นทางที่แยกกัน 2 เส้นทาง (ด้วยเหตุนี้ "fork") ในตัวอย่างที่เราให้เมื่อผู้ร้องขอส่งคำร้องจะมีการส่งการแจ้งเตือนไปยังทั้งหัวหน้างานและ HOD ในเวลาเดียวกัน หากเป็นกรณีนี้เราจะต้องเพิ่มเส้นทางตั้งค่าประเภทการแยกเป็น "and" และกระบวนการของเราจะมีลักษณะดังนี้: |
NOTE: If done correctly, a plus sign (+) will appear inside the route.
หมายเหตุ: หากทำอย่างถูกต้องเครื่องหมายบวก (+) จะปรากฏขึ้นภายในเส้นทาง |
Joins usually occur when you have separate paths (usually caused by previous forks) in your process that you intend to merge. In our Leave Application process, once the requester submits his leave application, both the supervisor and HOD are notified. Once they respond, the application ends up at the back office desk for further processing.
There are 2 types of joins:
การเข้าร่วมมักจะเกิดขึ้นเมื่อคุณมีเส้นทางแยก (มักเกิดจาก forks ) ในกระบวนการของคุณที่คุณต้องการผสาน ในขั้นตอนการ Leave Application ของเราเมื่อผู้ร้องขอส่งคำขอลาของเขาทั้งหัวหน้าและ HOD จะได้รับแจ้ง เมื่อพวกเขาตอบกลับแอปพลิเคชันจะสิ้นสุด ระบบจะทำงานด้านหลังเพื่อดำเนินการต่อ joins มี 2 ประเภท: |
XOR (or exclusive ORs in geek talk) means that the route is active and considered fulfilled once any of the transitions reaches it. So if you use the XOR option in your join route, the back office will be notified the moment either the supervisor or HOD responds.
XOR (หรือ ORs พิเศษ) หมายความว่าเส้นทางนั้นมีการใช้งานอยู่และได้รับการพิจารณาว่าสมบูรณ์เมื่อการผ่านใด ๆ มาถึง ดังนั้นหากคุณใช้ตัวเลือก XOR ในเส้นทาง ระบบด้านหลังจะได้รับการแจ้งเตือนทันทีที่หัวหน้าหรือ HOD ตอบกลับ |
AND means that the route will wait for all the transitions to be completed. So if you use the AND option, the back office will only be notified if and when both the supervisor and the HOD have responded.
และหมายความว่าเส้นทางจะรอกระบวนการทั้งหมดให้เสร็จสมบูรณ์ ดังนั้นหากคุณใช้ตัวเลือก AND ระบบด้านหลังจะได้รับแจ้งเฉพาะเมื่อทั้งหัวหน้างานและ HOD ตอบกลับแล้ว |
To sum it up, once the requester submits an application, the supervisor will decide on whether to accept or reject. If the supervisor accepts, the application will go to the HOD for approval. Two routes are needed here: one for when the supervisor approves and another for when the HOD approves. Again, while the position of the routes in specific swimlanes doesn't really matter, it is ideal to keep the process legible.
ในการสรุปผลเมื่อผู้ร้องขอส่งคำร้องให้หัวหน้างานจะตัดสินใจว่าจะยอมรับหรือปฏิเสธ หากหัวหน้ายอมรับยอมรับแอปพลิเคชันจะไปที่ HOD เพื่อขออนุมัติ จำเป็นต้องมีสองเส้นทาง: หนึ่งเส้นทางเมื่อผู้บังคับบัญชาอนุมัติและอีกเส้นทางหนึ่งเมื่อ HOD อนุมัติ ที่ตำแหน่งของเส้นทางที่เฉพาะเจาะจงมันเหมาะที่จะทำให้กระบวนการชัดเจน |
After adding the routes, the process should look like:
หลังจากเพิ่มเส้นทางกระบวนการควรมีลักษณะดังนี้: |
