การกำหนดเส้นทางตามเกณฑ์สำหรับกฎการอนุมัติที่ยืดหยุ่น

ทำไมกฎอนุมัติที่ฝังไว้ในโค้ดจึงล้มเหลว

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

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

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

ข้อยกเว้นที่ซ่อนอยู่ทำให้แย่ลง เมื่อเวลาผ่านไป ทีมมักเพิ่มกฎครั้งเดียวเช่น "ถ้า จำนวน มากกว่า 5,000 และแผนกเป็น Sales ให้ส่งไปยัง Director A" หรือ "ถ้าคำขอจากยุโรป ให้ข้ามขั้นตอนนี้" เมื่อกฎเหล่านั้นอยู่ลึกในเวิร์กโฟลว์ มีเพียงไม่กี่คนเท่านั้นที่เห็นมัน

คำถามง่าย ๆ ก็กลายเป็นยากที่จะตอบ:

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

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

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

ลองนึกถึงนโยบายค่าใช้จ่ายง่าย ๆ คำขอที่ต่ำกว่า $1,000 ไปยังหัวหน้าทีม คำขอ $1,000 ถึง $10,000 ไปยังหัวหน้าแผนก และมากกว่านั้นไปยังฝ่ายการเงิน ถ้าขอบเขตเหล่านั้นเปลี่ยนในเดือนหน้า ธุรกิจไม่ควรต้องการนักพัฒนาเพียงเพื่อทำให้การอนุมัติเดินหน้าต่อไป

การฝังกฎไว้ในโค้ดทำให้การอัปเดตนโยบายธรรมดากลายเป็นโครงการซอฟต์แวร์ ซึ่งเป็นต้นทุนที่แท้จริง

ความหมายของการกำหนดเส้นทางตามเกณฑ์

การกำหนดเส้นทางตามเกณฑ์หมายความว่าเส้นทางการอนุมัติเปลี่ยนแปลงตามค่าที่คุณกำหนดไว้ล่วงหน้า เกณฑ์คือขอบเขต เช่น จำนวนมากกว่า $1,000 คำขอจากแผนกการเงิน หรือการซื้อที่เกิดขึ้นในยุโรป

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

การตั้งค่าพื้นฐานอาจหน้าตาแบบนี้:

• คำขอที่ต่ำกว่า $500 ไปยังหัวหน้าทีม
• คำขอ $500 ถึง $5,000 ไปยังผู้จัดการแผนก
• คำขอที่มากกว่า $5,000 ไปยังผู้อำนวยการ
• คำขอของ HR เดินตามเส้นทางหนึ่ง ขณะที่คำขอ IT เดินอีกเส้นทาง
• North America และ EMEA อาจมีกำหนดผู้อนุมัติที่ต่างกัน

กระบวนการยังคงเหมือนเดิม แต่ค่าที่ควบคุมมันสามารถเปลี่ยนได้

แยกตรรกะออกจากนโยบาย

นี่คือแนวคิดสำคัญ ตรรกะคือส่วนที่บอกว่า "ตรวจสอบกฎและเลือกการจับคู่แรก" ข้อมูลนโยบายคือรายการกฎเอง: ช่วงจำนวน แผนก ภูมิภาค ผู้อนุมัติ และลำดับความสำคัญ

เมื่อผสมตรรกะและนโยยบาลเข้าด้วยกัน แม้แต่การเปลี่ยนแปลงเล็กน้อยก็อาจต้องนักพัฒนาแก้ไขเวิร์กโฟลว์ เมื่อแยกกัน เวิร์กโฟลว์คงที่และมีเพียงแถวกฎที่เปลี่ยนแปลง

ตัวอย่างเช่น หาก Sales ใน APAC ต้องการการอนุมัติของผู้อำนวยการเมื่อมากกว่า $3,000 แทน $5,000 คุณแค่แก้ไขแถวเดียวในตาราง ไม่ต้องสร้างกระบวนการใหม่ทั้งหมด

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

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

สิ่งที่ควรใส่ในตารางกฎของคุณ

ตารางกฎที่ดีควรตอบคำถามง่าย ๆ ว่า: เมื่อคำขอตรงกับเงื่อนไขเหล่านี้ ใครต้องอนุมัติ?

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

ตารางกฎที่ใช้งานได้จริงมักเริ่มจากฟิลด์ที่อธิบายคำขอ:

• amount
• currency
• department
• region
• request type
• approver role

จำนวนและสกุลเงินสำคัญเพราะตัวเลขเดียวกันอาจหมายถึงสิ่งต่างกันในงบประมาณหรือประเทศต่าง ๆ คำขอ 5,000 USD อาจเดินตามเส้นทางหนึ่ง ขณะที่ 5,000 EUR หรือ 500,000 JPY อาจต้องเส้นทางอื่น

แผนกและภูมิภาคสะท้อนการทำงานจริงของบริษัท Finance HR และ Operations มักมีเส้นทางอนุมัติแตกต่างกัน แม้จะเป็นค่าใช้จ่ายเท่ากัน ภูมิภาคก็สำคัญเมื่อมีกฎท้องถิ่นหรือผู้จัดการต่างกัน

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

สำหรับผู้อนุมัติ ให้เก็บเป็นบทบาทแทนชื่อบุคคล เช่น Department Manager, Regional Director, หรือ Finance Controller เมื่อมีคนเปลี่ยนตำแหน่ง คุณอัปเดตการมอบหมายบทบาทครั้งเดียวแทนการแก้ไขทุกกฎ

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

ฟิลด์ลำดับความสำคัญก็ควรมี กฎเช่น "EU + Finance + over 10,000" ควรชนะเหนือกฎกว้าง ๆ อย่าง "all departments + over 10,000" ลำดับความสำคัญที่ชัดเจนทำให้การกำหนดเส้นทางคาดเดาได้

วิธีจัดโครงสร้างตาราง

ทำให้โครงสร้างเรียบง่าย: หนึ่งแถวเท่ากับกฎอนุมัติหนึ่งข้อ

ถ้าค่าใช้จ่ายการตลาดที่เกิน $2,000 ในยุโรปต้องการผู้จัดการภูมิภาค นั่นควรอยู่ในเรคคอร์ดเดียว เมื่อแต่ละแถวมีความหมายชัดเจน การตั้งค่าจะง่ายต่อการอัปเดต ทดสอบ และตรวจสอบ

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

รูปแบบที่ใช้งานได้จริง

ตารางสะอาด ๆ มักรวมฟิลด์เหล่านี้:

• rule ID หรือชื่อกฎ
• สถานะการใช้งาน พร้อมวันที่เริ่มและสิ้นสุดแบบออปชัน
• คอลัมน์เงื่อนไข เช่น จำนวนขั้นต่ำ จำนวนสูงสุด แผนก ภูมิภาค และประเภทคำขอ
• คอลัมน์ผลลัพธ์ เช่น บทบาทผู้อนุมัติ ผู้ใช้ผู้อนุมัติ หรือลำดับถัดไป
• ลำดับความสำคัญและแฟลกกฎเริ่มต้น

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

สำหรับคอลัมน์ผลลัพธ์ ให้ตัดสินใจว่าเวิร์กโฟลว์ควรคืนค่าอะไร บางทีมให้กฎชี้ไปยังบุคคลเฉพาะ ในขณะที่ทีมอื่นให้ไปยังบทบาท เช่น Regional Manager หรือ Finance Director เลือกแนวทางหนึ่งและยึดตามมัน

ลำดับความสำคัญสำคัญเพราะอาจมีมากกว่าหนึ่งกฎที่ตรงกับคำขอ อย่าอาศัยลำดับแถวหรือวันที่สร้าง เพิ่มฟิลด์ลำดับความสำคัญเชิงตัวเลขและกำหนดวิธีการทำงาน เช่น 1 ตรวจสอบก่อน และ 100 ตรวจสอบทีหลัง

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

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

วิธีตั้งค่ามัน

เริ่มจากการตัดสินใจ ไม่ใช่จากตาราง เขียนคำถามที่เวิร์กโฟลว์ต้องตอบให้ชัด คำซื้อที่มากกว่า $5,000 ต้องการผู้จัดการไหม? ฝ่ายการเงินตรวจสอบทุกอย่างจาก Sales หรือไม่? คำขอจากภูมิภาคหนึ่งเดินตามเส้นทางต่างออกไปหรือไม่?

เมื่อคำเลือกเหล่านั้นชัด การกำหนดเส้นทางตามเกณฑ์จะง่ายขึ้นเพราะคุณกำลังเก็บนโยบายแทนการคาดเดาตรรกะทีหลัง

การตั้งค่าที่เรียบง่ายมักมีห้าขั้นตอน

อันดับแรก สร้างตารางกฎการอนุมัติด้วยฟิลด์ที่มีผลต่อการกำหนดเส้นทาง คอลัมน์ทั่วไปได้แก่ amount_min, amount_max, department, region, approver_role, priority, และ active_status

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

อันดับสาม เพิ่มกฎจากเฉพาะไปหากว้าง กฎเช่น "Sales + Europe + over $10,000" ควรตรวจสอบก่อนกฎกว้าง ๆ เช่น "any department + any region + over $10,000"

อันดับสี่ ทดสอบด้วยตัวอย่างจริงก่อนเปิดใช้งาน ใช้กรณีขอบเช่น $5,000 พอดี ข้อมูลแผนกหาย หรือภูมิภาคที่ไม่มีการกำหนดกฎเฉพาะ

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

นี่คือตัวอย่างง่าย ๆ คำขอ $12,000 จาก HR ใน North America อาจตรงกับกฎสำหรับ "HR over $10,000" ซึ่งส่งไปยังผู้อำนวยการ HR หากไม่มีการกำหนดกฎเฉพาะของ HR ระบบสามารถย้อนกลับไปยังกฎกว้างกว่าเช่น "any department over $10,000" ซึ่งส่งไปยังฝ่ายการเงิน

ลำดับมีความสำคัญมากกว่าที่หลายทีมคาด หากกฎกว้างอยู่เหนือกฎเฉพาะ คนผิดจะได้รับคำขอและผู้คนจะเลิกเชื่อถือระบบ

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

ตัวอย่างง่าย ๆ ในการใช้งานจริง

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

สมมติว่าบริษัทมีสองแผนกคือ Marketing และ IT ทั้งคู่สามารถส่งคำขอ $4,000 ได้ แต่เส้นทางอนุมัติไม่จำเป็นต้องเหมือนกัน

ตอนนี้เปรียบเทียบคำขอสองรายการที่มีจำนวนเท่ากัน คำขอของ Marketing จำนวน $4,000 ในสหรัฐไปยัง Marketing Manager ส่วนคำขอ IT จำนวน $4,000 ในสหรัฐข้าม IT Manager ไปยัง CTO เพราะ IT กำหนดเกณฑ์ต่ำกว่า

ภูมิภาคยังเปลี่ยนผลลัพธ์ได้ด้วย คำขอ Marketing $2,500 ในสหรัฐจะไปยัง Marketing Manager แต่คำขอเดียวกันใน EU จะไปยัง Regional Marketing Lead ฟอร์มยังคงเหมือนเดิม มีเพียงกฎที่จับคู่เท่านั้นที่เปลี่ยนไป

นั่นคือคุณค่าจริงของตารางกฎ นโยบายอยู่ในข้อมูล ไม่ใช่ในตรรกะเวิร์กโฟลว์

ถ้าบริษัทอัปเดตนโยบายในเดือนหน้า คุณไม่ต้องสร้างกระบวนการใหม่ทั้งหมด ถ้า IT ตัดสินใจว่าคำขอที่เกิน $2,000 ควรไปยัง CTO ตอนนี้ คุณแก้ไขเพียงแถวเดียว:

• กฎเก่า: IT, US, $3,001+, CTO
• กฎใหม่: IT, US, $2,001+, CTO

ทุกอย่างอื่นยังทำงานต่อไป คำขอใหม่จะปฏิบัติตามนโยบายใหม่ทันทีในขณะที่โครงสร้างแอปยังไม่เปลี่ยนแปลง

ความผิดพลาดที่พบบ่อยให้หลีกเลี่ยง

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

ข้อผิดพลาดที่พบบ่อยคือกฎที่ทับซ้อนกันโดยไม่มีลำดับความสำคัญชัดเจน คุณอาจมีกฎที่ส่งคำขอ Marketing ที่เกิน $3,000 ไปยังหัวหน้าแผนก และอีกกฎที่ส่งคำขอใด ๆ ที่เกิน $5,000 ไปยังฝ่ายการเงิน คำขอ Marketing $6,000 ตรงกับทั้งคู่ ระบบจึงต้องการผู้ชนะที่ชัดเจน ใส่ลำดับความสำคัญในตารางกฎ ไม่ใช่ในตรรกะเวิร์กโฟลว์ที่ซ่อนอยู่

อีกข้อผิดพลาดคือการ hard-code ชื่อบุคคลแทนบทบาทหรือกลุ่ม ชื่อเปลี่ยน ทีมเปลี่ยน ใครบางคนลาหรือย้ายแผนก ถ้ากฎเขียนว่า "ส่งไป Maria Lopez" คุณจะต้องแก้ไขทุกครั้งที่บุคลากรเปลี่ยน มันปลอดภัยกว่าที่จะส่งไปยังบทบาทเช่น Regional Finance Manager หรือ Sales Director แล้วแมปบทบาทนั้นไปยังคนปัจจุบัน

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

ข้อยกเว้นตามภูมิภาคเป็นจุดอ่อนอีกจุด หนึ่งนโยบายที่ใช้ได้ในประเทศหนึ่งอาจใช้ไม่ได้ในอีกที่เพราะขอบเขตการใช้จ่ายท้องถิ่น กฎภาษี หรือความต้องการการรายงาน ถ้าคุณทดสอบเพียงภูมิภาคเดียว คุณอาจพลาดกรณีที่ EU US หรือ APAC ควรเดินตามเส้นทางต่างกัน

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

การตรวจสอบขั้นสุดท้ายก่อนเปิดใช้งาน

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

เก็บการทบทวนขั้นสุดท้ายให้ง่าย

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

ตรวจสอบว่ามีกฎ fallback อยู่ ขาดแผนก ภูมิภาคใหม่ หรือจำนวนที่ผิดปกติยังควรไปยังที่ปลอดภัยได้

ยืนยันว่าการอัปเดตนโยบายทำได้โดยไม่ต้องพึ่งนักพัฒนา หากฝ่ายการเงินหรือปฏิบัติการต้องเปลี่ยนขีดจำกัด วันที่ หรือผู้อนุมัติ พวกเขาควรแก้ไขเรคคอร์ดในตารางผ่านหน้าจอแอดมิน แทนการขอให้ทีมพัฒนาทำการเปลี่ยนโค้ด

ทดสอบวันที่ ไม่ใช่แค่ค่า นโยบายเมื่อวานและนโยบายเดือนหน้าควรทำงานตามที่คาดเมื่อวันที่มีผลถูกตั้งค่า

เขียนตรรกะการกำหนดเส้นทางให้อยู่บนหน้ากระดาษเดียวด้วยภาษาง่าย ๆ หากผู้จัดการอธิบายไม่ได้อย่างชัดเจน แสดงว่าอาจซับซ้อนเกินไป

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

ขั้นตอนถัดไป

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

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

การเปิดตัวครั้งแรกควรตอบคำถามพื้นฐานสี่ข้อ:

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

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

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

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

หากคุณต้องการสร้างแบบเห็นภาพ AppMaster เหมาะสำหรับการสร้างตารางกฎ กระบวนการกำหนดเส้นทาง และหน้าจอแอดมินที่ให้พนักงานที่ไม่ใช่เทคนิคอัปเดตนโยบายโดยตรงแทนการส่งการเปลี่ยนทุกครั้งกลับไปหานักพัฒนา

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