แปลงเป็นดิจิทัลหรือสร้างกระบวนการใหม่? กรอบการตัดสินใจง่ายๆ

ทำไมการตัดสินใจนี้ถึงยากกว่าที่คิด

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

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

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

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

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

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

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

เก็บ เปลี่ยนให้เรียบง่าย หรือเอาออก

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

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

ขั้นตอนส่วนใหญ่เข้ากลุ่มใดกลุ่มหนึ่งต่อไปนี้:

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

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

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

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

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

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

กรอบง่ายๆ สำหรับการตัดสินใจ

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

วิธีปฏิบัติที่จะช่วยตัดสินใจแต่ละขั้นตอนคือถามสี่คำถาม:

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

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

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

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

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

วิธีทบทวนกระบวนการทีละขั้นตอน

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

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

จากนั้นถามคำถามเดียวสำหรับทุกขั้นตอน: ทำไมขั้นตอนนี้ถึงมีอยู่?

คำตอบส่วนใหญ่ตกเป็นสามกลุ่ม:

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

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

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

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

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

โครงร่างภาษาธรรมดานั้นยังใช้ได้ดีกับตัวสร้างแบบแชท มันให้เครื่องมือสิ่งที่ชัดเจนจะสร้างแทนที่จะบังคับให้เครื่องมือต้องสะท้อนกระบวนการที่ยุ่งเหยิง

ตัวอย่างสมจริง: งานอนุมัติก่อนมีซอฟต์แวร์

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

บนกระดาษ นั่นดูรอบคอบ แต่ในทางปฏิบัติ มันสร้างความล่าช้า กล่องจดหมายรก และการตรวจสอบซ้ำ

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

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

สิ่งที่เปลี่ยนไป

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

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

นั่นคงการตรวจสอบที่สำคัญและเอาวงจรที่ช้าทิ้งไป

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

นั่นคือการทดสอบสำคัญ: ขั้นตอนเปลี่ยนผลลัพธ์จริงไหม หรือแค่ทำซ้ำการตรวจสอบที่คนอื่นทำแล้ว?

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

ข้อผิดพลาดทั่วไปที่ทำให้ต้องทำงานแก้แพง

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

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

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

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

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

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

เช็คลิสต์ด่วนก่อนแปลงเป็นดิจิทัล

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

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

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

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

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

วิธีเปลี่ยนกระบวนการใหม่เป็นซอฟต์แวร์

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

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

เขียนเส้นทางปกติก่อน

งานส่วนใหญ่ทำตามเส้นทางพื้นฐานเดียว สร้างเส้นทางนั้นก่อน สำหรับแต่ละการส่งต่อ กำหนด:

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

ตรงนี้ช่วยให้ระบบโฟกัสที่งานปกติแทนที่จะโคจรรอบกรณีพิเศษ

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

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

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

ถ้าคุณใช้แพลตฟอร์มเช่น Koder.ai บันทึกเหล่านี้อาจเป็นสเปกภาษาธรรมดา ยิ่งกฎชัดเจน เวอร์ชันแรกก็จะสะอาดขึ้น

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

ขั้นตอนถัดไปสำหรับการเปิดตัวขนาดเล็กและปลอดภัย

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

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

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

ควรทดสอบอะไรเป็นอันดับแรก

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

โฟกัสสัญญาณไม่กี่อย่าง:

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

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

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

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

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