Forward Deployed ERP
เมื่อ Implementation ไม่ได้เป็นแค่การนำ ERP ไปติดตั้ง
ช่วงหลัง ๆ ผมมีเรื่องหนึ่งที่คิดวนอยู่บ่อย ๆ
อาจเป็นเพราะช่วงนี้ผมกำลังคิดเรื่อง implementation เยอะเป็นพิเศษ แต่ยิ่งคิดก็ยิ่งรู้สึกว่า สิ่งที่เราเรียกว่า “การวางระบบ ERP” อาจกำลังเปลี่ยนความหมายไปโดยที่เราไม่ทันสังเกต
เรื่องเริ่มจากการคุยกับหัวหน้าทีมเกี่ยวกับลูกค้ารายหนึ่ง
เป็นกิจการที่เติบโตเร็วมากในช่วงไม่กี่ปีที่ผ่านมา เร็วจนระบบการทำงานเดิมเริ่มรับไม่ไหว
ฟังเผิน ๆ ปัญหานี้ดูเหมือนปัญหาที่ ERP น่าจะเข้ามาแก้ได้
แต่พอกลับมาคิด ผมกลับรู้สึกว่ามันเป็นสถานการณ์ที่ค่อนข้างอันตราย
เพราะการเปลี่ยน ERP ตอนที่ธุรกิจกำลังโตอย่างรวดเร็ว ก็คล้ายกับ การพาผู้โดยสารเปลี่ยนรถในขณะที่รถกำลังเร่งความเร็ว
และผู้โดยสารในที่นี้ไม่ใช่แค่ข้อมูล
แต่คือคนที่กำลังทำงานอยู่ในระบบทั้งหมด
เรามักคิดว่า Software เป็นตัวแปรเดียว
เวลาเจอองค์กรที่ระบบเดิมเริ่มมีปัญหา เรามักคิดเป็นลำดับง่าย ๆ
ธุรกิจโต → ระบบเดิมไม่ไหว → เปลี่ยน ERP → ปัญหาจบ
แต่ในชีวิตจริง การเปลี่ยน ERP ไม่ได้เปลี่ยนเฉพาะ software
มันเปลี่ยนวิธีทำงาน
เปลี่ยนความรับผิดชอบ
เปลี่ยนลำดับขั้นตอน
เปลี่ยนสิ่งที่คนเคยรู้
และบางครั้งเปลี่ยนสิ่งที่คนในองค์กรเคย “ตกลงกันโดยไม่เคยเขียนไว้”
ทั้งหมดนี้เกิดขึ้นพร้อมกับช่วงเวลาที่ธุรกิจกำลังโต
ผมจึงเริ่มคิดว่า บางครั้ง การเปลี่ยน ERP อาจเป็นสิ่งที่ถูกต้อง แต่จังหวะที่เปลี่ยนต่างหากที่อาจผิด
และนั่นทำให้ผมเริ่มมอง implementation ในอีกแบบหนึ่ง
“ยังไม่เปลี่ยน” อาจเป็นส่วนหนึ่งของแผนเปลี่ยน
ถ้าเป็นลูกค้าของเรา ผมอาจไม่เสนอให้รื้อทุกอย่างในครั้งเดียว
แต่แบ่งเป็นหลายระยะ
ระยะแรก อะไรที่ยังใช้ได้และเป็นสิ่งที่องค์กรรู้จักดี ก็พยายามคงไว้ก่อน
อะไรที่เป็นจุดอ่อนและกำลังสร้างปัญหา ค่อยเติมเข้าไป
ส่วนอะไรที่เป็นช่องทางใหม่หรือวิธีทำงานใหม่ ก็แยกออกมาทดลอง
พูดง่าย ๆ คือ
รักษาสิ่งที่รู้แล้ว เติมสิ่งที่ขาด แยกสิ่งที่ยังไม่รู้ไปทดลอง
ผมชอบแนวคิดนี้เพราะมันไม่ได้มอง implementation เป็นแค่การ “เปลี่ยนระบบ”
แต่มองว่ามันเป็นช่วงเวลาที่ทั้งลูกค้าและทีมวางระบบกำลัง เรียนรู้ไปพร้อมกัน
และบางครั้งสิ่งที่เราต้องซื้อไม่ใช่ software เพิ่ม
แต่คือ เวลา
เวลาให้คนปรับตัว
เวลาให้ธุรกิจเห็นว่าช่องทางใหม่จะโตจริงหรือไม่
และเวลาให้เราเข้าใจว่า ปัญหาที่เห็นในวันนี้เป็นปัญหาจริง หรือเป็นเพียงอาการของช่วงที่ธุรกิจกำลังโต
เรื่องนี้ทำให้ผมนึกถึง Palantir
ผมเคยอ่านเรื่อง Forward Deployed Engineer หรือ FDE ของ Palantir
สิ่งที่สะดุดใจผมไม่ใช่ตัวตำแหน่งงาน แต่เป็นวิธีคิดที่อยู่ข้างหลัง
Palantir ไม่ได้มองว่าการนำ software ไปใช้กับลูกค้าเป็นขั้นตอนสุดท้าย หลังจาก product development จบแล้ว
คนที่อยู่หน้างานสามารถเข้าไปทำงานกับปัญหาจริง สร้าง solution ทดลอง และนำสิ่งที่พบกลับไปพัฒนา product
มันมีวงจรประมาณว่า
เข้าใจ → สร้าง → นำไปใช้ → สังเกต → เรียนรู้ → สร้างใหม่
ผมอ่านแล้วรู้สึกคุ้น ๆ
เพราะคนทำ ERP ก็ทำอะไรแบบนี้อยู่แล้ว
เวลาไปเจอลูกค้า เราไม่ได้เจอแค่ requirement
เราเจอความจริง
และความจริงหลายอย่างไม่เหมือนที่เขียนอยู่ในเอกสาร requirement เสมอไป
แต่ ERP ของเรามีโจทย์ที่ต่างจาก Palantir
ตรงนี้ผมคิดว่าสำคัญ
Palantir ทำงานกับ Large Enterprise และ economics ของเขาทำให้การมีคน engineering เข้าไปทำงานใกล้ลูกค้าเป็นเวลานานมีเหตุผล
แต่ ERP ที่เป็น Subscription และรวม Implementation อยู่ในค่าบริการ มีโจทย์อีกแบบ เราไม่สามารถส่งคนเก่งไปนั่งกับลูกค้าทุกรายเป็นเวลาหลายเดือนแล้วหวังว่าจะ scale ได้
ดังนั้นคำถามที่ผมสนใจจึงไม่ใช่
“เราจะมี FDE แบบ Palantir ได้อย่างไร?”
แต่เป็น
“เราจะเอาวิธีคิดแบบ FDE มาออกแบบ ให้เข้ากับ economics ของ ERP Subscription ได้อย่างไร?”
ผมคิดว่าคำตอบน่าจะไม่ได้อยู่ที่การเพิ่มคน
แต่อยู่ที่ การทำให้ implementation กลายเป็นส่วนหนึ่งของ product
Implementation เป็น Product ได้หรือเปล่า?
เราคุ้นกับการคิดว่า
Software = Product Implementation = Service
แต่ถ้า ERP ของเรารวม implementation อยู่ใน subscription ตั้งแต่ต้น ผมเริ่มสงสัยว่าเรายังควรแยกสองสิ่งนี้ทางความคิดอยู่หรือไม่
เพราะลูกค้าไม่ได้ซื้อ software อย่างเดียว เขาซื้อความสามารถในการทำให้ software นั้น กลายเป็นระบบที่ใช้กับธุรกิจของเขาได้
ถ้าอย่างนั้น implementation ก็น่าจะเป็น ความสามารถหนึ่งของ product
และถ้าเราคิดแบบนี้ จะเกิดคำถามต่อทันทีว่า
ถ้าเรา implement ลูกค้ารายหนึ่งเสร็จแล้ว ลูกค้ารายถัดไปควรได้ประโยชน์อะไรจากประสบการณ์ครั้งนั้น?
ถ้าคำตอบคือ “ไม่มี”
เราก็แค่ทำ project สำเร็จไปอีกหนึ่ง project
แต่ถ้าคำตอบคือ
เรารู้วิธีจัดการธุรกิจประเภทนี้ดีขึ้น เรามี configuration pattern เพิ่มขึ้น เรารู้ว่าอะไรไม่ควรทำ เรามี prototype ที่นำกลับมาใช้ได้ เรารู้ว่าปัญหาแบบนี้มักเกิดจากอะไร
ผมคิดว่านั่นเริ่มเป็นอีกเรื่องหนึ่ง
สิ่งที่เราควรสร้าง คือ “ความสามารถในการ Implement”
คำว่า customize ได้ เป็นคำที่เราใช้กันจนชิน
แต่ผมเริ่มรู้สึกว่ามันอาจไม่ใช่คำที่ดีที่สุดสำหรับ ERP รุ่นใหม่
เพราะ customize ได้ อาจหมายถึง
“ลูกค้าต้องการอะไร เราก็ยอมทำเพิ่มให้”
แต่สิ่งที่ผมสนใจกว่าคือ
ทุกครั้งที่เรา implement ลูกค้า เราเรียนรู้บางอย่าง ที่ทำให้การ implement ครั้งต่อไปง่ายขึ้นหรือไม่?
ถ้าใช่ นั่นคือ implementation ที่กำลังกลายเป็น product capability
ผมยังไม่มีคำที่ดีกว่านี้ แต่ตอนนี้ผมชอบคำว่า
Productized Implementation
มากกว่าคำว่า “customization”
เพราะมันเปลี่ยนคำถามจาก
เราจะทำตามลูกค้าได้มากแค่ไหน?
เป็น
เราจะเรียนรู้จากลูกค้าได้มากแค่ไหน โดยไม่ต้องเริ่มใหม่ทุกครั้ง?
แล้วผู้วางระบบอยู่ตรงไหน?
ตรงนี้ผมกลับมาคิดถึงบทบาทของ “ผู้วางระบบ” ที่เรามีกันอยู่ใน ERP
ผู้วางระบบที่ดีไม่ได้เป็น programmer ที่เก่งที่สุด
แต่ต้องฟังภาษาธุรกิจออก
เข้าใจ logic
เห็นความสัมพันธ์ของข้อมูล
และแปลงสิ่งเหล่านั้นกลับมาเป็น configuration หรือวิธีทำงานในระบบ
ถ้ามองแบบนี้ ผู้วางระบบอยู่ตรงจุดที่น่าสนใจมาก
เขาอยู่ระหว่าง
Product กับ Reality
เขาเห็นทั้งสองฝั่ง
และผมคิดว่าเราอาจกำลังใช้คนกลุ่มนี้ไม่เต็มศักยภาพ
เพราะถ้ามองเขาเป็นเพียง “คน configure ระบบ” เราก็จะวัดเขาด้วยว่า
ตั้งค่าเสร็จหรือยัง?
แต่ถ้ามองเขาเป็นคนที่อยู่หน้าแนวรบของ product เราอาจต้องถามเพิ่มว่า
เขาเห็นอะไรที่ทีมพัฒนายังไม่เห็น? เขาพบ pattern อะไรที่เกิดซ้ำในหลายธุรกิจ? อะไรที่วันนี้ต้องใช้คนอธิบาย แต่วันหนึ่งควรกลายเป็น capability ของ product?
แต่เราก็ควรระวังตัวเอง
เพราะถ้าคิดมาถึงตรงนี้ เราอาจเผลอพูดว่า
“ผู้วางระบบต้องเข้าไปแนะนำลูกค้าว่าควรปรับองค์กรอย่างไร”
ผมกลับไม่แน่ใจว่าใช่
ก่อนหน้านี้ผมเคยคิดเรื่องนี้กับลูกค้ารายหนึ่งที่กำลังโตเร็ว และพบว่าการเสนอ “ปรับโครงสร้างองค์กร” อาจเกิน boundary ของผู้วางระบบ
เจ้าของกิจการอาจมีเหตุผลที่เราไม่รู้
คนบางคนอาจมีความสำคัญต่อธุรกิจมากกว่าที่ organization chart บอก
บาง process อาจดูไม่มีเหตุผลจากข้างนอก แต่มีประวัติของมัน
และบางครั้งเรื่องที่ดูเหมือนปัญหาของ process อาจจริง ๆ แล้วเป็นเรื่องของความไว้วางใจ
ผมจึงเริ่มคิดว่า ผู้วางระบบอาจไม่จำเป็นต้องเป็นคนที่ตอบทุกคำถาม
บางครั้งเขาอาจทำหน้าที่เหมือน กระจก
ทำให้เจ้าของเห็นว่า
“ถ้าธุรกิจโตไปอีกสามเท่า สิ่งนี้จะเกิดอะไรขึ้น?”
จากนั้นคนที่ตัดสินใจว่าจะเปลี่ยนหรือไม่เปลี่ยน ยังคงเป็นเจ้าของ
จาก Consulting อาจมีพื้นที่สำหรับ Coaching
ตรงนี้ผมยังคิดต่ออยู่
Consulting แบบดั้งเดิมมีลักษณะว่า
“ผมเคยเห็นธุรกิจแบบนี้มาแล้ว ..และผมรู้ว่าคุณควรทำอะไร”
มันมีประโยชน์มาก โดยเฉพาะเมื่อปัญหาเป็นเรื่องที่มี pattern ชัดเจน
แต่สำหรับเรื่องที่มีบริบทเฉพาะองค์กรสูง ผมกลับรู้สึกว่าอีกวิธีหนึ่งน่าสนใจ
“ผมจะช่วยให้คุณเห็นสิ่งที่เกิดขึ้น ..แล้วเราค่อยค้นหาคำตอบด้วยกัน”
ไม่ใช่เพราะผู้วางระบบไม่มีความรู้
แต่เพราะ ไม่มีใครรู้จักองค์กรนั้นได้เท่าคนในองค์กร
นี่ทำให้ผมนึกถึงคำว่า
Know Thyself
ขึ้นมา
และจากคำนี้ก็เกิดคำเล่น ๆ ที่ผมยังไม่แน่ใจว่าจริงจังแค่ไหน
Enterprise Resource Awareness
ERP ในฐานะกระจก
เราอาจคุ้นกับคำว่า Enterprise Resource Planning
แต่ก่อนจะวางแผน เราต้องรู้ก่อนว่าเกิดอะไรขึ้น
ERP มี transaction ที่เกิดขึ้นจริงทุกวัน
มันรู้ว่า order ไหนมาจากไหน
ของอยู่ตรงไหน
ลูกค้ากลุ่มไหนซื้ออะไร
งานติดอยู่ที่ใด
กระบวนการไหนเกิดซ้ำ
และเมื่อเวลาผ่านไป มันมีความทรงจำขององค์กรเพิ่มขึ้นเรื่อย ๆ
ความรู้นี้ไม่เหมือนตำรา
ไม่เหมือน best practice
และไม่เหมือนสิ่งที่ consultant เอามาจากบริษัทอื่น
มันคือ
“ความจริงเฉพาะของเรา”
AI อาจรู้ว่า warehouse ที่ดีควรเป็นอย่างไร
consultant อาจรู้ว่าองค์กรทั่วไปแก้ปัญหาแบบนี้อย่างไร
แต่มีเพียงระบบของเราที่รู้ว่า
“องค์กรนี้กำลังเป็นอะไรอยู่”
นี่อาจเป็นพื้นที่ที่ ERP ยุค AI มีคุณค่ามากขึ้นก็ได้
เมื่อ AI รู้ทุกอย่าง องค์กรอาจยิ่งต้องรู้จักตัวเอง
ผมคิดว่ามี paradox อยู่ตรงนี้
ยิ่ง AI เข้าถึงความรู้ทั่วไปได้มากเท่าไร ความรู้ทั่วไปก็ยิ่งมีมูลค่าลดลง
เรา
ถาม AI ได้ว่า
warehouse ควรออกแบบอย่างไร
ถามได้ว่า
inventory policy มีแบบไหน
ถามได้ว่า
ERP implementation ควรทำอย่างไร
แต่คำถามว่า
“แล้วบริษัทของผมกำลังเกิดอะไรขึ้น?”
ยังต้องอาศัยข้อมูลของบริษัทนั้น
นี่ทำให้ผมเริ่มมองว่า AI กับ ERP อาจมีบทบาทที่ต่างกัน
AI รู้โลก
ERP รู้เรา
และบางที value ที่เกิดขึ้นจะอยู่ตรงกลาง
ERP สะท้อนสิ่งที่เกิดขึ้น AI ช่วยตีความสิ่งที่เห็น มนุษย์ตัดสินใจว่าจะทำอะไร
แล้ว FDE ก็กลับเข้ามาในภาพอีกครั้ง
ถ้าลองเอาทั้งหมดมารวมกัน ผมเริ่มเห็นวงจรหนึ่ง
ผู้วางระบบเข้าไปดูธุรกิจ
→ ระบบสะท้อนสิ่งที่เกิดขึ้น
→ AI ช่วยวิเคราะห์
→ คนตั้งสมมติฐาน
→ ทดลอง configuration หรือ workflow ใหม่
→ ดูผลที่เกิดขึ้นจริง
→ เรียนรู้
→ สิ่งที่เรียนรู้กลับไปเป็น product capability
นี่คล้าย FDE ในแง่ของ feedback loop
แต่ต่างกันตรงที่เราไม่สามารถใช้คนแบบ Palantir กับลูกค้าทุกคนได้
เราจึงต้องพยายามทำให้วงจรนี้
scale ได้ด้วย product และ AI
นี่อาจเป็นสิ่งที่น่าสนใจกว่า “เอา FDE มาใช้กับ ERP” เสียอีก
คือ
Productize the FDE mindset
ผมยังไม่แน่ใจว่าควรเรียกมันว่าอะไร
ตอนนี้ผมยังไม่อยากรีบสรุปว่ามันคือ methodology ใหม่
หรือเป็น architecture ใหม่
หรือควรเรียกมันว่า Forward Deployed ERP
ผมเองยังอยู่ในช่วงทดลองคิด
แต่สิ่งหนึ่งที่ผมเริ่มเชื่อคือ
Implementation ไม่ควรเป็นช่วงเวลาที่ product ถูกนำไปใช้แล้วจบ
มันควรเป็นช่วงเวลาที่ product ได้เห็นโลกจริง
และถ้าเราเป็น ERP ที่มี implementation รวมอยู่ใน subscription ความสัมพันธ์นี้ยิ่งน่าสนใจ
เพราะเรามีโอกาสสร้างวงจรว่า
ลูกค้ารายหนึ่งทำให้เราเข้าใจอะไรบางอย่าง ความเข้าใจนั้นทำให้ product ดีขึ้น product ที่ดีขึ้นทำให้ลูกค้ารายถัดไปขึ้นระบบง่ายขึ้น
ถ้าวงจรนี้เกิดขึ้นจริง
Subscription ก็ไม่ได้เป็นเพียงวิธีคิดค่าบริการ
แต่มันกลายเป็น กลไกของการเรียนรู้ระยะยาว
จาก “ติดตั้ง ERP” ไปสู่ “เรียนรู้ไปพร้อมกับธุรกิจ”
บางทีเราอาจต้องเลิกคิดว่าเป้าหมายของ implementation คือ
Go-live
เพราะ go-live เป็นเพียงจุดหนึ่งของการเดินทาง
สิ่งที่น่าสนใจกว่าคือ หลังจาก go-live แล้ว
เรารู้จักธุรกิจนี้มากขึ้นหรือยัง? ลูกค้ารู้จักตัวเองมากขึ้นหรือยัง? เรารู้แล้วหรือยังว่าอะไรควรเป็น standard และอะไรควรเป็นความแตกต่างของเขา? สิ่งที่เราเรียนรู้ครั้งนี้กลับไปทำให้ product ดีขึ้นหรือยัง?
และบางทีคำถามที่ผมอยากฝากเพื่อน ๆ ในวงการ ERP ไว้มากที่สุดคือ
ถ้า implementation ทุกครั้งจบลงพร้อมกับ project แล้วความรู้ที่เกิดขึ้นระหว่างทาง หายไปกับทีม implementation เรากำลังสร้าง product อยู่จริง ๆ หรือแค่ส่งมอบ project ทีละราย?
ผมยังไม่มีคำตอบที่สมบูรณ์สำหรับคำถามนี้
แต่ยิ่งคิดเรื่องนี้มากขึ้น ผมยิ่งรู้สึกว่า ERP ในยุคต่อไปอาจไม่ได้แข่งขันกันแค่เรื่อง feature
แต่อาจแข่งขันกันที่ว่า
ใครสามารถเปลี่ยนประสบการณ์ จากการทำงานกับลูกค้า ให้กลายเป็นความสามารถของ product ได้เร็วกว่า
และถ้าเป็นเช่นนั้น
Implementation อาจไม่ได้อยู่ปลายทางของ Software Product
แต่มันอาจเป็นส่วนหนึ่งของวงจร ที่ทำให้ Software Product เรียนรู้ว่าควรกลายเป็นอะไรต่อไป
ความคิดเห็น