สถาปัตยกรรมระบบอัตโนมัติในการจัดซื้อจัดจ้าง

การทำระบบจัดซื้อจัดจ้างให้เป็นอัตโนมัติอย่างแท้จริงหมายถึงอะไร

"ระบบอัตโนมัติในการจัดซื้อจัดจ้าง" ครอบคลุมแนวทางหลากหลายรูปแบบ ตั้งแต่วิธีอัตโนมัติผ่านเวิร์กโฟลว์ตามกฎ ซึ่งส่งคำขอซื้อผ่านสายการอนุมัติที่กำหนดไว้ ไปจนถึงระบบอัตโนมัติด้วยกระบวนการทางหุ่นยนต์ (RPA) ที่ใช้งานหน้าจอเดิมในลักษณะเดียวกับที่มนุษย์ทำ ไปจนถึงระบบอัตโนมัติอัจฉริยะที่เพิ่มความเข้าใจในเอกสารหรือตรรกะการจับคู่ซ้อนทับเข้าไป งานวิจัยที่ได้รับการตรวจสอบโดยผู้ทรงคุณวุฒิระบุว่า RPA คือ การใช้โปรแกรมซอฟต์แวร์แบบโลว์โค้ดเพื่อทำให้กระบวนการทางธุรกิจที่ทำซ้ำๆ และเป็นกิจวัตรกลายเป็นระบบอัตโนมัติ และเรียกสิ่งนี้ว่าเป็นเทคโนโลยีที่มีการเติบโตเร็วที่สุดในหมวดหมู่ซอฟต์แวร์สำหรับองค์กร. ไม่มีวิธีใดที่สามารถแทนที่กระบวนการจัดซื้อจนถึงชำระเงินได้ แต่จะแทรกอยู่ภายในกระบวนการเหล่านั้น โดยแต่ละวิธีจะเข้ามาดูแลขั้นตอนเฉพาะที่กำหนดไว้อย่างชัดเจน นั่นคือเหตุผลว่าทำไมคำถามที่มีประโยชน์จึงเป็นเรื่องของขั้นตอนใดใน สถาปัตยกรรมจัดซื้อจนถึงจ่ายเงิน (procure-to-pay) มีความเป็นกิจวัตรมากพอที่จะมอบหมายให้ซอฟต์แวร์จัดการ และส่วนใดที่ยังคงต้องอาศัยการพิจารณาตัดสินของมนุษย์

ขั้นตอนเวิร์กโฟลว์ใดควรได้รับการ automat ก่อน และเพราะเหตุใด

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

เส้นทางอัตโนมัติต้องรักษาการควบคุมใดไว้บ้าง

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

คุณจะลำดับขั้นตอนการเปิดใช้งานที่ยึดหลักการกำกับดูแลเป็นอันดับแรกอย่างไร?

การบูรณาการระบบ ERP แบบเดิมมักล้มเหลวที่จุดใด และไซโลข้อมูลเกิดขึ้นจากที่ใด

จุดที่แพลตฟอร์มการจัดซื้ออัตโนมัติเชื่อมต่อกับ ERP คือจุดที่ความเสี่ยงด้านการกำกับดูแลมารวมตัวกันในทางปฏิบัติ และยังเป็นจุดที่เกิดไซโลของข้อมูลขึ้น หากระบบอัตโนมัตินั้นเก็บสำเนาข้อมูลผู้ขาย งบประมาณ หรือการอนุมัติแยกต่างหากของตนเอง แทนที่จะถือว่า ERP เป็นระบบบันทึกข้อมูลหลักเพียงระบบเดียว คู่มือการ 통합 (integration) ของผู้ให้บริการระบบอัตโนมัติรายหนึ่งได้ระบุถึงความเสี่ยงด้านการเข้าถึงไว้อย่างชัดเจนว่า: ตัวเชื่อมต่อ (Connector) ที่ได้รับสิทธิ์เข้าถึงกว้างเกินกว่าที่ฟังก์ชันการทำงานต้องการ จะสามารถอ่านข้อมูลที่ไม่ควรเห็นและเขียนทับฟิลด์ที่ไม่ควรแตะต้องได้. มักจะมีการให้สิทธิ์การเข้าถึงแบบกว้างเพื่อความสะดวกในการตั้งค่า ไม่ใช่เพราะเวิร์กโฟลว์จำเป็นต้องใช้ และควรค่าแก่การถือเป็นรายการตรวจสอบที่ได้รับจากผู้   vendor สำหรับนำไปทดสอบ มากกว่าที่จะเป็นเพียงคำกล่าวอ้างเกี่ยวกับผลิตภัณฑ์ของ vendor รายใดรายหนึ่ง คู่มือฉบับเดียวกันนี้ยังได้ระบุถึงจุดที่เกิดความล้มเหลวรูปแบบที่สองซึ่งเงียบเชียบกว่าด้วย: บันทึกการตรวจสอบที่ครอบคลุมการกระทำของมนุษย์แต่ไม่บันทึกการตัดสินใจอัตโนมัติถือว่าไม่สมบูรณ์และจะก่อให้เกิดข้อพบเจอในการตรวจสอบบัญชีที่จริงจังทุกครั้งหากบอทเป็นผู้อنุมัติใบแจ้งหนี้ การตัดสินใจนั้นจำเป็นต้องมีบันทึกเช่นเดียวกับการอนุมัติโดยบุคคล ได้แก่: ใช้ตรรกะใดในการอนุมัติ, ใช้ข้อมูลใดบ้าง, และผลลัพธ์คืออะไร

ทำไมระบบอัตโนมัติที่ยังไม่ได้ตรวจสอบจึงมีต้นทุนสูงกว่าเงินที่ประหยัดได้?

ความท้าทายคือการมองว่าระบบอัตโนมัติเป็นเพียงปัญหาในการปรับใช้: กำหนดค่าเครื่องมือ เชื่อมโยงเข้ากับกระบวนการ แล้วใช้งานจริง งานวิจัยพื้นฐานเกี่ยวกับการตรวจสอบเวิร์กอัปเตือนให้หลีกเลี่ยงการข้ามขั้นตอนตรงกลาง จากการศึกษาเกี่ยวกับระบบการจัดการเวิร์กโฟลว์โดยทั่วไป นักวิจัยพบว่า ผลลัพธ์ที่ตามมาคือมีเวิร์กโฟลว์เพียงส่วนน้อยเท่านั้นที่ได้รับการตรวจสอบอย่างละเอียดก่อนนำไปใช้งานจริง ซึ่งมักส่งผลให้ต้องแก้ไขข้อผิดพลาดเฉพาะหน้าโดยมักจะมีค่าใช้จ่ายที่สูงเกินควรการค้นพบนั้นเกิดขึ้นก่อนแพลตฟอร์มระบบอัตโนมัติแบบ low-code ในปัจจุบันถึงสองทศวรรษ และปัญหาที่อยู่เบื้องหลังก็ยังคงอยู่: ข้อกำหนดของเวิร์กโฟลว์คือชุดของตรรกะ และตรรกะที่ไม่ได้รับการตรวจสอบทางเลือก ลำดับ และข้อยกเว้นที่จำเป็นต้องจัดการจริงๆ ย่อมล้มเหลวในลักษณะเดียวกัน ไม่ว่ามนุษย์หรือบอตจะเป็นผู้ดำเนินการก็ตาม ยกเว้นแต่ว่าบอตจะล้มเหลวเร็วกว่าและมีปริมาณมากกว่า ภาษาข้อกำหนดเวิร์กโฟลว์จำเป็นต้องรองรับการกำหนดจุดที่ต้องตัดสินใจ การทำงานตามลำดับ การทำงานแบบขนาน การซิงโครไนซ์ และการวนซ้ำ ก็เพราะว่ากระบวนการจริงจำเป็นต้องใช้สิ่งเหล่านี้ทั้งหมด และการทดลองระบบที่ทำงานเฉพาะเส้นทางที่ราบรื่น (happy path) นั้นไม่ได้เป็นการตรวจสอบเวิร์กโฟลว์เลยแม้แต่น้อย