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

ทำไมการพยายามดิจิไทซ์ทุกอย่างพร้อมกันจึงล้มเหลว
การพยายามเปลี่ยนทั้งธุรกิจในครั้งเดียวฟังดูมีประสิทธิภาพ แต่ในทางปฏิบัติมักปิดบังปัญหาที่แท้จริง
ธุรกิจบริการส่วนใหญ่ไม่ได้มีระบบเดียวที่เสียหายอย่างรุนแรง แต่มีช่องว่างเล็ก ๆ หลายจุดที่ทำให้งานช้าลงทุกวัน ใบเสนอราคาใช้เวลายืนยันนานไป ฟอร์มลูกค้าข้ามรายละเอียดสำคัญ การส่งต่องานระหว่างการขายและงานส่งมอบค้างอยู่ในกล่องจดหมายของใครบางคน เมื่อรวมเรื่องทั้งหมดไว้ในโครงการดิจิทัลครั้งใหญ่ ส่วนที่ยุ่งเหยิงมักถูกกลบด้วยการตั้งค่าซอฟต์แวร์ การประชุม และกฎใหม่
ทีมมักยังคงนิสัยเก่าในขณะที่เรียนรู้เครื่องมือใหม่ คนหนึ่งกรอกข้อมูลลูกค้าในสองที่ อีกคนยังขอการอนุมัติในแชทเพราะรู้สึกว่าเร็วกว่า แทนที่จะได้กระบวนการที่ชัดเจน คุณกลับได้ระบบสองชุดที่วิ่งคู่กัน งานดูหนักขึ้นก่อนจะดีขึ้น
ค่าใช้จ่ายปรากฏขึ้นตั้งแต่ต้น แต่ผลลัพธ์มักต้องรอ คุณต้องจ่ายค่าเซ็ตอัพ การฝึกอบรม การเปลี่ยนกระบวนการ และเวลาที่คนเสียไปขณะปรับตัว ถ้าสิ่งแรกที่ทีมรู้สึกคือความสับสนแทนที่จะเป็นความโล่งใจ ความเชื่อมั่นจะลดลงเร็ว นั่นคือเหตุผลหนึ่งที่โครงการเปลี่ยนระบบขนาดใหญ่ชะงัก
สิ่งที่มักพังเป็นอย่างแรกนั้นเรียบง่าย:
- คนถูกขอให้เปลี่ยนหลายขั้นตอนในครั้งเดียว
- การตัดสินใจกระบวนการที่ไม่ดีถูกล็อกไว้ในเครื่องมือใหม่
- พนักงานสร้างวิธีแก้ขัดเพื่อให้ยังบริการลูกค้าได้
- ผู้นำคาดหวังการประหยัดก่อนที่กระบวนการจะเสถียร
ความไว้วางใจคือสิ่งที่ยากที่สุดที่จะเรียกคืน ถ้าการเปิดตัวครั้งแรกรู้สึกยุ่งเหยิง คนจะหยุดเชื่อว่าการเปลี่ยนแปลงครั้งต่อไปจะช่วยได้ แล้วแม้แต่การอัปเดตที่ดี ๆ ก็จะเจอแรงต่อต้าน
วิธีที่ดีกว่าคือทำทีละน้อยและเป็นรูปธรรม เริ่มจากเวิร์กโฟลว์เดียวที่ทีมสัมผัสได้ทุกวัน เช่น กระบวนการเสนอราคา การรับลูกค้าเข้าระบบ หรือเวิร์กโฟลว์การอนุมัติ จะทดสอบง่าย ปรับปรุงง่าย และทีมยอมรับได้ง่ายกว่า
แม้กับเครื่องมือสร้างที่เร็วอย่าง Koder.ai การแทนที่ทุกกระบวนการพร้อมกันมักสร้างเสียงรบกวนมากกว่าความก้าวหน้า ชัยชนะชัดเจนเพียงครั้งเดียวสร้างแรงผลักดัน การปรับโครงสร้างทั้งบริษัทมักเผาแรงจูงใจไปหมด
การเปลี่ยนเวิร์กโฟลว์ให้เป็นผลิตภัณฑ์จริง ๆ หมายความว่าอย่างไร
การเปลี่ยนธุรกิจบริการให้เป็นผลิตภัณฑ์ไม่ได้หมายความว่าต้องเปลี่ยนทั้งบริษัทเป็นซอฟต์แวร์ในชั่วข้ามคืน แต่มันหมายถึงการหยิบงานชิ้นที่ทำซ้ำได้มาแล้วทำให้มันทำในแบบเดียวกันทุกครั้ง
งานหยุดอยู่ในหัวคนคนเดียว มันกลายเป็นลำดับที่ชัดเจน: อะไรเข้ามา อะไรเกิดขึ้นต่อ ใครตรวจ และสิ่งที่จะส่งมอบเมื่อเสร็จ
เวิร์กโฟลว์ที่ดีต้องมีจุดเริ่มต้นและเส้นชัย กระบวนการเสนอราคาตัวอย่างอาจเริ่มเมื่อผู้มีโอกาสเป็นลูกค้ากรอกแบบฟอร์มสั้น ๆ และจบเมื่อได้รับราคา ขอบเขต และเวลาที่ลูกค้าสามารถอนุมัติได้ ถ้าจุดเหล่านั้นไม่ชัด งานก็จะยังยุ่ง
การเปลี่ยนเป็นผลิตภัณฑ์ยังหมายถึงการใช้ข้อมูลนำเข้าที่เหมือนกันทุกครั้ง ถ้าลูกค้าทุกคนส่งรายละเอียดต่างกันในรูปแบบต่าง ๆ ทีมของคุณจะเสียเวลาไล่หาข้อมูลที่ขาดอยู่ ฟอร์มสั้น ๆ เช็คลิสต์ หรือเทมเพลตคำขอที่เป็นมาตรฐานสามารถแก้ได้อย่างรวดเร็ว
ส่วนกลางก็สำคัญ งานที่ทำซ้ำได้จะง่ายขึ้นเมื่อการตรวจสอบเกิดขึ้นในลำดับเดียวกัน คุณไม่ได้ตัดการตัดสินใจของมนุษย์ออก แต่คุณกำหนดให้ชัดว่าการตัดสินใจอยู่ที่จุดไหน แทนที่จะปล่อยให้มันเกิดขึ้นโดยสุ่ม
ในหลายกรณี เวิร์กโฟลว์ที่แข็งแรงหนึ่งรายการมีห้าส่วน:
- ทริกเกอร์ที่ชัดเจนที่เริ่มงาน
- ข้อมูลมาตรฐานที่เก็บล่วงหน้า
- การตรวจสอบไม่กี่จุดก่อนดำเนินการต่อ
- เจ้าของหนึ่งคนต่อแต่ละขั้นตอน
- คำนิยามของความเสร็จที่ชัดเจน
เมื่อองค์ประกอบเหล่านี้อยู่ในที่แล้ว ราคาขายและระยะเวลาจะคาดเดาได้ง่ายขึ้น คุณเริ่มเห็นรูปแบบ: งานใช้เวลานานแค่ไหน จุดที่เกิดความล่าช้า และคำขอใดอยู่นอกข้อเสนอปกติ นั่นทำให้การตั้งราคาแน่นอนขึ้นและการจัดการความคาดหวังลูกค้าทำได้ง่ายขึ้น
การมอบความเป็นเจ้าของก็ดีขึ้นด้วย เมื่อทุกคนรู้ว่าใครรับผิดชอบการตรวจทาน การอนุมัติ และการส่งต่องาน จะมีงานติดค้างน้อยลง
ลองนึกภาพเอเจนซีขนาดเล็กที่ส่งข้อเสนอ ก่อนจะเปลี่ยนเป็นผลิตภัณฑ์ ทุกใบเสนอราคาถูกสร้างจากศูนย์ การอนุมัติเกิดขึ้นในแชท และไม่มีใครรู้ว่าใครควรติดตาม หลังจากเปลี่ยนแล้ว เอเจนซีใช้ฟอร์มรับเรื่องเดียว ขั้นตอนตรวจทานเดียว กฎอนุมัติเดียว และรูปแบบข้อเสนอเดียว บริการยังคงปรับแต่งได้ แต่เวิร์กโฟลว์ไม่วุ่นวายอีกต่อไป
นั่นคือการเปลี่ยนจริง: ไม่ใช่การลดความใส่ใจ แต่เป็นการลดการคาดเดา
เลือกเวิร์กโฟลว์แรกที่จะแก้ไข
จุดเริ่มต้นที่ดีที่สุดไม่ใช่ปัญหาใหญ่ที่สุดในบริษัท แต่มักเป็นงานที่เกิดขึ้นทุกสัปดาห์ มีรูปแบบที่คุ้นเคย และเสียเวลาในแบบเดิม ๆ มองหางานที่ทำซ้ำได้ก่อนมองหางานที่สมบูรณ์แบบ
สัญญาณสองอย่างของเวิร์กโฟลว์เริ่มต้นที่ดีคือ พนักงานจำขั้นตอนได้จากความถี่ที่ทำ และลูกค้ารู้สึกถึงความล่าช้าเมื่อมันพัง นั่นทำให้คุณค่าปรากฏชัดทันที
การเสนอราคามักเป็นจุดเริ่มต้นที่ดีสำหรับหลายทีม การสนทนาการขายเกิดขึ้น รายละเอียดถูกรวบรวม ใครบางคนตั้งราคา แล้วส่งใบเสนอราคา ถ้ากระบวนการนั้นใช้เวลาสองวันเมื่อควรใช้สองชั่วโมง ทั้งทีมและลูกค้าต่างรับรู้ถึงปัญหา
การรับลูกค้าเข้าระบบและการอนุมัติก็เป็นตัวเลือกที่ดี พวกมันมักมีการตัดสินใจที่ชัดเจนเช่น เห็นชอบหรือไม่ เหสมบูรณ์หรือไม่ อนุมัติหรือส่งกลับ การตัดสินใจที่ชัดเจนแปรเป็นกระบวนการซ้ำได้ง่ายกว่างานที่ต้องตัดสินใจหนักทุกครั้ง
ก่อนเลือกเวิร์กโฟลว์ ตรวจสอบสัญญะพื้นฐานบางอย่าง:
- มันเกิดขึ้นอย่างน้อยสัปดาห์ละครั้ง
- ความล่าช้าทำให้พนักงานหรือลูกค้าหงุดหงิด
- ขั้นตอนส่วนใหญ่เหมือนกันทุกครั้ง
- มีจุดตัดสินใจที่ชัดเจน
- ความสำเร็จวัดได้ง่าย
หลีกเลี่ยงโปรเจกต์ที่เกิดไม่บ่อย กรณีเฉพาะ และงานที่ปรับแต่งสูงในช่วงแรก ถ้าคำขอแต่ละครั้งต่างกัน คุณจะใช้เวลามากกับข้อยกเว้นแทนการปรับปรุงกระบวนการ ซึ่งมักสร้างระบบที่ยุ่งเหยิงและไม่มีใครเชื่อถือ
ตัวอย่างเอเจนซีขนาดเล็ก: แทนที่จะพยายามอัตโนมัติทั้งการเสนอราคา การส่งมอบ การออกใบแจ้งหนี้ การจ้าง และการรายงานพร้อมกัน ให้เริ่มจากการอนุมัติการเปลี่ยนแปลงขอบเขต งานเดียวนี้ลดการถกเถียง ให้คำตอบลูกค้าเร็วขึ้น และสร้างบันทึกที่ชัดเจน
ถ้าคุณใช้ Koder.ai เพื่อสร้างเครื่องมือภายในหรือแอปเล็ก ๆ สำหรับลูกค้า เวิร์กโฟลว์ที่โฟกัสยังง่ายต่อการส่งมอบอย่างรวดเร็ว หนึ่งกระบวนการที่ทำซ้ำได้พร้อมผลลัพธ์ชัดเจนจะทำให้คุณมีจุดเริ่มต้นที่สะอาดและแสดงให้เห็นว่าจะปรับปรุงอะไรต่อไป
แม็ปเวิร์กโฟลว์บนหน้าเดียว
ก่อนจะอัตโนมัติอะไร ให้เอาเวิร์กโฟลว์ออกจากหัวคนและลงบนหน้าเดียว นั่นเพียงพอที่จะโชว์สิ่งที่เกิดขึ้นจริงตั้งแต่ต้นจนจบโดยไม่ปิดบังส่วนที่ยุ่งเหยิง
ทำให้เรียบง่าย เปิดเอกสาร กระดานไวท์บอร์ด หรือโน้ต แล้วเขียนขั้นตอนเป็นภาษาธรรมดา เช่นที่ทีมจะพูดออกมา: "ลูกค้าขอใบเสนอราคา," "ฝ่ายขายตรวจสอบขอบเขต," "ข้อเสนอได้รับการอนุมัติ," "ส่งใบแจ้งหนี้."
สำหรับแต่ละขั้น ให้จับห้าสิ่งนี้ไว้:
- เกิดอะไรขึ้น
- ตอนนี้ใครทำมัน
- ต้องการข้อมูลอะไรบ้าง
- จุดที่มักเกิดความล่าช้าอยู่ที่ไหน
- ขั้นตอนนี้เพิ่มคุณค่าอย่างชัดเจนไหม
ที่นี่แหละที่ธุรกิจส่วนใหญ่มองเห็นปัญหาจริง ปัญหาไม่ใช่งานเองเสมอไป แต่เป็นการรอคอย การถกเถียง หรือการที่รายละเอียดสำคัญอยู่ในอีเมลหรือความทรงจำของใครบางคน
ตัวอย่างง่าย ๆ จะชัดเจน ลองจินตนาการเอเจนซีเล็ก ๆ ที่สร้างใบเสนอราคา ลูกค้าเข้ามา ผู้จัดการบัญชีสอบถามรายละเอียดเล็กน้อย ดีไซเนอร์ให้การประเมิน ผู้ก่อตั้งตรวจสอบราคาซ้ำ แล้วจึงส่งใบเสนอราคา ดูบนกระดาษก็เป็นเรื่องปกติ แต่แผนที่เวิร์กโฟลว์อาจแสดงว่าดีไซเนอร์รอรายละเอียดโปรเจกต์ที่ขาดไปสองวัน และผู้ก่อตั้งยังตรวจสอบราคาที่ได้รับอนุมัติแล้วเมื่อเดือนก่อน
แผนที่แบบนี้ให้สิ่งที่ใช้แก้ไขได้จริง: รายการจุดเสียดทานที่คุณสามารถแก้ได้ อาจต้องเพิ่มคำถามสามข้อในฟอร์มรับเรื่อง หรือให้การอนุมัติเฉพาะโปรเจกต์ที่มีขนาดเกินเกณฑ์หนึ่ง หรืออาจยุบการส่งต่อบางจุดทิ้งไป
เข้มงวดในการตัดขั้นตอนที่ไม่เปลี่ยนผลลัพธ์ ถ้าขั้นตอนมีอยู่เพราะ "เราทำกันมาแบบนี้" ถือเป็นสัญญาณเตือน เก็บเฉพาะส่วนที่ลดความเสี่ยง ปรับปรุงคุณภาพ หรือช่วยลูกค้า ตัดส่วนที่เหลือ
ถ้าคุณวางแผนจะสร้างเวิร์กโฟลว์นี้ใน Koder.ai แผนที่หน้าเดียวจะกลายเป็นสเปคการสร้างที่ดี คุณรู้แล้วขั้นตอน ผู้เกี่ยวข้อง ข้อมูลนำเข้า และกฎ นั่นทำให้เวอร์ชันแรกสร้างและทดสอบได้ง่ายขึ้นมาก
วิธีเปลี่ยนให้เป็นผลิตภัณฑ์อย่างเรียบง่าย
เมื่อเวิร์กโฟลว์ชัดเจน ให้กำหนดเส้นทางเริ่มต้น จุดมุ่งหมายไม่ใช่ครอบคลุมทุกกรณีพิเศษ แต่ทำให้กรณีที่พบบ่อยเป็นเรื่องง่าย เร็ว และสม่ำเสมอ
เริ่มจากเลือกวิธีมาตรฐานหนึ่งวิธีให้คำขอเข้ามา ถ้าลูกค้าส่งอีเมล ข้อความ โทร และบันทึกเสียง ทีมคุณจะเดาไม่หยุดว่าขาดอะไร ฟอร์มรับเรื่องเรียบง่ายหรือหน้าคำขอแบบแนะนำจะดีกว่าเพราะขอข้อมูลแบบเดียวกันทุกครั้ง
ต่อมา กำหนดขอบเขตคงที่สำหรับงานที่เห็นบ่อย แทนที่จะบอกว่า "มีใบเสนอราคาปรับแต่งได้" คุณอาจเสนอสามแพ็กเกจอัปเดตเว็บไซต์ที่มีขอบเขต ราคา และเวลาส่งที่ชัดเจน นั่นทำให้การเสนอราคาง่ายขึ้นสำหรับลูกค้าและทีมของคุณมากขึ้น
เทมเพลตก็ช่วยได้มาก ใช้ข้อความสำเร็จรูปสำหรับการยืนยัน ติดตาม ขออนุมัติ และการส่งต่อ ใช้ฟอร์มมาตรฐานเพื่อให้ลูกค้ารู้ว่าจะส่งอะไร และผู้จัดการรู้ว่าต้องทบทวนอะไร เมื่อทุกขั้นมีเทมเพลต บริการจะเริ่มรู้สึกเหมือนเป็นผลิตภัณฑ์มากขึ้น
การตั้งค่าที่เรียบง่ายมักประกอบด้วย:
- ฟอร์มรับเรื่องเดียวสำหรับคำขอใหม่
- ตัวเลือกบริการมาตรฐานสองถึงสามแบบ
- เทมเพลตข้อความสำหรับแต่ละขั้น
- กฎการอนุมัติสำหรับคำขอความเสี่ยงต่ำและสูง
ขั้นตอนการอนุมัติสำคัญกว่าที่หลายทีมคาด บางคำขอควรเดินหน้าต่ออัตโนมัติ เช่น การเปลี่ยนแปลงขนาดเล็กภายใต้งบที่กำหนด หรืองานซ้ำสำหรับลูกค้าที่มีอยู่ คำขออื่นควรหยุดเพื่อตรวจสอบ โดยเฉพาะเมื่อราคา ขอบเขต หรือกำหนดเวลานอกขอบเขตปกติ
ลองดูเอเจนซีออกแบบที่จัดการการแก้ไขหน้าเว็บหนึ่งหน้าจำนวนมาก มันสามารถสร้างฟอร์มคำขอมาตรฐาน แพ็กเกจคงที่สำหรับ "แก้ไขได้สูงสุด 3 รายการ" และกฎอนุมัติอัตโนมัติสำหรับลูกค้าที่กลับมาในวงเงินที่กำหนด เฉพาะคำขอที่ใหญ่กว่าจะไปหาผู้จัดการ เท่านี้ก็ลดความล่าช้าและการถกเถียงได้
ถ้าสร้างใน Koder.ai มันสามารถกลายเป็นแอปภายในน้ำหนักเบาที่มีฟอร์ม สถานะ และตรรกะการอนุมัติในที่เดียว ก่อนเปิดใช้งานกว้าง ๆ ให้ทดสอบกับลูกค้าจำนวนเล็กน้อยหรือทีมหนึ่งทีมเป็นเวลาสองสัปดาห์ นั่นมักจะเผยขั้นตอนที่ไม่ชัด ช่องที่ขาดข้อมูล และกฎที่กระด้าง
ตัวอย่าง: เอเจนซีเล็ก ๆ เริ่มจากการเสนอราคา
เอเจนซีขนาดเล็กมักเจอรูปแบบเดียวกันก่อน: ทุกลีดใหม่เริ่มการแลกอีเมลดังเดิม ๆ โปรเจกต์ประเภทไหน งบประมาณเท่าไร ใครต้องอนุมัติ มีกำหนดส่งไหม ทีมตอบคำถามเดิมซ้ำ แต่ใบเสนอราคายังใช้เวลาหลายวัน
นั่นจึงเป็นเหตุผลว่าทำไมการเสนอราคามักเป็นจุดเริ่มต้นที่ง่าย มันทำซ้ำได้ วัดผลง่าย และเกี่ยวข้องกับรายได้โดยตรง
แทนที่จะคุยกันไปมาไม่รู้จบ เอเจนซีสร้างฟอร์มรับเรื่องสั้น ๆ ที่ถามเฉพาะรายละเอียดที่ส่งผลต่อราคาและขอบเขตจริง ๆ: ประเภทโปรเจกต์ จำนวนหน้า คุณสมบัติที่ต้องการ วันที่ต้องการเปิดตัว และลูกค้ามีเนื้อหาและแบรนด์อยู่แล้วหรือไม่
ตอนนี้การสนทนาครั้งแรกชัดเจนขึ้น ฝ่ายขายไม่ต้องไล่หาข้อเท็จจริงพื้นฐาน และลูกค้ารู้ว่าข้อมูลอะไรสำคัญตั้งแต่ต้น
สำหรับคำขอทั่วไป เอเจนซีตั้งช่วงราคาล่วงหน้า เว็บไซต์การตลาดง่าย ๆ อาจอยู่ในช่วงหนึ่ง หน้าลงทะเบียนอยู่ในอีกช่วงหนึ่ง และงานที่ปรับแต่งมากอยู่ในระดับสูงกว่า ใบเสนอราคาไม่ใช่การเดาอีกต่อไป แต่มาจากโมเดลที่ชัดเจน
นั่นเปลี่ยนหลายอย่างพร้อมกัน งานมาตรฐานเคลื่อนเร็วขึ้นเพราะเฟรมราคาชัดเจน ลูกค้าได้รับคำตอบเร็วขึ้นและข้อความไม่ขัดแย้ง ทีมยังมองเห็นลีดที่ไม่เหมาะสมได้เร็วขึ้น
ผู้จัดการเข้ามาเมื่อมีสิ่งผิดปกติ เช่น กำหนดเวลาที่เร่งด่วน การรวมระบบแบบกำหนดเอง หรือขอบเขตไม่ชัด นั่นทำให้การอนุมัติเน้นที่ข้อยกเว้นแทนที่จะเป็นทุกรายการ
ทีมอาจเปลี่ยนสิ่งนี้เป็นแอปภายในน้ำหนักเบา ด้วย Koder.ai เวิร์กโฟลว์การเสนอราคาแบบนี้สามารถสร้างจากพรอมต์แชทเป็นสิ่งที่ใช้งานได้จริงโดยไม่กลายเป็นโครงการซอฟต์แวร์ยักษ์ใหญ่
ชัยชนะที่แท้จริงปรากฏหลังจากส่งใบเสนอราคา โปรเจกต์เริ่มด้วยความประหลาดใจน้อยลงเพราะขอบเขตถูกกำหนดไว้ตั้งแต่ต้น ทีมรู้แล้วว่าสิ่งที่สัญญาไว้คืออะไร แพ็กเกจไหนเหมาะ และอะไรต้องการการทบทวนเพิ่มเติม
การเสนอราคาไม่ได้ซับซ้อนขึ้น แต่มันสม่ำเสมอขึ้น นั่นมักเป็นสัญญาณแรกว่าการอัตโนมัติเวิร์กโฟลว์บริการได้ผล
ความผิดพลาดทั่วไปที่ควรหลีกเลี่ยง
ความเสี่ยงใหญ่สุดไม่ใช่การเคลื่อนไหวช้าเกินไป แต่คือการพยายามแก้หลายอย่างพร้อมกันแล้วได้ระบบที่ไม่มีใครเชื่อถือ
ความผิดพลาดหนึ่งคือเลือกเวิร์กโฟลว์ที่ยุ่งที่สุดในบริษัทเพราะรู้สึกว่าสำคัญ นั่นมักหมายถึงกรณีเฉพาะมากขึ้น ความเห็นขัดแย้งมากขึ้น และความล่าช้ามากขึ้น ชัยชนะแรกที่ดีกว่าคืองานที่เกิดบ่อย ง่าย และเจ็บปวดพอที่คนอยากให้มันดีขึ้น เช่น การเสนอราคา การรับลูกค้าเข้าระบบ หรือการอนุมัติภายใน
กับดักอีกอย่างคือออกแบบให้รองรับทุกกรณีที่หายากตั้งแต่วันแรก ทีมมักถามว่า "ถ้าลูกค้าคนนี้ขอขั้นตอนพิเศษล่ะ?" หรือ "ถ้าฝ่ายกฎหมายต้องทบทวนพิเศษล่ะ?" กรณีเหล่านั้นสำคัญ แต่ไม่ควรเป็นตัวกำหนดเวอร์ชันแรก ถ้า 80% ของคำขอตามเส้นทางเดียวกัน ให้สร้างสำหรับเส้นทางนั้นก่อน แล้วจัดการข้อยกเว้นด้วยมือจนกว่าจะเห็นรูปแบบชัดเจน
ยังง่ายที่จะกระโดดเข้าเครื่องมือก่อนที่กระบวนการจะเรียบร้อย ทีมอาจเริ่มสร้างฟอร์ม ออโตเมชัน หรือแอปก่อนที่จะอธิบายเวิร์กโฟลว์เป็นภาษาธรรมดาได้ ถ้าคุณอธิบายไม่ได้ว่าใครเริ่มงาน อะไรเกิดขึ้นต่อ และอะไรถือว่าเสร็จ เครื่องมือจะเพียงปิดบังความสับสนเท่านั้น
กฎง่าย ๆ ช่วยได้: กำหนดขั้นตอนก่อน ตั้งชื่อเจ้าของแต่ละขั้น ตกลงจุดส่งต่อ และตัดสินความสำเร็จให้ชัดเจน
การมอบความเป็นเจ้าของคือจุดที่หลายโครงการเวิร์กโฟลว์ล้มหลังเปิดใช้งาน กระบวนการเปิดแล้วแต่ไม่มีใครรับผิดชอบในการดูแลความเรียบร้อย ตอบคำถาม หรืออัปเดตเมื่อธุรกิจเปลี่ยน จากนั้นปัญหาเล็ก ๆ สะสม คนกลับไปใช้อีเมลและแชท และเวิร์กโฟลว์ค่อย ๆ ตายไป
ทีมยังมักติดตามตัวเลขผิด ตัวชี้วัดการกระทำอาจดูน่าประทับใจโดยไม่ปรับปรุงการส่งมอบ การมีการส่งเข้ามามากขึ้น การแจ้งเตือนมากขึ้น หรืองานที่เสร็จมากขึ้นไม่เท่ากับกระบวนการดีขึ้น
ดูตัวเลขที่แสดงการปรับปรุงจริง:
-
เวลาจากคำขอจนเสร็จ
-
จำนวนข้อผิดพลาดหรือการแก้ไข
-
ความถี่ที่งานติดค้าง
-
ความถี่ที่คนข้ามระบบไปทำงานนอกระบบ
ถ้าเอเจนซีลดเวลาการตอบใบเสนอราคาจากสองวันเหลือสองชั่วโมงและลดความผิดพลาดด้านราคา นั่นคือความก้าวหน้า ถ้ามันแค่สร้างการอัปเดตภายในมากขึ้น นั่นคือเสียงรบกวน การเปลี่ยนแปลงเวิร์กโฟลว์ที่ดีที่สุดมักรู้สึกน่าเบื่อในทางที่ถูกต้อง: เร็วขึ้น ชัดเจนขึ้น และทำซ้ำได้ง่ายขึ้น
ตรวจสอบด่วนก่อนจะอัตโนมัติ
ก่อนจะอัตโนมัติอะไร ให้ทดสอบว่ากระบวนการชัดพอที่คนอื่นจะทำได้โดยไม่เดา ถ้ามันยังอยู่ในหัวคนคนเดียว การอัตโนมัติจะปิดบังความสับสนและทำให้แก้ไขยากขึ้นในภายหลัง
กฎง่าย ๆ คือ: เวิร์กโฟลว์ควรอธิบายในหน้าเดียวและทำซ้ำได้ในสัปดาห์ปกติ
แบบทดสอบด่วน:
- พนักงานใหม่สามารถทำตามขั้นตอนด้วยคู่มือสั้น ๆ แล้วจบงานได้โดยไม่ต้องขอความช่วยเหลือตลอดเวลาไหม?
- ข้อมูลนำเข้าง่ายและถูกเก็บแบบเดียวกันทุกครั้งไหม?
- การส่งต่อนั้นมีเจ้าของคนเดียวชัดเจนไหม?
- คุณรู้สามข้อยกเว้นที่เกิดบ่อยที่สุดไหม?
- ลูกค้ารู้ว่าจะเกิดอะไรต่อและเมื่อไรที่จะได้รับข่าวจากคุณไหม?
ถ้าข้อใดข้อหนึ่งยังไม่ชัด หยุดก่อนจะใส่เครื่องมือ กระบวนการรับลูกค้าที่ยุ่งจะไม่ดีขึ้นเพียงเพราะมันอยู่ในฟอร์มหรือแดชบอร์ดแล้ว
ตัวอย่างเอเจนซีขนาดเล็ก: ถ้าทีมอยากอัตโนมัติการอนุมัติ ก่อนสร้างอะไรให้ยืนยันว่าใครตรวจงาน อะไรถือว่าอนุมัติ จะทำอย่างไรถ้าคำติชมช้า และลูกค้าเห็นอะไรหลังแต่ละขั้น รายละเอียดเหล่านี้ดูพื้นฐาน แต่เป็นจุดเริ่มที่ปัญหาเวิร์กโฟลว์เกิดขึ้น
นี่คือที่ที่แพลตฟอร์มสร้างช่วยได้ เมื่อกระบวนการชัดเจน Koder.ai ออกแบบมาเพื่อสร้างเว็บ เซิร์ฟเวอร์ และแอปมือถือจากอินเทอร์เฟซแชท จึงเหมาะกับงานที่คุณรู้แล้วว่าอยากเปลี่ยนเป็นสิ่งที่ใช้งานได้จริง
ก้าวต่อไปของคุณ
อย่าเริ่มด้วยโครงการระบบทั้งชุด เลือกเวิร์กโฟลว์หนึ่งที่เกิดบ่อย มีการส่งต่อชัดเจน และสร้างปัญหาเดียวกันทุกสัปดาห์ ตัวเลือกแรกที่ดีคือการเสนอราคา การรับลูกค้าเข้าระบบ หรือเวิร์กโฟลว์อนุมัติแบบง่าย
เขียนเวิร์กโฟลว์นั้นลงในไม่เกินสิบขั้น ถ้าต้องมากกว่านั้น กระบวนการอาจยังยุ่งเกินไปที่จะอัตโนมัติให้อยู่ในเกณฑ์ดี เก็บไว้บนหน้าเดียวและใช้ภาษาธรรมดาที่พนักงานใหม่จะทำตามได้โดยไม่ต้องขอความช่วยเหลือ
จากนั้นทำมันแบบแมนนวลสองสัปดาห์
ฟังดูช้า แต่ช่วยประหยัดเวลาในภายหลัง การทดลองแบบแมนนวลเผยว่าคนติดขัดที่ไหน ลูกค้าถามอะไรบ่อย และข้อยกเว้นไหนเกิดบ่อยพอที่จะต้องใส่ใจ
ระหว่างทดสอบ ให้เก็บบันทึกสั้น ๆ สามข้อ:
- ความล่าช้าที่ทำให้งานช้าลง
- คำถามที่คนถามซ้ำ ๆ
- ข้อยกเว้นที่ทำให้กระบวนการพัง
รายการนั้นจะกลายเป็นสเปคที่แท้จริง มันมีประโยชน์กว่าการวางแผนใหญ่โตที่เขียนก่อนงานจะเริ่ม
เมื่อเวิร์กโฟลว์รู้สึกน่าเบื่อและเด predictable แล้วค่อยเพิ่มซอฟต์แวร์ นั่นคือเวลาที่เหมาะจะสร้างเครื่องมือภายใน ฟอร์ม หรือพอร์ทัลลูกค้า หากคุณรู้ขั้นตอนแล้ว Koder.ai สามารถช่วยเปลี่ยนเวิร์กโฟลว์นั้นให้เป็นแอปน้ำหนักเบาจากแชทโดยไม่ต้องพยายามแม็ประบบทั้งบริษัทก่อน
เก็บเวอร์ชันแรกให้เล็ก คุณไม่จำเป็นต้องมีแดชบอร์ด สิทธิขั้นสูง หรือทุกกรณีพิเศษตั้งแต่วันแรก คุณต้องการแค่กระบวนการเดียวที่ทำง่าย อธิบายง่าย และทำซ้ำได้ง่ายขึ้น
จุดตรวจสุดท้ายช่วยได้:
- คนคนเดียวทำตามได้โดยไม่ต้องมีการประชุมเพิ่มเติมไหม?
- ลูกค้าเห็นว่าจะเกิดอะไรต่อไหม?
- คุณมองเห็นจุดที่งานกำลังรอได้ไหม?
- คุณทำงานให้เสร็จด้วยข้อความกลับไปมาน้อยลงได้ไหม?
ถ้าคำตอบคือใช่ ให้ก้าวไปยังเวิร์กโฟลว์ถัดไปและทำวิธีเดียวกันซ้ำ อย่าเปลี่ยนทั้งธุรกิจเป็นดิจิทัลในครั้งเดียว แก้ทางเดินที่ทำซ้ำได้หนึ่งทาง ทำให้ใช้งานได้ แล้วสร้างการปรับปรุงต่อไปจากนั้น
คำถามที่พบบ่อย
ฉันควรทำเวิร์กโฟลว์ใดให้เป็นผลิตภัณฑ์ก่อน?
เริ่มจากงานที่เกิดขึ้นทุกสัปดาห์ มีรูปแบบคุ้นเคย และทำให้เกิดความล่าช้าที่เห็นได้ชัด การเสนอราคา การเริ่มต้นทำงานกับลูกค้า และการอนุมัติแบบง่าย ๆ มักเป็นตัวเลือกแรกที่ดี
การทำให้เป็นผลิตภัณฑ์หมายความว่าบริการของฉันจะปรับแต่งได้น้อยลงหรือไม่?
ไม่ การทำเวิร์กโฟลว์หนึ่งให้เป็นผลิตภัณฑ์หมายถึงการกำหนดเส้นทางที่ชัดเจนสำหรับงานที่ทำซ้ำ โดยมีข้อมูลนำเข้ามาตรฐาน ผู้รับผิดชอบ จุดตรวจสอบ และเกณฑ์ว่างานเสร็จสมบูรณ์ บริการของคุณยังคงมีงานที่ปรับให้เหมาะกับแต่ละรายได้
แบบฟอร์มรับข้อมูลควรเก็บข้อมูลอะไรบ้าง?
เลือกวิธีรับข้อมูลหลักเพียงวิธีเดียว เช่น แบบฟอร์มสั้น ๆ หรือหน้าส่งคำขอแบบมีคำแนะนำ ถามเฉพาะรายละเอียดที่ส่งผลต่อขอบเขตงาน ราคา ระยะเวลา หรือการอนุมัติ
ฉันจะแผนผังเวิร์กโฟลว์ก่อนทำให้เป็นอัตโนมัติได้อย่างไร?
เขียนแผนผังกระบวนการปัจจุบันด้วยภาษาง่าย ๆ ตั้งแต่จุดเริ่มต้นจนจบ ในทุกขั้นตอน ให้ระบุผู้รับผิดชอบ ข้อมูลที่ต้องใช้ ความล่าช้าที่มักเกิดขึ้น และขั้นตอนนั้นเปลี่ยนผลลัพธ์หรือไม่
เวิร์กโฟลว์มาตรฐานช่วยปรับปรุงการเสนอราคาได้อย่างไร?
ใช้แพ็กเกจหรือช่วงราคาที่ชัดเจนสำหรับคำขอทั่วไป แล้วส่งงานที่ไม่ปกติไปให้ตรวจทาน วิธีนี้ช่วยให้ลูกค้าได้รับคำตอบเร็วขึ้น โดยยังมีพื้นที่สำหรับข้อยกเว้น
ฉันควรสร้างรองรับทุกข้อยกเว้นตั้งแต่เริ่มต้นหรือไม่?
อย่าใส่ข้อยกเว้นไว้ในเวอร์ชันแรก เว้นแต่จะเกิดขึ้นบ่อย สร้างเส้นทางปกติก่อน จัดการกรณีที่พบไม่บ่อยด้วยตนเอง และเพิ่มกฎเมื่อเห็นรูปแบบที่เกิดซ้ำ
ใครควรเป็นเจ้าของแต่ละขั้นตอนของเวิร์กโฟลว์?
กำหนดผู้รับผิดชอบที่ระบุชื่อไว้หนึ่งคนสำหรับทุกการส่งต่องาน คนนี้ไม่จำเป็นต้องทำทุกงาน แต่ต้องดูแลงานให้เดินหน้าต่อหรือส่งต่อเพื่อยกระดับการแก้ไข
หลังเปิดใช้เวิร์กโฟลว์แล้ว ฉันควรวัดอะไรบ้าง?
ติดตามเวลาตั้งแต่รับคำขอจนงานเสร็จ ข้อผิดพลาดหรือการแก้ไข งานที่ค้าง และความถี่ที่ผู้คนข้ามกระบวนการ การมีการแจ้งเตือนหรือการส่งข้อมูลมากขึ้นเพียงอย่างเดียวไม่ได้แสดงว่าดีขึ้น
ฉันควรทดสอบเวิร์กโฟลว์ด้วยตนเองก่อนสร้างเครื่องมือหรือไม่?
ลองใช้กระบวนการใหม่ด้วยตนเองเป็นเวลาหนึ่งหรือสองสัปดาห์ก่อนสร้างซอฟต์แวร์รองรับ บันทึกความล่าช้า คำถามที่เกิดซ้ำ และข้อยกเว้นที่พบบ่อย แล้วนำสิ่งที่พบมาใช้กำหนดรูปแบบของแอปหรือระบบอัตโนมัติเวอร์ชันแรก
Koder.ai ช่วยเรื่องเวิร์กโฟลว์ที่ทำให้เป็นผลิตภัณฑ์ได้อย่างไร?
เมื่อคุณรู้ขั้นตอน ข้อมูลนำเข้า ผู้ที่เกี่ยวข้อง และกฎการอนุมัติแล้ว คุณสามารถอธิบายสิ่งเหล่านี้ในแชต และสร้างเว็บแอป แอปเซิร์ฟเวอร์ หรือแอปมือถือขนาดเล็กได้ คงเวอร์ชันแรกให้มุ่งเน้นที่เวิร์กโฟลว์เดียว