ASAP Project ขอแชร์เกณฑ์ในการคัดเลือกผู้ให้บริการแบบรอบด้าน ที่พวกเราใช้ในการทำโปรเจ็กต์จริงกันมาแล้วมากมาย โดยใช้กรอบทั้งในด้าน “Quantitative” หรือเชิงปริมาณ และ “Qualitative” หรือเชิงคุณภาพ ดังนี้:

เกณฑ์เชิงปริมาณ

ได้แก่

[1] ความสามารถของระบบ (Functionalities) 


ในกรณีที่เป็นผู้ให้บริการด้านซอฟต์แวร์หรือโซลูชัน โดยจะมีการให้คะแนนความสามารถในการรองรับความต้องการของโปรเจ็กต์ที่ต้องการทำของแต่ละระบบ โดยตรงนี้จะต้องมีการประเมินโดยละเอียดเทียบกับเอกสาร Request-for-Proposal หรือรายการความต้องการที่จะให้ทางผู้ให้บริการแต่ละรายส่งคำตอบมาให้ (เราจะอธิบายละเอียดในบทความถัดไป)

[2] งบประมาณ (Budget) 


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

[3] ระยะเวลา (Timeline)

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


โดยทั่วไป หากเป็นการขึ้นระบบซอฟต์แวร์ใดๆ เรามักจะแบ่งเฟสเป็น


• (a) Requirement Definition คือ ระยะเวลาในการเก็บความต้องการจากผู้ใช้งานหลัก จากการทำ Workshop หรือสัมภาษณ์ รวมถึงการทำเอกสารสรุปความต้องการ เพื่อให้ยืนยันก่อนดำเนินงานต่อ


• (b) Design and Development คือ ช่วงที่ทำการออกแบบ ตั้งค่า หรือพัฒนาระบบ ในกรณีที่มีงานพัฒนา (Customization) เพิ่มเติม ขั้นตอนนี้จะเป็นช่วงที่ออกแบบหน้าตาของระบบ และทำการพัฒนาตามความต้องการ หากเป็นระบบที่ใช้ได้เลยตามมาตรฐาน (Off-the-shelf) จะเป็นช่วงที่ทำการตั้งค่าต่างๆ ในระบบ


• (c) Integration (Optional) คือช่วงที่ทำการเชื่อมต่อกับระบบอื่นๆ ซึ่งระยะเวลาจะขึ้นอยู่กับจำนวนของระบบที่จะเชื่อม ความยากง่ายและกรณีที่ต้องการเชื่อม ในบางโปรเจ็กต์ อาจจะไม่มีขั้นตอนนี้


• (d) Delivery คือ ช่วงที่ผู้ให้บริการจะทำการทดสอบระบบ ทั้งภายใน (SIT) และกับทางลูกค้า (UAT) รวมถึงการอบรมการใช้งาน และเตรียมระบบในการเริ่มใช้จริง


• (e) Go Live คือ ช่วงเริ่มใช้ระบบจริง โดยส่วนใหญ่จะมีระยะเวลารับประกัน หรือดูแลแบบเข้มข้มหลังจากวันที่เริ่มใช้เป็นระยะเวลาหนึ่งๆ ตามสัญญา 

เกณฑ์เชิงคุณภาพ

ได้แก่

[4] แนวทางในการดำเนินการโครงการ (Implementation Approach)


คือ การพิจารณาการออกแบบเฟสหรือขั้นตอนในการทำโปรเจ็กต์ ว่าจะขึ้นโมดูลใดก่อนหลัง ด้วยระยะเวลาเท่าใด ด้วยเหตุผลใด จะทำแบบ Waterfall หรือ Agile ด้วยปริมาณทีมงานกี่คน และจะต้องให้ฝ่ายลูกค้าเข้ามามีส่วนร่วมในช่วงใด ต้องมีใครเข้ามาร่วมตัดสินใจในเวลาใดบ้าง 

แนวทางที่ดี ควรจะมีตรรกะที่ชัดเจน และจำนวนทีมที่เหมาะสม ที่ทำให้เข้าใจว่างานที่ออกแบบไว้จะเป็นไปได้ได้อย่างไร 

[5] การบริการหลังการขาย

จริงๆ แล้ว ข้อนี้ถือเป็นเกณฑ์ที่มีความสำคัญ และสมควรได้น้ำหนักมากข้อหนึ่ง โดยควรจะพิจารณาถึงแพ็กเกจในการให้บริการหลังจาก Go Live ไปแล้วว่า

• จะมีขอบเขตการให้บริการใดบ้าง ช่องทาง และทีมงานในการติดต่อเป็นอย่างไร 

• มี SLA หรือ “Service Level Agreement” อย่างไร เช่น จะมีระยะเวลาการตอบรับครั้งแรก (First Response Time) ภายในกี่นาทีหรือชั่วโมง และมีระยะเวลาการแก้ปัญหา (Final Resolution Time) ในระดับต่างๆ เป็นอย่างไร 

• มีช่องทางให้ติดตาม Ticket หรือเรื่องที่ส่งไปให้หรือไม่ อย่างไร เป็นต้น

[6] ความพร้อมในการขยายธุรกิจ

คือ การพิจารณาขอบเขตและเงื่อนไขของระบบและผู้ให้บริการว่ามีความยืดหยุ่นต่อการรองรับการเปลี่ยนแปลงและเติบโตของธุรกิจเพียงใด เช่น ราคาและขนาดของ Cloud Storage ต่อปริมาณข้อมูลที่จะเพิ่มขึ้น ราคาของ License ผู้ใช้งานในกรณีที่จะต้องเพิ่มผู้ใช้งานมากขึ้น หรือเพิ่มสาขามากขึ้น ราคาต่อ Manday ในกรณีต้องการพัฒนาบางส่วนเพิ่ม หรือขอบริการพิเศษ เป็นต้น

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

[7] หน้าตาของระบบ และความง่ายในการใช้งาน

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

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

[8] ความน่าเชื่อถือและประสบการณ์ของผู้ให้บริการ

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

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

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