การเงินแบบอไจล์
ผลกระทบต่อการเงินที่ผมมักพบเจอในองค์กรที่ทำ Agile transformation คือ project มีขนาดเล็กลง แต่มีจำนวนมากขึ้นอย่างยิ่งยวด เมื่อก่อนเวลาจะทำอะไรใหญ่ ๆ ต้องขอเงินก้อนใหญ่ ทำให้ต้องทำ proposal ยิ่งใหญ่เพื่อเอาแผนไปให้ผู้บริหารระดับสูง อนุมัติการใช้เงินก้อนใหญ่นี้
ใคร ๆ ก็รู้ว่า project ใหญ่ ๆ มาพร้อมกับความเสี่ยงที่มากตามไปด้วย ไม่มีใครอยากไปสัญญาเป็นมั่นเหมาะให้ผู้บริหารระดับสูงจำหน้าได้ แล้วไปอธิบายตอน project delay หรอก ท่าหนึ่งที่จะเห็นบ่อย ๆ คือ การแตก project ใหญ่ ๆ ออกเป็น project ย่อย ๆ แล้วขอเงินก้อนเล็ก ๆ สำหรับ project ย่อย ๆ เหล่านี้แทน
เสียอำนาจ
ปัญหาจากมุมมองทางการเงินคือ ผู้บริหารระดับสูงเสียอำนาจในการตัดสินใจอนุมัติเงินที่ใช้แทน เพราะมาเต็มไปหมดเลยเหมือนน้ำซึมบ่อทราย มาขอทีละนิด ๆ แต่มาหลาย ๆ รอบ พอรวมกันจริง ๆ มันเยอะมาก ดูอันเล็ก ๆ ก็ไม่น่าปฏิเสธ แต่พอเอามารวมกันแล้วเยอะขนาดนี้ อยากจะปฏิเสธ อ้อยก็เข้าปากช้างไปถึงไหนต่อไหนแล้ว แล้วทุก project ก็เคลมของเหมือน ๆ กัน คือ เพิ่มยอดขาย, ลดค่าใช้จ่ายในการดำเนินการ, สร้างชื่อเสียง ผลลัพธ์ที่เอามาเคลมตอนจบ project ก็มาซ้ำ ๆ สุดท้ายการเงินต้องมานั่งเกาหัวว่า ไอ้ที่ขอเงินไปลด operation cost 10 projects นี่ project ไหนมันทำให้ลด cost ไปเท่าไหร่นะ เล่นเคลมมารวม ๆ แบบนี้แล้วชั้นจะรายงานสรุปหัวหน้า / region / head quarter ยังไง
งานเยอะขึ้น
นอกจากจะเสียอำนาจในการตัดสินใจแล้ว แต่ละ project มีเอกสารทางการเงินที่ต้องทำเป็น overhead ของแต่ละ project อยู่ พอปริมาณ project เพิ่มขึ้นมหาศาลแบบนี้ การเงินก็ยุ่งหัวไม่วางหางไม่เว้นเลย เพราะงานเอกสารเยอะมาก แค่ไล่ถามว่า project เหล่านี้ในแผนบอกว่าต้องเริ่มแล้ว ทำไมยังไม่เห็นใช้เงิน หรือ project นี้ในแผนบอกว่าต้องจบแล้ว ทำไมยังเหลือเงินอยู่อีกแค่นี้ก็ไม่ต้องทำอะไรกินแล้ว
ที่เป็นแบบนี้เพราะแต่ละอไจล์ทีมก็ขอเงินเผื่อไว้ในแต่ละ project แถมยังขอเงินล่วงหน้าอีก เพราะจำเป็นต้องมีเงินมาหล่อเลี้ยงทีมและคนจองตัวเองไว้ เพราะถ้าเงินสะดุดเมื่อไหร่ ก็กลัวว่าคนจะหายไปหมด แล้วใครจะทำงานต่อ? การทำแบบนี้ทำให้อไจล์ทีมต่าง ๆ ต้องตัดสินใจล่วงหน้าว่าจะทำอะไรก่อนที่จะได้ inspect สถานการณ์จริงของผลิตภัณฑ์ที่ตัวเองสร้างและสภาพตลาด เพราะการขอเงินมันมี lead time ที่ทำให้เค้าขยับตัวช้าถ้ารอ inspect แล้วค่อยมาขอมันไม่ทันกิน
ถ้าลงมาดูหน้างานจริง ๆ จะเห็นว่า ส่วนใหญ่สิ่งที่ทีมทำมันสอดคล้องกับแผนที่วางไว้ตอนขอเงินแค่ 50–80% เท่านั้น นี่สำหรับทีมที่ไม่เจอความเปลี่ยนแปลงเท่าไหร่แล้วนะ มันจะมีการหยิบยืมเงินโปรเจคนี้ไปจ่ายเรื่องนั้นเต็มไปหมด แล้วการเงินจะไม่ได้รับรู้เลยว่าจริง ๆ แล้ว project ไหนเลื่อน, project ไหนเกินงบ, project ไหนงบเหลือ ไปรู้อีกทีผลายปีตอนรวบเงินกลับเพื่อสรุปบัญชีโน่น
แก้ปัญหายังไงดี
หนังสือ The DevOps Handbook มีหัวข้อหนึ่งแนะนำว่า ให้เปลี่ยนกลยุทธ์การ Funding จากการลงทุนเป็น project ให้ไปลงทุน product และ service แทน
การเปลี่ยนแบบนี้จะทำให้งานเอกสารทางการเงินลดลงทันที เพราะ ไอ้ที่ขอมาเป็นสิบ projects นั้น มันมาจาก product เดียวเท่านั้นแหละ ปัญหาเรื่องเคลมผลงานซ้ำซ้อนก็จะหายไปด้วย
หลายคนก็อาจจะกังวลว่า งั้นชั้นก็ไม่ได้ตัดสินใจว่าเค้าจะทำอะไรหน่ะสิ คำตอบคือใช่ การที่เราฟอร์มทีมมาดูแล product หรือ service หนึ่ง ๆ นั้น เพื่อให้เค้าอยู่ใกล้ชิดลูกค้าหรือตลาด แล้วตอบสนองได้ทัน ให้เค้าตัดสินใจเองว่าจะทำอะไรจากสิ่งที่เค้าเห็นหน้างานดีแล้ว ไม่ต้องกลับมา report การเงินหรอก เราจะ fund เป็นทีมแทน ทีมไหนที่ทำประโยชน์ให้องค์กรได้ ก็จะมี fund แยะหน่อย ทีมไหนที่ไม่ค่อยมีประโยชน์ อาจจะแปลว่าตลาดไม่เหลือพื้นที่สำหรับ product หรือ service นั้นแล้ว ก็ให้ทีมไปโฟกัสอย่างอื่น แบบนี้จะลดพวกการของบเผื่อ เอาเงินไปอมไว้แต่ไม่ใช้ได้ แล้วแบบเดิมที่ขอเป็น project เล็ก ๆ การเงินก็ไม่มีโอกาสได้ปฏิเสธการใช้เงินอยู่ดี เราแค่ปรับให้มันเข้ากับธรรมชาติมากขึ้น ทั้งการเงินทั้งทีมจะได้ไม่เจ็บปวด
ผลพลอยได้ที่สำคัญมาก จากการปรับแบบนี้ เอาจริง ๆ เป็นเจตนาหลักที่หนังสือแนะนำให้ปรับเลยคือ ทีมจะได้อยู่ยั่งยืนยาวขึ้น ไม่ต้องแยกย้ายกันไปเพราะเงินหมด ซึ่งเปิดโอกาสให้ทีมได้เห็นผลลัพธ์ของงานออกแบบที่ตัวเองทำไปใน product หนือ service ว่าแบบไหนดูแลง่าย แบบไหนดูแลยากแล้วจะได้เรียนรู้ เพราะ feedback เหล่านี้บางครั้งมันใช้เวลาเป็นปี กว่าจะกลับมาถึงทีม และการที่ทีมสลายตัวกันไปก่อน ก็จะไม่ได้เรียนรู้ตรงนี้ ทำให้ออกแบบผิด ๆ ซ้ำ ๆ แล้วก็เกิดปัญหาซ้ำ ๆ ให้คนอื่นแก้ องค์กรเลยไม่ไปไหนสักที
บ่อยครั้งเวลาผมสอนอไจล์ จะได้ยินคำถามจากการเงินว่า องค์กรเราทำอไจล์ แต่ชั้นไม่ได้อยู่ไอทีนะ อยู่การเงิน มันเกี่ยวกับชั้นไหม เกี่ยวตรงนี้แหละ ตรงที่เล่าในบทความ ปัญหาคือ ตอนเปลี่ยนแปลง (ตอนเกี่ยว) มันอาจจะเปลี่ยนช้า ๆ เราเลยเหมือนกบที่โดนตุ๋นไปช้า ๆ จำนวน project มันจะค่อย ๆ เพิ่ม ขนาดมันจะค่อย ๆ เล็กลง เราเลยไม่รู้ตัว ผ่านไปสองปี รู้ตัวอีกทีก็ยุ่งหัวไม่วางหางไม่เว้นแล้ว
ใครที่เห็นแพทเทิร์นของปัญหาแบบนี้ในการเงินขององค์กรตัวเอง ลองปรับไป fund เป็น product หรือ service ดูนะครับ องค์กรเราอาจจะต้องมีมากกว่า 1 กลยุทธ์ในการทำ funding เพื่อรองรับลักษณะงานที่มีความเสี่ยงหรืองาน innovation
ทำสิ่งที่สอดคล้องกับธรรมชาติจะทำได้ยั่งยืนครับ
