จากประสบการณ์ที่ผ่านมา เราพบว่าองค์กรต่างๆ มักทดลองใช้อไจล์ โดยเริ่มต้นที่แผนกไอที โดยเฉพาะฝ่ายพัฒนาซอฟต์แวร์ (Software Development) ซึ่งนั่นไม่น่าแปลกใจเท่าใดนัก เพราะในปี 2001 ที่เหล่ากูรูด้านการพัฒนาซอฟต์แวร์ได้รวมตัวกันเพื่อประกาศคำแถลงอุดมการณ์แห่งอไจล์ (Agile Manifesto) ซึ่งได้ประกาศชัดเจนว่า มีการค้นพบวิธีการใหม่ในการพัฒนาซอฟต์แวร์ แต่สิ่งที่พวกเขาไม่ได้บอกกล่าวอย่างชัดเจนคือ ต้นตอของปัญหา ไม่ได้มาจากวิธีที่เราใช้ในการพัฒนาซอฟต์แวร์ หากแต่มาจากมุมมองของเราต่อการพัฒนาซอฟต์แวร์ต่างหาก
ความรู้ด้านไอทีที่เรามีอยู่ทุกวันนี้ เริ่มมาจากความพยายามที่จะสร้างเครื่องมือเพื่อช่วยในการคำนวณทางคณิตศาสตร์ที่ซับซ้อน สิ่งนี้แสดงให้เห็นได้โดยในช่วงเริ่มต้นไม่มีสถาบันการศึกษาใดเลยที่มี คณะคอมพิวเตอร์ แต่เริ่มมาจากเป็นส่วนหนึ่งของคณะวิทยาศาสตร์แทบทุกมหาวิทยาลัย ชื่อแรกของศาสตร์แห่งคอมพิวเตอร์คือ Computer Science หรือชื่อในภาษาไทยว่า วิทยาการคอมพิวเตอร์ ใช่แล้ว! คอมพิวเตอร์เป็น “ศาสตร์” เหมือนๆ กันกับ วิทยาศาสตร์ คณิตศาสตร์ ศิลปศาสตร์ หรือสังคมศาสตร์ จวบจนกระทั่ง ณ จุดหนึ่ง มีการนำ “คอมพิวเตอร์” ไปประยุกต์ใช้ในภาคธุรกิจ ในฐานะเครื่องไม้เครื่องมือ หรือแม้แต่ถูกมองเป็นเครื่องจักร เพราะในช่วงต้นนั้นเครื่องคอมพิวเตอร์เครื่องหนึ่งต้องใช้พื้นที่เพื่อจัดวางราวครึ่งชั้นเลยทีเดียว
จากการที่คอมพิวเตอร์เป็นเครื่องมือที่สลับซับซ้อน ผู้คนในภาคธุรกิจประสบความยากลำบากในการทำความเข้าใจและใช้งาน ไม่จำเป็นต้องนับไปถึงการสร้างหรือเขียนโปรแกรมซอฟต์แวร์ เพื่อใช้ควบคุมเครื่องคอมพิวเตอร์เหล่านั้นเลย หน้าที่นี้จึงตกเป็นของเจ้าหน้าที่เฉพาะทาง ที่เรียกว่า “โปรแกรมเมอร์” และเนื่องจากความซับซ้อน ความยากที่จะเข้าใจนี้เอง แผนกเฉพาะเพื่อนำคนเข้าใจยากเหล่านั้นมาอยู่รวมกันจึงเกิดขึ้น เรารู้จักกันดีในทุกวันนี้ที่มีชื่อว่า แผนกไอที (Information Technology Department)
ปัญหาจึงเกิดขึ้นด้วยความที่ คอมพิวเตอร์ เป็นศาสตร์ ไม่ใช่หน่วยของธุรกิจ ถ้าหากเราลองจินตนาการว่า บริษัทของเรา มีแผนกคณิตศาสตร์ เมื่อใครต้องการทำการคำนวณใดๆ ทางธุรกิจ จะต้องส่งให้แผนกนี้ หรือเรามีแผนกวิทยาศาตร์ การวิจัยทดลองใดๆ ก็ตามจะต้องส่งให้แผนกนี้ทำการทดลองเท่านั้น ธุรกิจของเราจะเป็นอย่างไร จะเจริญรุ่งเรืองหรือรุ่งริ่ง และประเด็นนี้เองที่เป็นรากเหง้าของปัญหาทั้งหมดในการพัฒนาซอฟต์แวร์ ที่เหล่ากูรูเหล่านั้นได้ค้นพบ นั่นคือ “การพัฒนาซอฟต์แวร์ ไม่ใช่เรื่องเฉพาะทางไอที” หากแต่เป็นศาสตร์หนึ่งที่ต้องเป็นส่วนประกอบในการพัฒนาและดำเนินการทางธุรกิจ เหมือนๆ กับที่ แผนกบัญชีใช้ความรู้ด้านคณิตศาสตร์ หรือแผนก R&D ใช้ความรู้ด้านวิทยาศาสตร์
ปัญหาของการมีแผนกไอทีแยกตัวเป็นเอกเทศ ได้ถูกแสดงออกมาให้เห็น ในรายงานที่ชื่อว่า CHAOS Report ซึ่งจัดทำเป็นประจำทุกปีโดย Standish Group รายงานนี้เป็นผลการสำรวจโครงการด้านไอที กว่า 50,000 โครงการทั่วโลก ผลการสำรวจ (รูปที่ 1) พบว่า โครงการพัฒนาซอฟต์แวร์ส่วนใหญ่ที่ได้รับการพัฒนาออกมานั้น มีถึง 43% ที่ล่าช้า เกินงบประมาณที่ตั้งไว้ หรือมีความสามารถไม่ครบตรงตามความต้องการ (Challenged) มีถึง 18% ที่ถูกยกเลิกกลางคันหรือเมื่อทำสำเร็จแล้วกลับไม่ได้นำไปใช้งานจริงเลย (Failed) และมีเพียง 39% เท่านั้นทำเสร็จทันกำหนด อยู่ในงบที่ตั้งไว้ และใช้งานได้ตรงตามความต้องการ (Successful) หรืออีกนัยหนึ่งก็คือ โครงการไอทีทั่วไปนั้นจะมีโอกาสประสบความสำเร็จจริงๆ เพียงแค่ราว 1 ใน 3 เท่านั้น!!!
ทางออกของปัญหานี้ก็คือ การรวมไอทีเข้ากับธุรกิจตั้งแต่ต้น สิ่งที่อไจล์ค้นพบคือ ทุกภาคส่วนมีความจำเป็นต้องมองเห็นภาพใหญ่ภาพเดียวกัน มีเป้าหมายเดียวกัน และทุกๆ การตัดสินใจในแต่ละภาคส่วนจะต้องกระทำเพื่อตอบสนองเป้าหมายหลักเหล่านั้น การที่จะให้ทุกคนในทุกภาคส่วนขององค์กรเห็นภาพของธุรกิจเป็นภาพเดียวกัน ตลอดจนเข้าใจและซึมซับในเป้าหมายหลักร่วมกันนั้น การทำแผนธุรกิจเป็นร้อยๆ หน้าแบบดั้งเดิม ซึ่งเป็นที่รู้กันว่าไม่มีใครอ่าน คงจะเป็นเรื่องที่ห่างไกลจากความเป็นจริง ในปัจจุบันองค์กรยุคใหม่เริ่มเข้าใจถึงสิ่งนี้ และหันมาใช้เทคนิคที่เรียกว่า Business Model Canvas
Business Model Canvas เป็นเทคนิคการทำแผนธุรกิจที่แตกต่างจากแผนธุรกิจทั่วไปแบบดั้งเดิม เพราะมีรูปแบบการทำที่กระชับและทำความเข้าใจได้ง่าย แต่ยังครอบคลุมองค์ประกอบหลักสำคัญ ในการทำธุรกิจไว้ครบถ้วน ซึ่งในบทความนี้จะนำเสนอ ตัวอย่างจากการใช้งานจริง ในการนำ Business Model Canvas มาใช้เพื่อการวางแผน และประสานงานคณะทำงานให้มีความเข้าใจในเป้าหมายเดียวกัน
ในทุกๆ ปี คณะทำงาน Agile66 ซึ่งเป็น กลุ่มสังคม (Social Community) ที่คอยผลักดันและเผยแพร่แนวคิดและหลักการของ อไจล์ในประเทศไทย จะจัดให้มีงานสัมมนาระดับนานาชาติ ในช่วงไตรมาสสุดท้ายของทุกปี ซึ่งตัวอย่างนี้นำมาจากการจัดงานครั้งล่าสุด คือ งาน Agile Tour Bangkok 2014 ในช่วงเริ่มต้นของการจัดงานในปี 2014 ที่ผ่านมานี้ หลังจากได้กลุ่มอาสาสมัครของปีนั้นแล้ว ก็จะมีการประชุมร่วมของกลุ่มเพื่อเริ่มการทำงาน (Kick-Off) ซึ่งเอกสารเดียวที่มีสำหรับการประชุมนั้นคือ Business Model Canvas
Business Model Canvas ของงาน Agile Tour Bangkok 2014 จะประกอบไปด้วยส่วนต่างๆ ดังนี้
Customer Segment – กลุ่มลูกค้าคือใคร? งานนี้เราแบ่งลูกค้าของงานสัมมนาออกเป็น 4 กลุ่มคือ ผู้ร่วมสัมมนาชาวไทย, วิทยากรที่เป็นชาวต่างชาติ, วิทยากรชาวไทย และ ผู้ให้การสนับสนุน (Sponsors)
Value Propositions – คุณค่าของสิ่งที่นำเสนอคือ? ผู้จัดงานกำหนดมุมมองว่า กลุ่มลูกค้าแต่ละกลุ่มจะได้รับคุณค่าต่างๆ กันไป ผู้ร่วมสัมมนาชาวไทยจะได้เปิดโลกทัศน์, วิทยากรที่เป็นชาวต่างชาติจะได้มาเที่ยวเมืองไทย และขยายธุรกิจ, วิทยากรชาวไทยจะได้สร้างชื่อเสียง และขยายธุรกิจ ส่วนผู้ให้การสนับสนุนจะได้มีโอกาสเสริมสร้างแบรนด์ และเพิ่มโอกาสในการรับสมัครงานจากผู้สมัคร ที่มีความสนใจในการทำงานแบบอไจล์
Channels – ช่องทางการขาย? ผ่านทางกลุ่ม Agile66 และกลุ่มอไจล์อื่นๆ, ลงบทความในสื่อ, ขายตรงไปยังองค์กร
Customer Relationships – มีช่องทางสร้างสายสัมพันธ์กับลูกค้าอย่างไร? ผู้ร่วมงานปีก่อนๆ และสื่อสังคมออนไลน์
Revenue Streams – หารายได้อย่างไร? ขายตั๋วเข้างานและเงินสนับสนุน ซึ่งแม้งานนี้จะไม่ใช่งานเพื่อแสวงหากำไร แต่ถ้าหากขาดทุนมาก ก็คงไม่สามารถดำเนินการได้
Key Resource – ทรัพยากรหลักขององค์กรคือ? กลุ่มอาสาสมัคร Agile66 ซึ่งมีทั้งที่เป็น บุคคลธรรมดา และจากนิติบุคคล
Key Activities – กิจกรรมหลักคืออะไร? ประชุมเตรียมงาน หาสปอนเซอร์ หาสถานที่ เตรียมของที่ระลึก
Key Partners – พันธมิตรหลักคือใคร? บรรดาสื่อและผู้สนับสนุนในอดีต
Cost Structure – ค่าใช้จ่ายของธุรกิจคืออะไร? ค่าอาหาร ค่าสถานที่ ค่าของที่ระลึก เงินสนับสนุนวิทยากร
ในระหว่างการจัดงาน มีการประชุมระหว่างอาสาสมัคร ถึงเรื่องการว่าจ้างทีมงานมาบันทึกวิดีโอการบรรยายของวิทยากรไว้ การย้อนกลับมาดู Customer Segments และ Value Propositions ของงานช่วยเตือนให้อาสาสมัครกลับมาที่คำถามที่ว่า เราจะบันทึกวิดีโอไปเพื่อใคร และคุ้มค่ากับการลงทุนแค่ไหน ในกรณีนี้อาสาสมัครเข้าใจตรงกันว่า เราจะบันทึกวิดีโอเพื่อให้ผู้ร่วมสัมมนาที่ไม่มีโอกาสชมการบรรยายสด ให้สามารถฟังบรรยายย้อนหลังได้ เนื่องจากมีการแบ่งงานออกเป็น 4 ห้อง ทำให้ผู้เข้าร่วมจะต้องพลาดการบรรยายในอีก 3 ห้องที่เหลือ อย่างหลีกเลี่ยงไม่ได้ อาสาสมัครจึงให้ความสำคัญกับการบันทึกเสียงของวิทยากรให้ชัดเจน มากกว่าองค์ประกอบรองอื่นๆ เช่น การตัดต่อหรือการแยกกล้องบันทึกสไลด์ การดำเนินการเช่นนี้ ช่วยให้เราได้รับผลสะท้อนที่พึงพอใจมาก ในขณะที่สามารถลดค่าใช้จ่ายไปได้หลายหมื่นบาท จากฟีเจอร์อื่นๆ ที่ถึงแม้ว่าจะเป็นการดีที่จะมี แต่หาได้ตอบสนองต่อความต้องการที่แท้จริงของกลุ่มลูกค้าไม่
ในอีกกรณีหนึ่งซึ่งเกี่ยวข้องกับการใช้ไอทีโดยตรง คือการทำเว็บไซต์ประชาสัมพันธ์งาน การออกแบบก็ล้อกับ Value Propositions ของ Customer Segments ต่างๆ เช่น โลโก้ของผู้สนับสนุนต้องโดดเด่นชัดเจนเพราะเขาต้องการเสริมสร้างแบรนด์ ผู้ร่วมสัมมนาต้องสามารถหาข้อมูลได้ง่ายว่าวิทยากรเป็นใครจะมาพูดหัวข้ออะไร โดยการที่เราสามารถกำหนดเป้าหมายหลักของงานได้เช่นนี้ ทำให้อาสาสมัครที่รับผิดชอบในการทำเว็บไซต์ มีความคล่องตัว (Agility) ในการทำงานอย่างสูง เนื่องเพราะสามารถดำเนินการตัดสินใจต่างๆ เกี่ยวกับเว็บไซต์ได้เอง (Decentralized / Self-Organized) โดยไม่จำเป็นต้องขออนุญาตที่ประชุม ซึ่งกว่าจะพบกันแต่ครั้งก็กินเวลานาน
เนื่องจากงานนี้เป็นงานไม่แสวงหาผลกำไร ในส่วนของการจัดการขายตั๋ว อาสาสมัครก็ได้นำ Revenue Streams และ Cost Structure มาเป็นจุดเริ่มต้น เราพอจะรู้ค่าใช้จ่ายหลักคร่าวๆ กล่าวคือ เพื่อให้ไม่ให้ขาดทุนแต่ถ้าหากมีรายได้จากผู้สนับสนุน ก็ถือเป็นกองทุนสำหรับการจัดงานครั้งต่อไป เมื่อทุกคนเข้าใจภาพรวมทางธุรกิจนี้แล้ว ผู้ที่รับผิดชอบขายตั๋วเป็นผู้เลือกใช้เครื่องมือไอทีซึ่งกลุ่มทำงาน เป็นผู้ตัดสินใจว่าการทำงานในส่วนนี้เกินกำลังของกลุ่ม และได้เลือกใช้บริการเอาต์ซอร์สของ EventBrite.com ทำให้สามารถกำหนดราคาตั๋วและประเภทของตั๋วได้อย่างคล่องตัว และมีความมั่นใจว่าจะไม่ทำให้ธุรกิจเสียหาย จากการที่มีกำลังคนไม่เพียงพอ
ตัวอย่างเหล่านี้ยกมาเพื่อให้เราพอเห็นภาพการใช้งานของ Canvas อย่างคร่าวๆ เพื่อให้เข้าใจถึงการที่ทุกภาคส่วนจะต้องมองเป้าหมายทางธุรกิจเป็นสำคัญ จึงจะสามารถตัดสินใจในการทำงานแต่ละขั้นตอนได้อย่างมีประสิทธิภาพได้ ที่แล้วมาแผนกไอทีมักถูกแผนกอื่นทิ้งให้โดดเดี่ยว เนื่องเพราะความเข้าใจผิดว่า ไอทีเป็นเรื่องต่างหากที่ไม่เกี่ยวข้องกับธุรกิจเจฟ ตัวละครเอกจากหนังสือชื่อ The Phoenix Project ซึ่งเป็นหนังสือนิยายไอทีขายดี ที่หลายๆ สำนักยกให้เป็นหนังสือที่ CEO ต้องอ่าน กล่าวไว้ว่า
“ในอีกสิบปีข้างหน้า ผมมั่นใจว่า ซีโอโอที่มีฝีมือทุกคนจะต้องรู้ไอที ซีโอโอคนใดที่ไม่มีความเข้าใจในไอทีอย่างลึกซึ้ง ก็จะเป็นได้แค่มนุษย์ใส่สูทที่ต้องคอยพึ่งพาคนอื่น ให้ช่วยทำงานของตัวเองอยู่ตลอดเวลา”
ไม่ว่าคำกล่าวนี้จะเป็นจริงหรือไม่ เราคงจะปฏิเสธไม่ได้ว่าในการดำเนินธุรกิจในปัจจุบันไม่สามารถละเลยไอทีได้ การรวมธุรกิจและไอทีเป็นหนึ่งเดียวกัน คือคำตอบ ของการทำธุรกิจในทศวรรษนี้ และกุญแจดอกสำคัญที่จะช่วยให้เกิดการรวมพลังของธุรกิจและไอทีได้นั้นได้ก็คือ แนวคิดและปฏิบัติแบบ อไจล์
อ้างอิง
กลุ่ม Agile66 – http://fb.com/groups/agile66
งาน Agile Tour Bangkok – http://agiletourbkk.org
Standish Group (2013), CHAOS Manifesto 2013
Alexander Osterwalder (2010), Business Model Generation, John Wiley and Sons
Kevin Behr, George Spafford, Gene Kim (2013), The Phoenix Project, IT Revolution Press
