เราเองก็เป็นเอเจนซีที่ทำระบบอัตโนมัติ จึงมีส่วนได้ส่วนเสียกับเรื่องนี้อย่างชัดเจน และนั่นก็เป็นเหตุผลที่ควรเขียนคู่มือนี้ เพราะในความเป็นจริง คำเรียกเดียวกันนี้ถูกใช้กับงานที่ต่างกันมาก ตั้งแต่การตั้งค่าแพลตฟอร์มสำเร็จรูป การพัฒนาซอฟต์แวร์เฉพาะทาง ไปจนถึงการเริ่มจากตัวกระบวนการเอง สิ่งที่เขียนต่อจากนี้คือมุมมองของเรา ไม่ใช่มาตรฐานของวงการ
ความต่างนี้สำคัญกว่าราคา การเลือกผิดประเภทคือการได้ระบบอัตโนมัติที่สวยงามไปวางทับกระบวนการที่จริง ๆ แล้วควรถูกแก้ตั้งแต่ต้น
สามแบบ ภายใต้ชื่อเดียวกัน
ไม่มีแบบไหนผิด ทั้งสามคือคำตอบของคำถามคนละข้อ และการจับคู่ผิดต่างหากที่ทำให้เสียเงิน
- ผู้ติดตั้งเครื่องมือ รู้จักแพลตฟอร์มหนึ่งอย่างลึกซึ้งและตั้งค่าได้ดี ถ้ากระบวนการเข้ากับแพลตฟอร์มนั้น นี่มักเป็นทางที่สั้นที่สุดในการทำให้ใช้งานได้ แต่ถ้าไม่เข้ากัน งานจะกลายเป็นการเขียน logic เฉพาะและการดัดแปลง ซึ่งกินข้อได้เปรียบนั้นไปเกือบหมด
- สตูดิโอพัฒนาซอฟต์แวร์ทั่วไป สร้างตามที่โจทย์บอก แข็งแรงเมื่อคุณรู้ชัดแล้วว่าต้องการอะไร แต่เสี่ยงเมื่อสิ่งที่ควรถูกตั้งคำถามคือตัวโจทย์เอง
- ผู้ให้บริการที่เริ่มจากกระบวนการ จะใช้ช่วงแรกของงานทำความเข้าใจว่างานเดินอย่างไรก่อนเสนออะไร และบางข้อเสนอของเขาจะไม่ใช่ซอฟต์แวร์ ช่วงสำรวจนี้กินเวลาช่วงต้น และไม่จำเป็นเลยถ้าสิ่งที่คุณต้องการมีแค่การเชื่อมต่อแบบมาตรฐานระหว่างเครื่องมือสองตัว
ห้าคำถามที่ช่วยแยกแยะ
- ขอให้เล่าเคสที่เขาสรุปว่าไม่คุ้มที่จะทำให้อัตโนมัติ คำตอบจะบอกคุณว่าเขาใช้อะไรตัดสินว่าอะไรควรถูกสร้างขึ้นมา
- ใครเป็นเจ้าของบัญชี โค้ด และระบบอัตโนมัติ ในวันที่เราเลิกทำงานด้วยกัน ขอคำตอบก่อนเซ็นสัญญา ไม่ใช่ตอนจบงาน
- อะไรจะพังเมื่อระบบอีกฝั่งเปลี่ยน คนที่เคยดูแลการเชื่อมต่อระบบจริงควรบอกได้ว่าเขาเฝ้าดูอะไร เคยมีการเปลี่ยนแปลงฝั่งต้นทางแบบไหนที่ทำให้พัง และเกิดอะไรขึ้นเมื่อการซิงก์ล้มเหลว
- เล่าเคสที่ผิดพลาดให้ฟังหน่อย คำตอบที่มีประโยชน์จะรวมถึงสิ่งที่เขาเปลี่ยนหลังจากนั้น
- คุณจะทำงานบนเครื่องมือที่เราใช้อยู่ หรือจะย้ายเราไปใช้ของคุณ ทั้งสองแบบมีเหตุผลได้ แต่คุณควรรู้ว่ากำลังคุยเรื่องไหนอยู่
รูปแบบราคาแต่ละแบบให้รางวัลกับอะไร
ราคาเหมาแบบขอบเขตตายตัวใช้ได้ดีเมื่อรู้ความต้องการล่วงหน้าจริง ๆ แต่ถ้ายังต้องค้นหาความต้องการสำคัญระหว่างทาง ทุกสิ่งที่ค้นพบใหม่ก็เสี่ยงจะกลายเป็นการเถียงเรื่องขอบเขต
การคิดเป็นรายวันเหมาะกว่าเมื่อขอบเขตงานยังมีความไม่แน่นอนจริง แต่คุณต้องอยู่ร่วมตลอด เพราะไม่มีอะไรมาจำกัดยอดรวม ส่วนค่าดูแลรายเดือนอธิบายได้ง่ายที่สุดเมื่อมีระบบใช้งานจริงที่ต้องดูแลและพัฒนาต่อ ถ้ายังไม่มี ค่าดูแลรายเดือนก็ต้องมีเป้าหมายและสิ่งส่งมอบที่ชัดเจนมาก
ระวังการคิดราคาผูกกับชั่วโมงที่ประหยัดได้ ฟังดูเหมือนผลประโยชน์ตรงกัน แต่มันอาจให้รางวัลกับการทำอัตโนมัติในส่วนที่วัดง่ายที่สุด มากกว่างานที่สร้างคุณค่าจริง และคุณจะเสียเวลาส่วนหนึ่งไปกับการเถียงว่าจุดตั้งต้นคือเท่าไร
เมื่อไรที่ไม่ควรจ้างใครเลย
- คุณต้องการแค่การเชื่อมต่อเดียวระหว่างเครื่องมือยอดนิยมสองตัว ลองดูการเชื่อมต่อที่มีมาในตัวและเครื่องมือ no-code ทั่วไปก่อน ถ้ามีตัวไหนรองรับเวิร์กโฟลว์นั้นได้อย่างน่าเชื่อถือ ก็ไม่มีโปรเจกต์ที่ต้องจ่ายเงิน
- มีผลิตภัณฑ์สำเร็จรูปที่ทำเรื่องนี้ได้อยู่แล้ว และสิ่งที่คุณติดคือค่าสมาชิกรายเดือน ลองเทียบค่าสมาชิกกับต้นทุนการสร้างบวกค่าดูแล ก่อนสรุปว่าการสร้างเองถูกกว่า
- มีคนในทีมที่ใกล้จะแก้ได้แล้ว และสิ่งที่ต้องการหลัก ๆ คือทิศทางเชิงเทคนิค ให้ซื้อความช่วยเหลือเฉพาะจุดนั้น แทนการยกงานทั้งก้อนออกไปข้างนอก
- กระบวนการกำลังจะเปลี่ยน โดยทั่วไปการรอไว้ก่อนคุ้มกว่า ดีกว่าไปฝังการตัดสินใจที่คุณรู้อยู่แล้วว่าเป็นเพียงชั่วคราว
เราอยู่ตรงไหน
วิธีทำงานของเราใกล้เคียงกับแบบที่สามมากที่สุด งานเริ่มจากกระบวนการ ไม่ใช่จากแพลตฟอร์ม และสิ่งที่ส่งมอบชิ้นแรกมักเป็นแผนผังกระบวนการพร้อมตัวเลข ไม่ใช่ซอฟต์แวร์ที่ใช้งานได้
สำหรับ Mutualys ซึ่งเป็นกลุ่มธุรกิจประกันสุขภาพ ผลลัพธ์คือ CRM ที่พัฒนาขึ้นเองและแชตบอต WhatsApp เพราะการดูแลลูกค้ามุ่งหวังกระจายอยู่ในอีเมล บันทึกการโทร และสเปรดชีต และเครื่องมือสำเร็จรูปที่เราพิจารณาไม่ตรงกับวิธีคัดกรองและติดตามลูกค้าของพวกเขา ส่วนงานที่จบลงด้วยการเปลี่ยนการตั้งค่าแทนการสร้างระบบ ก็เป็นผลลัพธ์ที่เรารับได้ไม่ต่างกัน