เมื่อกระบวนการคัดเลือกผู้ให้บริการ (Vendor Selection) ถือเป็นขั้นตอนสำคัญที่ทำให้งาน PMO หรือ Program Management Office สามารถผลักดันกิจกรรมภายในโครงการให้ดำเนินไปอย่างมีประสิทธิภาพ เพื่อให้องค์กรธุรกิจสามารถปรับตัวก้าวสู่การเป็นองค์กรดิจิทัลทรานฟอร์เมชันได้ตามเป้าหมาย

แต่ทุกการขับเคลื่อนย่อมมีอุปสรรคเสมอ “ทิติยาพร สุเมธารัตน์” Strategy and Management Director ได้แนะนำ 12 แนวทางเพื่อกระบวนการคัดเลือกผู้ให้บริการ (Vendor Selection) ราบรื่นและไม่กลายเป็นสิ่งที่ต้องหนักใจอีกต่อไป

1. ทีมผู้ตัดสินใจเลือก Vendor ต้องมีความเข้าใจภาพใหญ่และรู้กระบวนการทำงานจริงขององค์กร

ผู้ที่มีอำนาจในการตัดสินใจเลือกผู้ให้บริการควรประกอบไปด้วยผู้ที่มีความเข้าใจในกลยุทธ์และทิศทางขององค์กรในภาพรวมว่าต้องการพัฒนาศักยภาพด้านใด ได้แก่ ผู้บริหารระดับสูงร่วมกับผู้ที่เข้าใจปัญหาที่เกิดกับกระบวนการทำงาน (Operation) รวมไปถึงเข้าใจความต้องการและประสบการณ์ของผู้ที่ใช้งานระบบจริง (User Experience) ได้แก่ ผู้บริหารระดับกลาง (Middle Management) หรือ Supervisor ที่มีความเข้าใจในรายละเอียดฟังก์ชันและความสามารถต่างๆ ของซอฟท์แวร์และมีประสบการณ์จริงในการทำงานร่วมกับผู้ให้บริการต่างๆ  โดยเฉพาะอย่างยิ่งถ้ามีประสบการณ์ในการคัดเลือก Vendor โดยต้องเข้ามามีส่วนร่วมในการคัดเลือกตั้งแต่เริ่มต้นกระบวนการคัดเลือก เพื่อร่วมพิจารณาและกำหนดหลักเกณฑ์และข้อกำหนดความต้องการอะไรบ้างที่จำเป็นในการคัดเลือก (Evaluation Criteria) ซึ่งหากผู้ที่มีอำนาจในการตัดสินใจมีคุณสมบัติและสามารถมีส่วนร่วมดังที่กล่าวมาแล้ว ก็จะเพิ่มโอกาสที่จะทำให้ Vendor Selection ประสบความสำเร็จ ช่วยให้ขั้นตอนการดำเนินการหรือติดตั้งระบบจริงเป็นไปตามแผนงานและความคาดหวัง

“ที่ผ่านมาคนที่เป็นผู้มีส่วนตัดสินใจว่าจะใช้ Vendor หรือ Software รายใดไหนมักจะเกิดกรณีที่ ‘คนเลือกไม่ได้ใช้ คนใช้ไม่ได้เลือก คนเลือกไม่เข้าใจ คนใช้ไม่ถูกใจ’ จึงทำให้การทำ Vendor Selection มีการพบปัญหาหรือไม่ประสบความสำเร็จ แนวทางแก้ไขคือต้องมีการคัดเลือกคณะทีมงานผู้มีอำนาจตัดสินใจที่เข้าใจทั้งความต้องการในเรื่องกลยุทธ์และขั้นตอนการทำงานจริง เข้ามาช่วยพิจารณาและตัดสินใจตั้งแต่เริ่มต้นในขั้นตอนการวางแผนการคัดเลือก ซึ่งต้องมีการกำหนดโครงสร้างทีมที่ดี”

2. การกำหนด Requirement ต้องละเอียดและครบถ้วนตั้งแต่เริ่มต้น

ควรกำหนดรายละเอียดเกี่ยวกับความต้องการในการใช้ระบบงานทางธุรกิจและเทคนิคที่ละเอียดและครบถ้วนมากที่สุดตั้งแต่เริ่มต้นโครงการเพื่อเป็นเกณฑ์และข้อตกลงในการคัดเลือกซอฟต์แวร์และผู้ติดตั้งระบบ ตรงนี้จะช่วยลดความเสี่ยงและปัญหาได้มากเมื่อถึงเวลาติดตั้งระบบและใช้งานจริง  เพราะมีหลายกรณีที่เกิดปัญหา ไม่ว่าจะเกิดจาก ความเข้าใจระหว่างผู้ใช้บริการและ Vendor ที่ไม่ตรงกัน ระบบที่ไม่สามารถทำงานได้ตามที่เคยตกลงหรือนำเสนอในขั้นตอนคัดเลือก หรือแม้แต่ระบบที่ต้องมีค่าใช้จ่ายเพิ่มเติมเพื่อให้สามารถทำงานได้ ดังนั้นหากไม่มีการกำหนดและตกลงรายละเอียดความต้องการระหว่างผู้ใช้บริการและผู้ใช้บริการติดตั้งซอฟท์แวร์หรือโซลูชันในรูปแบบเอกสาร มักจะเกิดปัญหาที่ไม่สามารถอ้างอิงความต้องการการใช้งานระบบด้านธุรกิจและเทคนิค (Business  and Technical Requirement) ได้

ดังนั้น จึงควรมีข้อกำหนดที่เป็น Requirement ให้ชัดเจน ไม่ว่าจะเป็นขั้นตอนกระบวนการทำธุรกิจและความต้องการทางเทคนิค อีกทั้งต้องเชื่อมโยงกระบวนการทำงานและระบบอื่นๆ ที่จำเป็นด้วย  ทั้งนี้เพื่อให้ทุกฝ่ายเข้าใจไปในทิศทางเดียวกันเมื่อเกิดปัญหาระหว่างปฏิบัติงาน จึงสามารถย้อนดูข้อตกลงที่กำหนดไว้ได้ ที่สำคัญของการกำหนด requirement ที่ชัดเจน จะทำให้ง่ายต่อการทำงานทั้ง Vendor และผู้ใช้บริการด้วย  ในหลายโครงการมักพบว่าหากลงรายละเอียด Requirement ในภาพที่ใหญ่มากเกินไปและใช้เวลาพิจารณาคัดเลือกเพียงไม่กี่ชั่วโมง  มีโอกาสได้ว่าผลจากการคัดเลือก  Vendor นั้น เป็นสาเหตุหลักที่ทำให้เกิดปัญหาเมื่อต้องทำงานจริง จากกรณีตัวอย่างในการเข้าไปมีส่วนแก้ไขปัญหาในโครงการที่ข้ามขั้นตอนและการให้ความสำคัญในส่วนนี้ของการทำ Vendor Selection  

3. Vendor ต้องยืนยันว่าโซลูชันทางธุรกิจและเทคนิคที่นำเสนอเป็นโซลูชันแบบใด ระหว่างมาตรฐานที่รวมในแพ็กเกจ (standard package) หรือ ต้องมีการแก้ไขโปรแกรม (customization) โดยมีค่าใช้จ่ายเพิ่ม

ในเอกสารรายละเอียดความต้องการทางธุรกิจและเทคนิคต้องมีความละเอียด และกำหนดให้ Vendor ที่นำเสนอระบุอย่างชัดเจนว่าโซลูชันเป็นแบบใด รวมอยู่ในแพ็กเกจมาตรฐานแล้ว หรือต้องคิดค่าบริการเพิ่มหากมีการปรับแก้ไขโปรแกรมเพื่อให้เป็นไปตามความต้องการของผู้ใช้บริการ รวมถึงระดับความยากง่ายในการแก้ไข (customization complexity)  ซึ่งหลายโครงการไม่ได้ดำเนินการในส่วนนี้ จึงเกิดกรณีความขัดแย้งเพราะเมื่อมีการติดตั้งระบบ (Implementation) แล้วพบว่ามีความจำเป็นต้องแก้ไขโปรแกรม จึงกลายเป็นต้องมีค่าใช้จ่ายเพิ่มเติมที่ไม่ได้ประเมินไว้จนบางครั้งอาจสูงขึ้นจนถึงหลักหลายสิบล้านบาท

“หลายคนอาจเข้าใจผิดเวลาเปลี่ยนระบบซอฟท์แวร์จากระบบหนึ่งไปอีกระบบหนึ่งว่าเป็นเรื่องง่ายแต่ความจริงมันไม่ง่ายเหมือนการ copy and paste  ยิ่งใช้ระบบเดิมมานาน ยิ่งมีเป็นไปได้ว่าต้องเขียนปรับแก้โปรแกรมจาก standard package มากขึ้นตามความต้องการของผู้ใช้งานหรือความเคยชินในกระบวนการทำงานแบบเดิม ดังนั้นถ้ามีการเปลี่ยนซอฟท์แวร์ตัวใหม่ ควรมีการทรานฟอร์มกระบวนการทำงานทั้งหมด โดยต้องวางกลยุทธ์ในการคัดเลือกและติดตั้งระบบใหม่ให้ชัดเจนตั้งแต่แรก เพราะหลายครั้งผู้ใช้งานอาจจะแจ้งกว่ากระบวนการหรือฟังก์ชันที่ต้องการทรานฟอร์มนั้น ยุ่งยาก ไม่สะดวก ขอปรับเปลี่ยนภายหลัง ทำให้มีต้นทุนเพิ่มเพราะต้องเขียนโปรแกรมเพิ่มทำให้งบประมาณบานปลาย ส่งผลให้แผนงานช้ากว่าที่กำหนด และยังส่งผลต่อต่อเป้าหมายและโอกาสทางธุรกิจของบริษัทได้”

4. อย่าลืมตรวจสอบและประเมินประสิทธิภาพของซอฟท์แวร์ (System Performance) และความสามารถในการรองรับการใช้งานที่เพิ่มขึ้น (Scalability)

จะพบกรณีนี้บ่อยเมื่อเลือกใช้ซอฟท์แวร์ใหม่แล้วไม่ได้ตรวจสอบหรือประเมินเรื่องประสิทธิภาพของโปรแกรมใหม่ (System Performance) ว่าสามารถรองรับจำนวนผู้ใช้งานสูงสุดเท่าไหร่ในกรณีที่มีการใช้งานพร้อมกัน ความรวดเร็วและจำนวนรายการในการประมวลผลข้อมูลเป็นไปตามความต้องการหรือไม่ เช่น ในช่วงที่มีการใช้งานสูงสุดนั้นการรับส่งข้อมูลผ่านระบบอยู่ในเกณฑ์ที่ธุรกิจรับได้หรือไม่  ซึ่งหากละเลยการตรวจสอบและประเมินในจุดนี้อาจพบปัญหาข้อจำกัดที่ระบบใหม่ไม่สามารถขยายหรือรองรับการใช้งานที่ต้องการเพิ่มในอนาคต (Scalability)  การทดสอบประสิทธิภาพของซอฟท์แวร์โดยการจำลองการใช้งานและการทำรายการในระบบจะช่วยให้ลดความเสี่ยงได้ระดับนึง และควรให้ Vendor ดำเนินการทำ Proof of Concept รวมถึงเตรียม Infrastructure เพื่อรองรับการใช้งานได้อย่างเพียงพอด้วย

5. ต้องพิจารณาโซลูชัน On Cloud หรือ On Premise

โซลูชันหรือซอฟท์แวร์ของ Vendor แต่ละรายอาจจะมีเพียงโซลูชัน Cloud หรือ On Premiseเท่านั้น แต่บางรายอาจมีทั้งสองแบบแต่มีข้อจำกัดที่ต้องพิจารณาให้ละเอียด ผู้ใช้บริการควรพิจารณาข้อดีข้อเสียและกำหนดว่าจะเลือกรูปแบบใดให้เหมาะสมกับความต้องการทางธุรกิจและงบประมาณที่มี  บางกรณีมีความต้องการปรับเปลี่ยนจากรูปแบบ  On Premise (Server Based) ไปใช้ Cloud แต่ยังไม่พร้อมในด้าน Infrastructure  ก็ต้องพิจารณาวางแผนดำเนินการในส่วนนี้ ขณะเดียวกันก็ต้องดูว่า Vendor มีประสบการณ์และความเชี่ยวชาญในการ implement ระบบบน Cloud หรือ On Premise  เพื่อให้มั่นใจได้ว่าการติดตั้งโซลูชันหรือซอฟท์แวร์จะเป็นไปอย่างราบรื่น

6. มีแผนงานพัฒนาผลิตภัณฑ์หรือโซลูชันที่ดี (Product Roadmap)

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

7. ให้ความสำคัญกับการกำหนดขอบเขตงานด้าน Data

หลายโครงการมักคิดว่าค่อยไปทำความเข้าใจและตกลงเรื่องขอบเขตงานด้านข้อมูลหลังจากทำสัญญาคัดเลือกVendor ไปแล้วถือเป็นความคิดที่ผิด โดยผู้ใช้บริการมักมีปริมาณข้อมูลจำนวนมากในระบบเดิมตั้งแต่ 5-20 ปีที่แล้ว เมื่อ  ต้องทำการย้ายข้อมูลจากระบบเดิมสู่ระบบใหม่ ต้องกำหนดขอบเขตและกระบวนการโอนย้ายข้อมูลที่ชัดเจน (Data Migration Scope and Approach) เพื่อป้องกันความเสี่ยง เช่น ประเภทจำนวนข้อมูลหลักและข้อมูลรายการ จำนวนปีย้อนหลังของข้อมูล (Historical Data) เป็นต้น รวมถึงการทำความเข้าใจกระบวนการรวมถึงหน้าที่ความรับผิดชอบตั้งแต่การทำ Data Cleansing  Data Mapping  Data Transformation และ Data Validation ระหว่าง Vendor และผู้ใช้บริการด้วย ถ้าผู้ใช้บริการกับ Vendor ไม่สื่อสารและบันทึกในเอกสารให้ความเข้าใจให้ตรงกัน อาจเกิดปัญหาระหว่างการทำงานสูงมาก จนหลายโครงการไม่สามารถขึ้นระบบใหม่ได้เลย หรือล่าช้าจากแผนงานเดิมเป็นปีก็มี เนื่องจากปัญหาเรื่องขอบเขตงานและกระบวนการการโอนย้ายข้อมูลที่ไม่ชัดเจน

8. ประสบการณ์ของทีม Vendor ทีมเวิร์คต้องแน่นและเก่งจริง

ผู้ใช้บริการควรพิจารณาประสบการณ์และโครงสร้างของทีม Vendor เพื่อให้แน่ใจว่าหากได้รับคัดเลือกเข้ามาทำงานแล้วจะมีบุคลากรที่มีทั้งความเชี่ยวชาญ ประสบการณ์ รวมถึงจำนวนทีมงานที่เพียงพอ ในบางโครงการอาจจะประเมินจากประวัติการทำงานที่ส่งให้แต่ไม่มีการสอบถามหรือสัมภาษณ์เพื่อประเมินความสามารถอย่างจริงจัง เพื่อให้เกิดความเชื่อมั่นว่าจะสามารถนำพาให้โครงการสำเร็จตามเป้าหมายได้จึงควรพิจารณาความสามารถอย่างเข้มข้น โดยเฉพาะในตำแหน่งสำคัญ  

“เป็นเรื่องที่เกิดขึ้นได้เสมอที่จะพบปัญหาระหว่างการติดตั้งระบบจริง แต่หากทีมงานที่ตัดเลือกมา มีความเชี่ยวชาญ แข็งแกร่งและมีระบบทำงานร่วมกันเป็นทีมสูง โอกาสที่จะสามารถพลิกสถานการณ์และแก้เกมได้เร็วก็สูงตาม แต่ถ้าทีมงานมีลักษณะตรงกันข้าม เมื่อยามเกิดปัญหาและความสามารถและความรวดเร็วในการแก้ไขปัญหามีจำกัด จะส่งผลต่อความคืบหน้าและคุณภาพของโครงการแน่นอน”

9. อย่าเลือก Vendor เพราะราคาถูก อาจทำให้เสียทั้งเวลาและโอกาส

การเลือก Vendor ควรพิจารณาจากคะแนนการประเมินพร้อมเหตุผลสนับสนุนที่สามารถอธิบายว่า Vendor แต่ละรายมีข้อดีหรือข้อเสียแตกต่างอย่างไร  ควรเลือก Vendor จากเกณฑ์พิจารณาทุกๆ ด้าน (รวมเกณฑ์ด้านราคา)  มากกว่าเลือก Vendor จากการนำเสนอราคาถูกเป็นลำดับแรก ซึ่งผู้ใช้บริการบางรายกำหนดน้ำหนักเกณฑ์ด้านราคาที่สูงเกินไปเมื่อเทียบกับเกณฑ์ด้านอื่นๆ  ทำให้เกิดปัญหาว่าไม่สามารถทำงานตามความคาดหวัง หรือ โซลูชันไม่ตอบโจทย์ จนต้องทำการคัดเลือกใหม่หรือต้องเปลี่ยนโซลูชัน ทำให้เสียทั้งเวลา งบประมาณ ทรัพยากร และโอกาสทางธุรกิจ  ดังนั้นผู้บริหารที่มีอำนาจในการตัดสินใจควรให้ความสำคัญกับกระบวนการ Vender Selection ที่อาจใช้เวลา 4-6 เดือนในการดำเนินการ รวมถึงกำหนดหลักเกณฑ์และน้ำหนักในการคัดเลือกที่เหมาะสมสำหรับโครงการ ซึ่งถือว่ามีความสำคัญต่อองค์กร  

10. ข้อตกลงเรื่องรูปแบบการให้บริการหลังจบโครงการ (Service Support Model) ต้องชัดเจน

ข้อผิดพลาดอย่างหนึ่งที่มักจะเกิดขึ้นคือ การตกลงรูปแบบและเงื่อนไขการให้บริการหลังขึ้นระบบและจบระยะเวลาการ Go Live Support ตามขอบเขตของโครงการ ซึ่งในขั้นตอนการทำ Vendor Selection บางโครงการไม่ได้กำหนดและตกลงกับ Vendor ให้ชัดเจนก่อนเริ่มโครงการ ส่งผลให้ระดับคุณภาพการให้บริการลดลง หรือต้องมีค่าใช้จ่ายเพิ่มเติม ดังนั้นจึงควรมีการเขียนข้อตกลงไว้อย่างชัดเจนว่าผู้ให้บริการแต่ละรายมีรูปแบบการให้บริการอย่างไรหลังจบโครงการภายใต้เงื่อนไขความเร่งด่วนของปัญหาและระยะเวลาที่ต้องแก้ไขตามที่ตกลงกัน (Service Level Agreement) รวมถึงกรณีที่ต้องช่วยเหลือผู้ใช้บริการทั้งแบบ On-site และOff-site เช่น หากระบบผู้ใช้บริการเกิดปัญหาใช้งานไม่ได้ขึ้นมา จะต้องตอบสนองและแก้ไขอย่างไร สื่อสารผ่านช่องทางใด ภายในระยะเวลาเท่าไร ตามระดับความรุนแรงของปัญหารวมถึงต้องมีรายละเอียดอย่างชัดเจนว่าการแก้ไขดังกล่าวเป็นสิ่งที่สามารถบริการให้ได้ปกติตามเงื่อนไขที่ได้ตกลงไว้หรือมีคิดค่าใช้จ่ายเพิ่มเติม

ทั้งหมดนี้หากผู้ใช้บริการนำทั้ง 10 ข้อแนะนำนี้ไปเป็นข้อพิจารณาสำหรับกระบวนการ Vendor Selection จะสามารถช่วยลดความเสี่ยงและทำให้องค์กรบรรลุเป้าหมายตามแผนงานที่วางไว้ได้ไม่ยากจนเกินไป