รูปแบบเวิร์กโฟลว์สำหรับทีมปฏิบัติการที่ช่วยประหยัดเวลา

ทำไมเวิร์กโฟลว์ของฝ่ายปฏิบัติการจึงถูกสร้างขึ้นใหม่บ่อย

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

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

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

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

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

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

ห้าบล็อกที่ทีมส่วนใหญ่ใช้ซ้ำอยู่เสมอ

เวิร์กโฟลว์ปฏิบัติการส่วนใหญ่อาจสรุปเป็นบล็อกสร้างขึ้นห้าชิ้น: ส่ง (submit), ตรวจสอบ (review), อนุมัติ (approve), แจ้งผล (notify) และปิด (close) ทีมต่าง ๆ อาจใช้ชื่อแตกต่างกัน แต่โครงสร้างคงคุ้นเคย มีคนขอ มีคนตรวจ มีคนตัดสิน ผู้คนได้รับการอัปเดต และงานก็เสร็จ

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

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

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

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

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

บล็อกเหล่านี้ใช้งานได้เพราะแต่ละบล็อกมีหน้าที่ชัดเจน Submit เก็บคำขอ Review ตรวจคุณภาพ Approve ตัดสิน Notify แจ้งผล และ Close ระบุว่ากระบวนการเสร็จสิ้น

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

เริ่มที่การส่งและจับคำขอให้ชัดเจน

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

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

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

ฟอร์มคำขอส่วนใหญ่ต้องการข้อมูลพื้นฐานไม่กี่อย่าง:

• สิ่งที่ต้องการ
• ทำไมถึงต้องการ
• ต้องการเมื่อไหร่
• ใครเป็นผู้ขอ
• ไฟล์หรือบันทึกที่จำเป็น

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

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

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

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

การตรวจกับการอนุมัติไม่ใช่ขั้นตอนเดียวกัน

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

การตรวจคือการเช็กคุณภาพและความครบถ้วน การอนุมัติคือการตัดสินใจใช่หรือไม่

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

ขั้นตอนการตรวจควรตอบคำถามเช่น:

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

ขั้นตอนการอนุมัติควรถามคำถามต่างออกไป: เราจะยอมรับคำขอนี้หรือไม่?

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

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

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

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

แจ้งผลและปิดโดยไม่มีปลายหลวม

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

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

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

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

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

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

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

วิธีเปลี่ยนกระบวนการหนึ่งอย่างให้เป็นรูปแบบที่นำกลับมาใช้ได้

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

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

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

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

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

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

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

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

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

ตัวอย่าง: โฟลว์คำขอซื้อแบบง่าย

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

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

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

เวอร์ชันที่สะอาดของโฟลว์อาจเป็นดังนี้:

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

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

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

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

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

ข้อผิดพลาดทั่วไปที่ทำให้ทีมช้าลง

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

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

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

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

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

สัญญาณเตือนบางอย่างมักปรากฏเร็ว:

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

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

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

เช็ครวดเร็วก่อนนำรูปแบบไปใช้ซ้ำ

ก่อนจะคัดลอกเวิร์กโฟลว์ไปใช้กับกระบวนการใหม่ หยุดและเช็คพื้นฐานก่อน

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

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

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

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

สุดท้าย ทำให้สถานะอ่านง่ายในพริบตา คนที่เปิดคำขอไม่ควรต้องอ่านประวัติทั้งหมดเพื่อรู้ว่าเกิดอะไรขึ้น สถานะเรียบง่ายเช่น ส่งแล้ว (Submitted), อยู่ระหว่างตรวจ (In Review), ต้องแก้ไข (Needs Fixes), อนุมัติ (Approved) และ ปิด (Closed) มักเพียงพอ

เปลี่ยนรูปแบบให้เป็นเครื่องมือจริง

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

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

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

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

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

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