นิธิกร เสนอ Agile Procurement แก้ปัญหาจัดซื้อซอฟต์แวร์

ก็ขอเรียนท่าน ประธานสภาและท่านสมาชิกทุกท่านนะครับ ผม นิธิกร บุญยกุลเจริญ ประธานคณะทำงาน ทุกท่านครับสำหรับรายงานการปรับปรุงกระบวนการจัดซื้อจัดจ้างให้มีความคล่องตัว เหมาะสมกับการจัดซื้อจัดจ้างซอฟต์แวร์และนวัตกรรมหรือที่เรียกว่า Agile Procurement ที่อยู่ต่อหน้าทุกท่านนะครับ เราแบ่งเนื้อหาเป็น ๓ ส่วนด้วยกัน ส่วนแรกจะเป็นส่วนของที่มา ส่วนของปัญหาแล้วก็กฎหมายที่เกี่ยวข้อง ส่วนที่ ๒ จะเป็นส่วนของการศึกษานโยบาย กฎหมายต่างประเทศ แล้วก็ข้อค้นพบต่าง ๆ ในประเทศไทย และส่วนสุดท้ายจะเป็นส่วนของ ข้อเสนอแนะครับ ทุกท่านครับสำหรับกล่าวโดยสรุปครับว่าปัญหาของการจัดซื้อจัดจ้าง ซอฟต์แวร์และนวัตกรรมจากการที่เราได้พูดคุยกับหน่วยงานต่าง ๆ เดี๋ยวอย่างไรฝ่ายโสต ผมรบกวนขอสไลด์หน่อยนะครับ

(เจ้าหน้าที่ดำเนินการเปิดคลิปภาพ)

หน้าถัดไปครับ เราพบว่าด้วยธรรมชาติของเทคโนโลยีที่เปลี่ยนไป ความต้องการมากขึ้นแต่กระบวนการ จัดซื้อใช้เวลานานครับ และเมื่อทำสัญญาแล้วหน่วยงานเปลี่ยนแปลงความต้องการได้ อย่างยากลำบาก รูปแบบการบริหารโครงการเป็นแบบขั้นตอนตายตัวอย่างที่ท่านประธาน กรรมาธิการได้แจ้งไปนะครับ ก็คือเขียนความต้องการตั้งแต่แรก พอดำเนินการไปเรื่อย ๆ แล้วส่งงานในตอนสุดท้าย รูปแบบธรรมชาติของซอฟต์แวร์ครับ มีการเปลี่ยนแปลงอยู่ ตลอดเวลา บางทีมีรุ่นใหม่ที่เหมาะสมสามารถนำมาใช้งานได้ ปัจจุบันยังเป็นอุปสรรคอยู่ แล้วก็สุดท้ายครับ ภาครัฐไม่ได้เป็นเจ้าของซอฟต์แวร์ที่จัดจ้างอย่างแท้จริง แม้ว่าใน TOR ครับจะมีคำว่า ลิขสิทธิ์เป็นของภาครัฐ แต่ในเรื่องของกระบวนการพัฒนาครับ เราปล่อยให้ เอกชน เราปล่อยให้ผู้รับจ้างดำเนินการทั้งหมดทำให้ภาครัฐไม่สามารถเข้าใจในสิ่งที่ตัวเอง พัฒนาได้ และสุดท้ายต้องมาของบประมาณซ้ำซ้อนอีกในปีถัด ๆ ไป ขอสไลด์หน้าถัดไปครับ จากการศึกษาวิธีการปัญหาเหล่านี้ครับ คณะทำงานได้พบว่าในต่างประเทศนั้นมีนโยบาย หรือว่ากฎหมายที่เรียกว่า Agile Procurement แปลเป็นไทยได้ว่า การจัดซื้อจัดจ้างแบบ คล่องตัว เช่น การกำหนดการใช้งบประมาณให้มีความเหมาะสมกับวงรอบพัฒนามากยิ่งขึ้น บางครั้งมีการพูดคุยระดับ ๑ - ๔ สัปดาห์ ๑ ครั้ง และถึงจะเบิกจ่ายเงิน เพื่อมีระยะสั้นให้ ยืดหยุ่นครับ เหมาะสมกับการเปลี่ยนแปลงหรือการเน้นซื้อทักษะเวลาของ Developer ครับ นี่คือสิ่งที่เรายังไม่ได้ดำเนินการอยู่ในภาครัฐของเรามากเพียงพอ เช่น การกำหนดนะครับว่า Developer นักพัฒนา นักออกแบบหน้าจอใช้ระยะเวลาเท่าไร มากกว่าการยึดตามสเปกงาน เพียงอย่างเดียว สิ่งเหล่านี้ครับ ศัพท์ทางเทคนิคเรียกว่า IT as a Service เพื่อให้สามารถ ปรับเปลี่ยนความต้องการได้ระหว่างโครงการนะครับหรือบางประเทศมีกฎหมายออกมา บังคับใช้ แล้วก็บอกว่าให้อำนาจหน้าที่ของหน่วยงานที่ผลักดันด้านดิจิทัลของภาครัฐ สามารถออก Guideline เดี๋ยวขอสไลด์หน้าถัดไปครับ ออก Guideline เพื่อบอกหน่วยงาน ภาครัฐเพื่อปฏิบัติตามได้โดยง่ายอย่างแท้จริง จริง ๆ คำว่า Agile Procurement มาจาก คำว่า Agile Development หรือแปลเป็นไทยว่าการบริหารโครงการแบบยืดหยุ่น อยู่ในการ พัฒนาซอฟต์แวร์อยู่แล้วครับ แต่คำว่า Agile นี้ตรงข้ามกับ Waterfall อย่างที่ผมบอกไปคือ การกำหนดนะครับ Requirement หรือว่าสเปกตั้งแต่ต้น แล้วสุดท้ายเราส่งงานตอนท้าย โครงการ สิ่งเหล่านี้ครับ ทำให้ขาดการสื่อสารที่เพียงพอและไม่ได้ซอฟต์แวร์ที่ตอบโจทย์ ตามที่ต้องการ ซึ่งวิธีการ Agile Development ครับ คือการบังคับให้เกิดการพูดคุยกันใน ทุก ๆ วงรอบ แบ่งออกเป็น ๑-๔ สัปดาห์อย่างที่ผมได้เรียนไปก่อนหน้านี้ เพื่อรับฟังว่า ข้อสรุปของวงรอบในการพัฒนาก่อนหน้านี้มีอะไรบ้างและอะไรบ้างที่ยังไม่แล้วเสร็จสามารถ ทบไปยังงวดงานถัดไปได้นะครับ แบบนี้ถึงเรียกว่า Agile Procurement อย่างที่ท่านสมาชิก ได้เห็นและท่านประธานได้เห็นอยู่บนหน้าจอนี้นะครับ ขอสไลด์ถัดไปครับ ที่ผมเล่ามาแบบนี้ เพราะว่าจะเกี่ยวข้องกับกระบวนการจัดซื้อก็แบบนี้ครับ Agile Procurement ที่คณะทำงาน ของเราจะเสนอต่อไปคือการใช้ข้อดีของคำว่า Time & Materials ครับ คือเน้นการซื้อทักษะ ของนักพัฒนาไม่ใช่ซื้อขอบเขตงานเพียงอย่างเดียว แน่นอนว่า TOR ต้องมีกำหนดขอบเขต งานครับที่จะต้องจัดจ้าง ที่จะต้องประมูล แต่ในเรื่องของการบริหารสัญญานั้น ขอบเขตงาน สามารถปรับเปลี่ยนได้ถ้าหากใช้เวลาเท่าเดิมกับโครงการนั้น ๆ ผมยกตัวอย่างให้ท่านสมาชิก ได้เข้าใจนะครับ ปัจจุบันมี Model AI รุ่น ๒ ที่สามารถใช้ได้ฟรีในภาครัฐเพื่อนำมาทำ AI บางอย่าง แต่พอเขียน TOR ในวันนี้เรากำหนดสเปก Version ๒ ไป แต่พอบริหารโครงการไปมี Version ใหม่ออกมา สุดท้ายแล้วภาครัฐก็ต้องต่อรองกับเอกชนเพื่อขอให้ทำให้ทั้ง ๆ ที่ การทำงานสามารถทำได้และทำได้ดีกว่า นี่คือข้อกำหนดโดยง่ายที่เราหมายถึงนะครับ แต่ด้วยงบประมาณเราต้องใช้แบบ Firm Fixed Price คือการกำหนดกรอบงบประมาณและ กรอบเวลาก่อนตามที่สำนักงบประมาณได้กำหนดไว้ พูดง่าย ๆ คือใช้กรอบงบประมาณแบบ Firm Fixed Price แต่การบริหารโครงการใช้แบบ Agile Procurement อย่างที่ผมบอก ไปได้ ขออนุญาตสไลด์ถัดไปครับ เปรียบเทียบได้ง่าย ๆ ว่า Agile Procurement กับ Traditional Procurement หรือการจัดซื้อจัดจ้างแบบเดิม การส่งมอบแบบ Agile Procurement คือเป็นรอบ ๆ มันจะเป็นการบังคับให้ภาครัฐต้องคุยกับผู้รับจ้างได้มากขึ้น ไม่ใช่แค่ ๙๐ วัน หรือ ๑๒๐ วันเท่านั้น แต่ทุกเดือนเราจะมีการ Review งวดงานที่ส่งไป ถ้าอันไหนที่ยังไม่เหมาะสมสามารถปรับเปลี่ยนได้ก็จะเป็นการเปลี่ยนแปลงที่รองรับไม่ได้ ยึดติดกับข้อจำกัดเดิม ๆ ขออนุญาตสไลด์ถัดไปครับ สิ่งเหล่านี้เพื่อเป็นการไม่ใช้เวลาสภา แห่งนี้มากนักนะครับ ผมจึงได้สรุปออกมาเป็นข้อเสนอแนะเพียง ๔ ข้อ แต่ถ้าสามารถ ดำเนินการได้ในภาครัฐของเราจะทำให้การบริหารโครงการซอฟต์แวร์คุ้มค่าทุกบาท ทุกสตางค์ ข้อแรกครับเราควรมอบหมายสำนักงานพัฒนารัฐบาลดิจิทัลหรือว่า DGA จัดทำ ตัวอย่าง TOR เรียกได้ว่าเป็น TOR Template ครับ แบบ Agile Procurement ให้สัมพันธ์ กับรูปแบบการพัฒนา ซอฟต์แวร์แบบยืดหยุ่น หรือที่เรียกว่า Agile Development เฉกเช่น ต่างประเทศครับ คือมีดิจิทัล Guideline มาเลยครับว่าถ้าหากจะเขียน TOR นั้นไม่ใช่กำหนด แค่สเปกงานอย่างเดียว ต้องบอกด้วยว่าผู้ใช้คือใคร ต้องบอกว่า User Story ของระบบคือ อะไร ไม่ต้องลงลึกรายละเอียดมากนักนะครับ แต่สามารถคุยได้ในระดับสัญญาเพื่อให้ตอบ โจทย์ในข้อนั้น ๆ มีกรอบสัญญาโครงสร้างราคาสัญญาที่เหมาะสมว่าแบบใดควรเป็นแบบ Firm Fixed Price หรือแบบใดที่จะต้องเป็นแบบ Time and Material อย่างภาพที่ผมแสดง อยู่บนหน้าจอด้านขวานี้จะเป็นตัวอย่างของ Template TOR ที่ทางสหรัฐอเมริกาเขียนเอาไว้ เพื่อให้หน่วยงานภาครัฐสามารถนำไปประยุกต์ใช้ได้ ก็จะมี Firm Fixed Price ก็คือกรอบ งบประมาณทั้งหมด ระยะเวลาที่ต้องแล้วเสร็จ สุดท้ายก็แบ่งเป็นวงรอบย่อย ๆ แล้วก็มีการ กำหนดงานสั้น ๆ เล็ก ๆ แบบกว้าง ๆ ให้ผู้รับจ้างทำได้ แบบนี้จะเป็นการปกป้องภาครัฐ ในการพัฒนาซอฟต์แวร์ ขอสไลด์หน้าถัดไปครับ

สำหรับข้อสังเกตข้อที่ ๒ ในแรกเริ่มคณะทำงานของเราพยายามศึกษาครับว่า ถ้าเราจะไปในรูปแบบของ Agile Procurement นี้ติดขัดระเบียบข้อใด หรือต้องยกร่าง กฎหมาย หรือต้องเปลี่ยนแปลงกฎหมายฉบับใดหรือไม่ จากการที่เราได้หารือกับทาง กรมบัญชีกลางพบว่าการบริหารสัญญาแบบ Agile Procurement หรือยืดหยุ่นแบบนี้ สามารถทำได้ครับ รูปแบบแบบนี้หน่วยรับงบประมาณสามารถบริหารจัดการเองได้ เพราะฉะนั้นเราจึงเสนอว่าข้อสังเกตข้อที่ ๒ ให้กรมบัญชีกลางทำหนังสือเวียนร่วมกับ DGA ในการกำหนดสเปกขอบเขต TOR อย่างข้อเสนอแนะข้อที่ ๑ เพื่อเป็นการแจ้งให้กับ หน่วยงานทุกหน่วยงานรับทราบว่าเรารองรับในรูปแบบ Agile Procurement เพราะว่าจาก การที่กรรมาธิการได้คุยกับหน่วยงานต่าง ๆ ที่เป็นหน่วยงานที่ต้องพัฒนาซอฟต์แวร์ พบว่า มีความกังวลว่าถ้าเขียนในรูปแบบที่ผมกล่าวไปก่อนหน้านี้จะผิดกฎหมายข้อใดหรือไม่ จึงได้ ใช้ในรูปแบบเดิม ๆ ที่เป็น Waterfall ซึ่งในปัจจุบันไม่ได้เป็นแบบนั้นครับ ขออนุญาตสไลด์ หน้าถัดไปครับ

ข้อที่ ๓ เราต้องเปลี่ยนการบริหารโครงการ การพัฒนานวัตกรรมหรือ ซอฟต์แวร์จากการที่ภาครัฐเป็นแค่ Project Management คือการทำโครงการให้แล้วเสร็จ ก็จบ ให้มาเป็นคำว่า Product Owner หรือเจ้าของผลิตภัณฑ์จริง ๆ นะครับ ยกตัวอย่างเช่น ประเทศสิงคโปร์ ทางประเทศสิงคโปร์นี้ไม่ว่า Product อะไรที่ทำออกมาทุก Product ถือโดย Owner ก็คือเจ้าของของภาครัฐและต้องมีความเข้าใจในซอฟต์แวร์อย่างแท้จริง มีแผนงาน Roadmap อีก ๓ ปี ๕ ปีว่าระบบที่พัฒนาขึ้นมานั้นจะเพิ่มเติมอะไรหรือจะปรับ ลดอะไร และมีการของบประมาณเป็นก้อนอย่างชัดเจนนะครับ ไม่ใช่ปีนี้ของบประมาณมา พัฒนาซอฟต์แวร์เสร็จ อีก ๒ ปีถัดไปผมเชื่อคิดว่าท่านสมาชิกก็เคยได้ยินว่ามีการขอ งบประมาณเพื่อไปทดแทนกับระบบเดิม ทั้ง ๆ ที่จริง ๆ แล้วเราสามารถกันงบประมาณ เพื่อให้เป็นการพัฒนาจากระบบเดิมได้ถ้าเกิดภาครัฐสามารถเป็น Product Owner ได้อย่าง แท้จริงนะครับ ซึ่งมีหลายหน่วยงานที่เป็นแบบนี้แล้ว แต่ว่าหลายหน่วยงานยังต้องมีการ ขับเคลื่อนในระดับนโยบายต่อไป ขอสไลด์หน้าถัดไปครับ

และข้อเสนอแนะข้อสุดท้ายของคณะทำงานเรานะครับ หน่วยงานต่าง ๆ ต้องนำ Source Code ที่พัฒนาขึ้นครับ จัดเก็บในแหล่งเก็บข้อมูล Code สาธารณะ หรือว่าทางเทคนิคเรียกว่า Public Repository ถ้าหาก Code ไหนไม่สามารถขึ้น Public Repository ได้ก็สามารถขึ้นเป็นส่วนตัวหรือที่เรียกว่า Private Repository เพื่อให้ Source Code เหล่านั้นไม่ได้อยู่กับ Vendor เพียงอย่างเดียว หรือว่าไม่ให้ทำการส่ง Source Code นั้นด้วย Flash Drive อย่างเดียว แล้วพอทำหายสุดท้ายแล้วซอฟต์แวร์ที่เราจัดซื้อจัดจ้างมา ก็หายตามไปด้วย สิ่งเหล่านี้ครับประเทศที่มี Digital Government Index สูง ๆ ล้วนแต่มี Public Repository เพื่อให้สาธารณะเข้ามาช่วยกัน Contribute หรือเข้ามาช่วยกันเขียน Code ได้ครับ สิ่งเหล่านี้เกิดการแชร์ระหว่างหน่วยงานได้ ซึ่งจะทำให้เกิดการประยุกต์ใช้ Reuse Software ครับ ไม่ต้องของบประมาณซ้ำซ้อนในภารกิจเดียวกันระหว่างภาครัฐ หรือ อย่างที่เห็นอยู่บนสไลด์ที่ทุกท่านเห็นทางด้านขวาจะมีคำว่า Public Money Public Code ก็คือเงินสาธารณะ Code สาธารณะทุกหน่วยงานใช้ได้ ภาครัฐและประชาชนสามารถเข้ามา มีส่วนร่วมกับภาครัฐได้ ทุกท่านครับทั้งหมดนี้คือบทสรุปและข้อเสนอแนะของคณะทำงาน เราที่จริง ๆ แล้วเราไม่จำเป็นต้องแก้กฎหมายใดครับ เพียงแต่ต้องปรับแนวปฏิบัติและทำ ความเข้าใจร่วมกันว่าการจัดซื้อในรูปแบบจัดซื้อจัดจ้างแบบยืดหยุ่น หรือที่เรียกว่า Agile Procurement นั้นทำได้ไม่ติดขัดระเบียบใด ทางคณะทำงานก็หวังเป็นอย่างยิ่งนะครับว่า รายงานฉบับนี้จะเป็นประโยชน์ต่อการจัดซื้อจัดจ้างพัฒนาซอฟต์แวร์และนวัตกรรมของ ภาครัฐต่อไปในอนาคต ขอบคุณครับ