ระบบคำขอซื้อภายใน: หลีกเลี่ยงคอขวด

ทำไมคำขอซื้อจึงติดค้าง

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

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

รายละเอียดที่ขาดทำให้ล่าช้า

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

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

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

ระเบียนเดียวและความรับผิดชอบที่ชัดเจน

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

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

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

กำหนดข้อมูลที่คำขอแต่ละรายการควรมี

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

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

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

ใช้แบบฟอร์มคำขอสองประเภท

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

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

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

ให้ช่องบังคับกรอกมีเหตุผล

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

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

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

สร้างแคตตาล็อกเพื่อเร่งการส่งคำขอ

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

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

ตัวอย่างเช่น รายการ «แล็ปท็อปมาตรฐาน» อาจระบุรุ่น ผู้ขายที่อนุมัติแล้ว ราคา 1,200 ดอลลาร์ และการรับประกันสามปี ผู้ขอเลือกจำนวนและอธิบายว่าใครจะใช้ ฝ่ายจัดซื้อจึงได้รับข้อมูลที่มีประโยชน์เหมือนกันทุกครั้ง

ทำให้ตัวเลือกไม่ซับซ้อน

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

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

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

เผื่อไว้สำหรับข้อยกเว้น

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

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

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

เพิ่มการตรวจสอบงบประมาณก่อนอนุมัติ

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

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

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

ตรวจสอบยอดรวมของคำขอทั้งหมด

คำนวณยอดที่ฝ่ายจัดซื้อจะจ่ายจริง รวมจำนวน ราคาต่อหน่วย ภาษี ค่าจัดส่ง ค่าติดตั้ง และค่าใช้จ่ายต่อเนื่องเมื่อเกี่ยวข้อง การสมัครซอฟต์แวร์ราคา 900 ดอลลาร์ที่มีค่าติดตั้ง 150 ดอลลาร์ จึงเป็นคำขอ 1,050 ดอลลาร์

ให้กระบวนการอนุมัติงบประมาณทำงานเมื่อผู้ขอส่งแบบฟอร์ม ก่อนที่ระบบจะส่งต่อให้ผู้อนุมัติ วิธีนี้ช่วยลดเวลาตรวจสอบที่สูญเปล่า และเปิดโอกาสให้ผู้ขอแก้ศูนย์ต้นทุน ลดรายการสั่งซื้อ หรืออธิบายข้อยกเว้น

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

กำหนดเส้นทางสำหรับคำขอที่เกินงบ

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

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

ตั้งเส้นทางอนุมัติที่ผู้ใช้ทำตามได้

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

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

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

ใช้กฎที่คาดเดาได้

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

ตัวอย่างกฎที่บริษัทอาจใช้มีดังนี้

• คำขอต่ำกว่า 500 ดอลลาร์ส่งให้ผู้จัดการแผนก
• คำขอระหว่าง 500 ถึง 5,000 ดอลลาร์ส่งให้ผู้จัดการและเจ้าของศูนย์ต้นทุน
• คำขอซอฟต์แวร์และบริการคลาวด์ส่งให้ฝ่ายไอทีหรือฝ่ายความปลอดภัยด้วย
• คำขอเกิน 5,000 ดอลลาร์ส่งให้ฝ่ายจัดซื้อหลังผ่านการอนุมัติงบประมาณ
• การซื้อสินทรัพย์ถาวรส่งให้เจ้าของฝ่ายการเงินไม่ว่าวงเงินเท่าใด

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

วางแผนกรณีผู้ไม่อยู่และเก็บระเบียนให้ครบ

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

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

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

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

สร้างขั้นตอนคำขอทีละขั้น

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

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

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

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

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

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

กำหนดการดำเนินการของแต่ละบทบาท

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

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

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

แจ้งเตือนเมื่อถึงเวลาต้องดำเนินการ

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

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

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

ด้วย AppMaster แอปจัดซื้อแบบไม่ใช้โค้ดสามารถจัดโครงสร้างสถานะใน Data Designer และกำหนดการเปลี่ยนแปลงที่อนุญาตใน Business Process Editor การส่งต่องานแต่ละครั้งจึงอยู่ในระเบียน ไม่ต้องอาศัยความจำของใคร

ตัวอย่าง: คำขอสมัครใช้ซอฟต์แวร์

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

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

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

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

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

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

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

ข้อผิดพลาดที่ทำให้การจัดซื้อล่าช้า

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

ส่งทุกคำขอให้ผู้บริหารระดับสูง

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

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

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

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

กำหนดกฎสำหรับการแก้ไขที่มีผลสำคัญ การเปลี่ยนจาก 10 ใบอนุญาตเป็น 12 ใบ หรือจาก 500 ดอลลาร์เป็น 1,200 ดอลลาร์ ควรส่งคำขอกลับให้ผู้ตรวจสอบที่เกี่ยวข้อง ส่วนหมายเหตุเล็กน้อย เช่น ผู้ติดต่อเรื่องการจัดส่ง อาจแก้ไขได้โดยไม่ต้องเริ่มเวิร์กโฟลว์อนุมัติการซื้อใหม่

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

ปิดคำขอเร็วเกินไป

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

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

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

ตรวจสอบก่อนเปิดใช้งาน

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

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

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

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

ใช้ตัวเลขจริงในการทดสอบงบประมาณ กำหนดให้ทีมมีงบประมาณรายเดือนเหลือ 2,000 ดอลลาร์ แล้วส่งคำขอ 2,400 ดอลลาร์ ตัดสินใจว่าระบบควรบล็อกคำขอ ขออนุมัติจากฝ่ายการเงิน หรือเปิดให้เจ้าของงบประมาณโอนเงิน ทุกฝ่ายที่เกี่ยวข้องควรเห็นผลลัพธ์เดียวกัน

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

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

เลือกขั้นตอนถัดไป

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

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

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

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

AppMaster ช่วยให้ทีมสร้างแอปจัดซื้อแบบไม่ใช้โค้ดโดยไม่ต้องเริ่มจากโครงการทางเทคนิคที่ว่างเปล่า ทีมสร้างแบบฟอร์มคำขอของพนักงาน ใช้ Business Process Editor สำหรับการตรวจสอบงบประมาณและเส้นทางอนุมัติ และสร้างหน้าจอแยกสำหรับผู้จัดการและฝ่ายจัดซื้อได้ Data Designer ช่วยเก็บรายการในแคตตาล็อก แผนก ผู้ขาย งบประมาณ และคำขอไว้ในที่เดียว

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