การสร้างกฎเกณฑ์ทางธุรกิจด้วย Drools - พลังสู่ SMEople

สิ่งที่น่าทึ่งที่สุดประการหนึ่งเกี่ยวกับการทำงานในการพัฒนาซอฟต์แวร์คือความสามารถในการทำงานในอุตสาหกรรมต่างๆ มากมาย โดยเฉพาะอย่างยิ่งหากคุณเป็นที่ปรึกษา ทักษะการพัฒนาซอฟต์แวร์ส่วนใหญ่ที่คุณเรียนรู้ขณะทำงานภายในอุตสาหกรรมหนึ่งสามารถถ่ายทอดโดยตรงไปยังอุตสาหกรรม บริษัท โครงการและกลุ่มเฉพาะอื่นๆ จำนวนเท่าใดก็ได้

ฉันกำลังพูดเกี่ยวกับหัวข้อต่างๆ เช่น การออกแบบฐานข้อมูล รูปแบบการออกแบบ เลย์เอาต์ GUI การจัดการเหตุการณ์ ฯลฯ แน่นอนว่ามีหัวข้อเฉพาะสำหรับอุตสาหกรรม บริษัท หรือโครงการหนึ่งโดยเฉพาะ

SME พบกับ IT เริ่มถ่ายทอดความรู้

นี่คือที่มาของ Subject Matter Expert (SME) โดยทั่วไปแล้ว SME จะมีส่วนร่วมอย่างมากในขั้นตอนการออกแบบของโครงการ

SME ได้ทำงานในอุตสาหกรรมมาเป็นเวลานาน รู้จักศัพท์แสง และเข้าใจตรรกะทางธุรกิจที่อยู่เบื้องหลังการเข้ารหัส SME อาจมีความเข้าใจในการพัฒนาซอฟต์แวร์บ้าง แต่ก็ไม่จำเป็นสำหรับโครงการที่จะประสบความสำเร็จ

สำหรับหลายโครงการ เว้นแต่ผู้พัฒนาซอฟต์แวร์จะมีความเข้าใจในตรรกะทางธุรกิจเป็นอย่างดี การทำให้แอปพลิเคชันซอฟต์แวร์ประสบความสำเร็จนั้นค่อนข้างยาก ระยะเวลาที่ใช้ในการถ่ายทอดความรู้จะแตกต่างกันไปตามความซับซ้อนของโครงการ

สมมติว่ามีการนำแนวทางที่คล่องตัวและ SMEs หนึ่งรายขึ้นไปพร้อมให้บริการตลอดขั้นตอนการพัฒนาของโครงการ การถ่ายทอดความรู้จะดำเนินต่อไปในทุกขั้นตอนของโครงการ

จะเกิดอะไรขึ้นถ้าการถ่ายทอดความรู้ที่สมบูรณ์ไม่สามารถทำได้?

ขึ้นอยู่กับอุตสาหกรรมและโครงการ เอสเอ็มอีอาจไม่สามารถถ่ายทอดความรู้ที่สมบูรณ์ได้ ทั้งนี้ขึ้นอยู่กับอุตสาหกรรมและโครงการ

ตัวอย่างเช่น ลองนึกภาพว่า SME เป็นแพทย์ที่มีประสบการณ์ 25 ปี และคุณมีเวลา 6 เดือนในการทำโครงการให้เสร็จ หรือลองจินตนาการว่า SME เป็นนักชีววิทยาที่มีประสบการณ์ 40 ปี ระดับความรู้ดังกล่าวไม่สามารถถ่ายทอดในกรอบเวลาจริงสำหรับโครงการพัฒนาซอฟต์แวร์ได้

แต่ถ้าพื้นที่ความรู้เป็นไดนามิกล่ะ?

โดยปกติ ซอฟต์แวร์จะออกตามกำหนดเวลาตามเวลาหรือคุณสมบัติ อย่างไรก็ตาม กฎเกณฑ์ทางธุรกิจภายในบางอุตสาหกรรมเปลี่ยนแปลงบ่อยกว่ามาก

ในหลายกรณี อาจไม่สามารถเผยแพร่ซอฟต์แวร์ได้บ่อยเท่าที่จำเป็นเพื่อให้ทันกับการเปลี่ยนแปลงของอุตสาหกรรม ความสามารถในการสร้างกฎเกณฑ์ทางธุรกิจภายนอกภายในกลไกจัดการกฎธุรกิจอาจสมเหตุสมผลในสถานการณ์ดังกล่าว ความสามารถสำหรับโครงการซอฟต์แวร์ที่สามารถทนต่อการเปลี่ยนแปลงจะช่วยให้มั่นใจได้ถึงความสำเร็จในระยะยาวสูงสุด

เมื่อใดและที่ไหนที่กลไกของกฎมีความสมเหตุสมผล?

สำหรับโครงการซอฟต์แวร์หลายโครงการ มีความเป็นไปได้ที่จะมีการถ่ายโอนความรู้เต็มรูปแบบ และสำหรับตรรกะทางธุรกิจที่จะเขียนโค้ดในภาษาคอมพิวเตอร์เช่น C # หรือ Java

อย่างไรก็ตาม มีชุดย่อยของโปรเจ็กต์ที่มีปริมาณความเข้าใจในหัวข้อที่เฉพาะเจาะจงมาก หรือกฎเกณฑ์ทางธุรกิจอาจมีการเปลี่ยนแปลงอย่างมากจนทำให้ผู้ที่ไม่ใช่โปรแกรมเมอร์เข้าถึงตรรกะทางธุรกิจได้โดยตรง นี่เป็นหัวข้อของบทช่วยสอนนี้ โดยที่ในใจ มาหารือเกี่ยวกับ Rules Engines ในเชิงลึก

เครื่องมือกฎธุรกิจคืออะไร?

กลไกจัดการกฎเป็นเครื่องมือสำหรับดำเนินการกฎเกณฑ์ทางธุรกิจ กฎเกณฑ์ทางธุรกิจประกอบด้วยข้อเท็จจริงและข้อความแบบมีเงื่อนไข คำสั่ง "if-then" ใดๆ ที่ปรากฏในตรรกะทางธุรกิจแบบเดิมถือเป็นกฎเกณฑ์ทางธุรกิจ

ตัวอย่างเช่น หาก พนักงานลาป่วยติดต่อกันเกิน 5 วันและไม่มีบันทึกของแพทย์ ก็ จะต้องเขียนบันทึกดังกล่าว หาก ไม่มีการติดต่อกับผู้ร่วมธุรกิจเป็นเวลานานกว่า 6 เดือนและไม่ได้ทำการซื้อใดๆ ในช่วงเวลา ดัง กล่าว อาจถึงเวลาที่ต้องส่งอีเมลหาพวกเขาอย่างจริงใจ หาก ผู้ป่วยมีอุณหภูมิร่างกายสูง มีปัญหาด้านการมองเห็น และมีประวัติครอบครัวเป็นโรคต้อหิน อาจถึงเวลา ที่ ต้องขอ MRI เพิ่มเติมหรือการทดสอบอื่นๆ

SMEs เขียนกฎเกณฑ์ทางธุรกิจอย่างไร?

แทนที่จะคาดหวังว่า SME จะเรียนรู้ Java, C# หรือภาษาการเขียนโปรแกรมอื่น IT จะสร้างภาษาขนาดเล็กสำหรับเขาหรือเธอเพื่อแสดงกฎเกณฑ์ทางธุรกิจของตน พื้นฐานของกฎเหล่านี้จะประกอบด้วยข้อเท็จจริงที่สามารถสอบถามได้ ตัวอย่างข้อเท็จจริงบางส่วนตามอุตสาหกรรม/พื้นที่ปฏิบัติ ได้แก่

• ทรัพยากรบุคคล: เงินเดือน ตำแหน่ง ผู้จัดการ ปีกับบริษัท
• การแพทย์ : อุณหภูมิ ความดันโลหิต ยาที่ใช้อยู่ในปัจจุบัน
• การเงิน: ราคาหุ้นปัจจุบัน ราคาสูงสุด/ต่ำสุดในรอบ 52 สัปดาห์ อัตราส่วน P/E วันที่ประกาศผลประกอบการครั้งต่อไป

โดยพื้นฐานแล้ว ข้อมูลที่จำเป็นในการตัดสินใจทางธุรกิจจะต้องพร้อมสำหรับ SME อย่างคล่องตัว

กฎเหล่านี้มีลักษณะอย่างไร?

สำหรับส่วนที่เหลือของกวดวิชากลไกกฎนี้ ฉันจะใช้ Drools ซึ่งเป็นเอ็นจิ้นกฎแบบโอเพนซอร์สของ Java ซึ่งสามารถพบได้ที่ www.drools.org และเป็นโปรเจ็กต์ JBoss ใน Drools กฎจะถูกเขียนเป็นโค้ด Java และมีโครงสร้างดังต่อไปนี้:

คำสั่งการนำเข้าไปที่นี่:

 rule “Name of rule” when “The if” part of the business logic goes here. then The “then” part of the business logic goes here. end

Drools และหน่วยความจำในการทำงาน

Drools ใช้แนวคิดที่เรียกว่า Working Memory

รหัสแอปพลิเคชันจะรับผิดชอบในการโหลดข้อมูลที่เหมาะสมลงใน Working Memory เพื่อให้ SME สามารถเขียนกฎที่สืบค้นข้อเท็จจริงเหล่านี้ได้ ควรโหลดเฉพาะข้อเท็จจริงที่เกี่ยวข้องกับตรรกะทางธุรกิจของแอปพลิเคชันลงใน Working Memory เพื่อให้กลไกจัดการกฎทำงานด้วยความเร็วสูงสุด

ตัวอย่างเช่น หากใบสมัครกำลังกำหนดว่าจะอนุมัติสินเชื่อลูกค้าหรือไม่ ข้อเท็จจริงที่เกี่ยวข้องจะรวมถึงเงินเดือน คะแนนเครดิต และเงินให้สินเชื่อคงค้าง ข้อเท็จจริงที่ไม่เกี่ยวข้องจะรวมถึงวันในสัปดาห์หรือเพศ

การประเมินกฎเกณฑ์

หลังจากที่โหลดกฎและข้อเท็จจริงของ Drools Working Memory แล้ว กฎจะได้รับการประเมินตามส่วน "จากนั้น" ของกฎ หากส่วน "แล้ว" ประเมินว่าเป็นจริง ส่วน "เมื่อ" ของกฎจะถูกดำเนินการ

โดยปกติ กฎทั้งหมดจะได้รับการประเมินในครั้งเดียว แม้ว่ากฎสามารถจัดกลุ่มเข้าด้วยกันและประเมินตามแต่ละกลุ่มได้ ส่วน "แล้ว" ของกฎสามารถเปลี่ยนเนื้อหาของหน่วยความจำในการทำงานได้ เมื่อสิ่งนี้เกิดขึ้น Drools จะประเมินกฎทั้งหมดอีกครั้งเพื่อดูว่ากฎใด ๆ ประเมินว่าเป็นจริงหรือไม่ ถ้าเป็นเช่นนั้น ส่วน "เมื่อ" ของพวกเขาจะถูกดำเนินการ

ลักษณะการประเมินกฎแบบเรียกซ้ำนี้สามารถให้พรหรือคำสาปได้ ดังนั้นจึงต้องสร้างกฎโดยคำนึงถึงสถาปัตยกรรมนี้

กฎ "ถ้า" ของกฎ Drools

ใน Drools ข้อเท็จจริงจะแสดงด้วยวัตถุ สามารถสอบถามการมีอยู่หรือไม่มีอยู่ของประเภทวัตถุได้ นอกจากนี้ ยังสามารถสอบถามแอตทริบิวต์ของวัตถุได้เช่นกัน

นี่คือตัวอย่างบางส่วน:

ตรวจสอบว่าพนักงานมีรายได้มากกว่า 100,000 หรือไม่

 Employee(salary > 100000)

ตรวจสอบว่าผู้ป่วยมีระดับคอเลสเตอรอลมากกว่า 200 หรือไม่และกำลังรับประทาน Lipitor

 Patient(cholesterol > 200, medications.contains(“lipitor”))

ตรวจสอบว่าราคาหุ้นอยู่ในช่วง 1% ของราคาสูงสุดประจำปีหรือไม่

 Stock(price >= (yearHigh * .99))

รวมแบบสอบถาม

เมื่อเขียนตรรกะทางธุรกิจที่ซับซ้อน กฎทางธุรกิจสามารถรวมการสืบค้นโดยใช้ตัวดำเนินการบูลีน AND, OR และ NOT และซ้อนโดยใช้วงเล็บ

ตัวอย่างเช่น:

ตรวจสอบว่ามีผู้จัดการที่ทำรายได้น้อยกว่า $75,000 หรือกรรมการที่ทำรายได้น้อยกว่า $100,000 หรือไม่

 Employee(position.Equals(“Manager”),salary<75000) OR Employee(position.Equals(“Directory”),salary<100000)

การใช้อ็อบเจ็กต์หลายประเภท

ตัวอย่างทั้งหมดจนถึงตอนนี้อิงตามประเภทออบเจ็กต์เดียว เช่น พนักงานหรือผู้ป่วย อย่างไรก็ตาม Drools อนุญาตให้มีการสืบค้นตามวัตถุหลายประเภท

ตัวอย่างเช่น:

ตรวจสอบว่าลูกค้ามีเงินเดือนสูงกว่า 50,000 ดอลลาร์และไม่ได้ถูกฟ้องล้มละลายหรือไม่

 Customer(salary>50000) AND not exists Bankruptcy()

ด้าน "แล้ว" ของกฎ

ด้าน "แล้ว" ของกฎกำหนดสิ่งที่จะเกิดขึ้นเมื่อมีอย่างน้อยหนึ่งผลลัพธ์ในส่วน "เมื่อ" ของกฎ

ใน Drools สิ่งใดก็ตามที่สามารถเขียนด้วย Java สามารถเขียนได้ในส่วน "แล้ว" ของกฎ อย่างไรก็ตาม ในการทำให้กฎนำมาใช้ใหม่ได้มากขึ้น โดยทั่วไปแล้วไม่ควรวาง I/O, รหัสควบคุมโฟลว์ หรือโค้ดการดำเนินการทั่วไปภายในกฎ

คุณสามารถใช้ส่วน "แล้ว" ของกฎเพื่อแก้ไขหน่วยความจำในการทำงานได้ แนวทางปฏิบัติทั่วไปคือการแทรกข้อเท็จจริงลงใน Working Memory เมื่อกฎถูกประเมินว่าเป็นจริง

ตัวอย่างเช่น:

 rule “LoanApproved” when Customer(credit>700) && not exist LoanOutstanding() then insert(new LoanApproval()) end

เราจะรู้ได้อย่างไรว่ากฎใดถูกประเมินว่าเป็นความจริง

หลังจากที่กฎทั้งหมดเริ่มทำงานแล้ว แอปพลิเคชันจำเป็นต้องรู้ว่ากฎใดที่ประเมินว่าเป็นจริง ถ้ากฎแทรกอ็อบเจ็กต์ลงใน Working Memory เมื่อประเมินค่า true ก็สามารถเขียนโค้ดเพื่อสอบถาม Working Memory สำหรับอ็อบเจ็กต์เหล่านั้นได้

ในตัวอย่างข้างต้น หลังจากที่กฎทั้งหมดถูกไล่ออก สามารถทำแบบสอบถามเพื่อดูว่าอ็อบเจ็กต์ LoanApproval() อยู่ใน Working Memory หรือไม่

 query "GetLoanApproval " $result: LoanApproval() end

Business Rules Engine โต้ตอบกับแอปพลิเคชันอย่างไร

แอปพลิเคชันทั่วไปประกอบด้วยตรรกะทางธุรกิจ GUI I/O และโฟลว์ของโค้ดควบคุม

ตัวอย่างเช่น แอปพลิเคชันอาจประมวลผลคำขอของผู้ใช้ดังนี้:

 GUI ? Flow Control ? I/O ? Business Logic ? I/O ? Flow Control ? GUI

การฝังกลไกจัดการกฎจะเพิ่มขั้นตอนสองสามขั้นตอนให้กับกระบวนการนี้:

 GUI ? Flow Control ? I/O ? Create Rules Engine Session ? Add Facts to Working Memory ? Fire Rules ? Determine which rules have evaluated true ? I/O ? Flow Control ? GUI

SMEs ทำงานกับกฎอย่างไร

การสร้าง แก้ไข และลบกฎ

เพื่อให้ SMEs ทำงานกับกฎเกณฑ์ได้ พวกเขาจำเป็นต้องมี GUI ที่ใช้งานง่าย เครื่องมือกฎธุรกิจบางอย่างมาพร้อมกับอินเทอร์เฟซดังกล่าว

ตัวอย่างเช่น Drools มาพร้อมกับ GUI สองตัวที่ฉันพบว่าใช้งานง่าย ส่วนแรกคล้ายกับสเปรดชีตและอนุญาตให้ SMEs สร้างกฎโดยไม่ต้องเขียนโค้ดใดๆ จริง GUI ที่สองช่วยให้สามารถสร้างตรรกะทางธุรกิจที่ซับซ้อนมากขึ้นได้

แม้ว่า GUI ทั้งสองนี้จะมีประโยชน์สำหรับการป้อนเงื่อนไขง่ายๆ แต่จะใช้งานไม่ได้เนื่องจากตรรกะทางธุรกิจมีความซับซ้อนมากขึ้น ในกรณีนี้ คุณจะต้องสร้าง GUI ที่กำหนดเอง

องค์ประกอบของ SME Custom GUI

เพื่อให้ SMEs ทำงานได้อย่างมีประสิทธิภาพ ให้พิจารณาสร้าง GUI แบบกำหนดเองที่มีความสามารถดังต่อไปนี้:

• ตัวตรวจสอบไวยากรณ์ – ปุ่ม "ตรวจสอบไวยากรณ์" สามารถเรียกรหัส Drools เพื่อตรวจสอบข้อผิดพลาดที่เป็นไปได้และหมายเลขบรรทัด
• ลาก/วาง – แทนที่จะต้องการให้ SME จำอ็อบเจ็กต์และแอตทริบิวต์ที่มีให้ ให้พิจารณาเสนอรายการเลือกที่พวกเขาสามารถลากและวางได้
• เว็บอินเทอร์เฟซ – อินเทอร์เฟซไคลเอ็นต์แบบบางจะพร้อมใช้งานสำหรับ SMEs โดยไม่ต้องกังวลเรื่องการกระจาย สิ่งนี้จะมีประโยชน์เนื่องจาก GUI ต้องการคุณสมบัติเพิ่มเติมและการบำรุงรักษาทั่วไป
• ผู้ทดสอบกฎ – ความสามารถในการทดสอบกฎแต่ละข้อโดยไม่ต้องเชื่อมต่อกับแอปพลิเคชันทั้งหมด จะช่วยเพิ่มประสิทธิภาพการทำงานของ SME ได้อย่างมาก อนุญาตให้ SME GUI กำหนดข้อเท็จจริงแล้วเริ่มกฎแต่ละข้อ

กฎควรเก็บไว้ที่ไหน?

ใน Drools โดยปกติแล้วจะมีสองวิธีในการจัดเก็บกฎ Drools ทำงานนอกกรอบด้วยกฎแบบไฟล์ที่มักจะมีนามสกุล .drl

วิธีนี้ใช้ได้ผลดีเมื่อกฎมีน้อย เมื่อจำนวนกฎเพิ่มขึ้น คุณจะต้องการใช้ฐานข้อมูล การจัดเก็บและเรียกกฎจากฐานข้อมูลต้องมีการทำงานมากขึ้น แต่ควรให้สถาปัตยกรรมที่จัดการได้มากขึ้น

บทช่วยสอนเกี่ยวกับกลไกจัดการกฎนี้ได้กล่าวถึงส่วนเล็กๆ ของภาษากฎของ Drols เท่านั้น สำหรับคำอธิบายโดยละเอียด โปรดดูที่เอกสารอ้างอิงอย่างเป็นทางการ

การตัดสินใจใช้กลไกจัดการกฎไม่ควรเป็นเรื่องเล็กน้อย ในขณะที่กลไกจัดการกฎจะทำให้ SME ขยายแอปพลิเคชันของคุณได้มากขึ้น แต่การพัฒนา ทดสอบ และปรับใช้จะซับซ้อนยิ่งขึ้นด้วย สำหรับข้อควรพิจารณาเพิ่มเติมในหัวข้อนี้ คุณอาจต้องการทบทวนหลักเกณฑ์ต่อไปนี้

ตอนนี้ เราสามารถแสดงให้คุณเห็นสิ่งที่น่าสนใจกว่านี้ได้อีกเล็กน้อย ซึ่งเป็นตัวอย่างง่ายๆ ในชีวิตจริงของการใช้งาน Drols ในกรณีการใช้งานที่ผู้อ่านบล็อก Toptal ส่วนใหญ่น่าจะคุ้นเคย

การใช้ Drools ในสถานการณ์จริง

Toptal ผู้ให้บริการชั้นนำด้านการพัฒนาซอฟต์แวร์ระดับสูง ปัจจุบันใช้ซอฟต์แวร์ Applicant Tracking เพื่อนำผู้สมัครผ่านขั้นตอนต่างๆ ในกระบวนการจ้างงาน นี่คือโฟลว์ชาร์ตภาพแบบง่ายของกระบวนการนี้:

ในปัจจุบัน ตรรกะทางธุรกิจในการตัดสินใจว่าผู้สมัครจะดำเนินการในกระบวนการจ้างงานต่อไปหรือไม่ได้ถูกฮาร์ดโค้ดลงในซอฟต์แวร์แล้ว ทุกครั้งที่ฝ่ายทรัพยากรบุคคลจำเป็นต้องเปลี่ยนตรรกะทางธุรกิจ พวกเขาต้องมีส่วนเกี่ยวข้องกับไอที พวกเขาต้องการมีความสามารถในการเปลี่ยนแปลงวิธีการทำงานของซอฟต์แวร์โดยตรง

ซอฟต์แวร์ติดตามผู้สมัครจะถูกแก้ไขเพื่อเรียกใช้กฎที่ฝ่ายบุคคลให้มา ณ จุดตัดสินใจแต่ละจุดในกระบวนการจ้างงาน ฝ่ายทรัพยากรบุคคลจะมีออบเจ็กต์ 'ผู้สมัคร' ที่จะเป็นตัวแทนของผู้สมัครงานที่มีสถานะเพิ่งได้รับการแก้ไขโดยการป้อนครั้งแรก การสอบออนไลน์เสร็จสิ้น หรือปัจจัยต่างๆ หลายประการ วัตถุผู้สมัครจะมีช่องสำหรับแสดงประสบการณ์ คะแนนสอบ คะแนนสัมภาษณ์ ฯลฯ

ตัวอย่างต่อไปนี้นำเสนอชุดกฎแบบง่ายเพื่อให้คุณพิจารณา ยังไม่ได้ปรับใช้ เป็นเพียงตัวอย่างง่ายๆ ที่ประกอบด้วยกฎที่เชื่อมต่อถึงกันสี่กฎ:

• ส่งแล้ว -> การทดสอบ
• การทดสอบ -> สัมภาษณ์
• สัมภาษณ์ -> โครงการ
• โครงการ -> การว่าจ้าง

ส่งแล้ว -> การทดสอบ

ตามความต้องการของลูกค้าในปัจจุบัน ฝ่ายทรัพยากรบุคคลต้องการเขียนกฎที่จะกำหนดว่าผู้สมัครควรได้รับการกำหนดเวลาสำหรับการทดสอบออนไลน์หรือไม่

 Rule “Schedule For Testing” when $candidate: Candidate(status=='Submitted',yrsExperience >= 10, skill(name=='Java', yrsExperience>=5) or Skill(name=='C#', yrsExperience>=5)) then $candidate.setStatus('Testing'); end

การทดสอบ -> สัมภาษณ์

หลังจากที่ผู้สมัครสอบออนไลน์แล้ว คะแนนของพวกเขาจะต้องได้รับการประเมิน ฝ่ายทรัพยากรบุคคลต้องการควบคุมกฎนี้ด้วย ข้อสอบออนไลน์จะทดสอบความสามารถของผู้สมัครในการทำความเข้าใจทฤษฎีการพัฒนาซอฟต์แวร์ การแก้ปัญหา และไวยากรณ์ ฝ่ายทรัพยากรบุคคลต้องการตัดสินใจว่าคะแนนรวมใดบ้างที่จะช่วยให้ผู้สมัครได้รับการพิจารณาสำหรับการสัมภาษณ์ทางเทคนิค

 Rule “Schedule For Interview” when $candidate: Candidate(status=='Testing', testScore(theory>.8 && syntax>.6 && problemSolving>.8); then $candidate.setStatus('Interview'); end

สัมภาษณ์ -> โครงการ

การสัมภาษณ์ทางเทคนิคจะทดสอบความสามารถของผู้สมัครในการพูดเกี่ยวกับประสบการณ์ของตน ตอบคำถามในการแก้ปัญหา และจะทดสอบความสามารถในการสื่อสารโดยทั่วไป ฝ่ายทรัพยากรบุคคลจะเขียนกฎที่กำหนดคะแนนผ่านสำหรับการสัมภาษณ์ทางเทคนิค

 Rule “Schedule For Project” when $candidate: Candidate(status=='Interview', interviewScore(speakExperience>.9 && problemSolving>.8 && communication>.9 ); then $candidate.setStatus('Project'); end

โครงการ -> การว่าจ้าง

หากผู้สมัครผ่านการสัมภาษณ์ด้านเทคนิค จะได้รับโครงการเขียนโปรแกรมออฟไลน์ พวกเขาจะยื่นโครงการและจะพิจารณาความสมบูรณ์ สถาปัตยกรรม และ GUI

 Rule “Schedule For Hiring” when $candidate: Candidate(status=='Project', projectScore(completeness>.8 && architecture>.9 && gui>.7 ); then $candidate.setStatus('Hiring'); end

อย่างที่คุณเห็น แม้แต่ตัวอย่างพื้นฐานนี้ยังมีความเป็นไปได้มากมายสำหรับ HR และสามารถปรับปรุงการดำเนินงานได้ การที่ฝ่ายทรัพยากรบุคคลสามารถเปลี่ยนแปลงกฎเกณฑ์โดยไม่ต้องให้ฝ่ายไอทีเข้าไปเกี่ยวข้องในกระบวนการนี้ จะช่วยประหยัดเวลาและเร่งกระบวนการคัดกรองอย่างหลีกเลี่ยงไม่ได้

เนื่องจากกฎสามารถเปลี่ยนแปลงได้ทันที ฝ่ายทรัพยากรบุคคลก็จะมีความยืดหยุ่นมากขึ้นเช่นกัน ตัวอย่างเช่น HR สามารถขยายหรือจำกัดกระบวนการคัดเลือกโดยการตั้งค่าพารามิเตอร์ต่างๆ

หากมีผู้สมัครจำนวนมากเกินไปที่ทำเครื่องหมายในช่องที่ถูกต้องทั้งหมด แถบอาจเพิ่มขึ้นในไม่กี่นาที ซึ่งจะเป็นการลดจำนวนผู้สมัคร อีกทางหนึ่ง หากกระบวนการทำให้มีผู้สมัครน้อยหรือไม่มีเลยที่ตรงตามข้อกำหนดทั้งหมด ฝ่ายทรัพยากรบุคคลสามารถเลือกที่จะลดหรือลดมาตรฐานบางส่วน โดยเปลี่ยนโฟกัสไปที่ทักษะที่เกี่ยวข้องมากขึ้น จนกว่าผู้สมัครจะมีคุณสมบัติตรงตามข้อกำหนดจำนวนเพียงพอ