ศาสตร์แห่งการเลือก Vendor: ก้าวแรกของ Digital Transformation
ในทุกการทำ Digital Transformation ไม่มีองค์กรใดเดินได้ด้วยตัวเอง ต้องอาศัยพาร์ตเนอร์หรือ Vendor ที่เหมาะสมเข้ามาร่วมขับเคลื่อน — และ “การเลือก Vendor” ที่ดีตั้งแต่แรกเริ่ม คือหัวใจสำคัญของความสำเร็จระยะยาว
บทความนี้เขียนจากประสบการณ์ตรงของ ASAP Project ที่เคยทำงานในโปรเจกต์ทรานส์ฟอร์มหลายสิบครั้ง เราจะพาคุณไปรู้จักกับ
ใครควรมีส่วนร่วมในการเลือก Vendor
ทำไมกระบวนการเลือกจึงต้องโปร่งใส และให้ทุกฝ่ายมีส่วนร่วม
เกณฑ์วัดผลทั้งแบบเชิงปริมาณและคุณภาพ
ขั้นตอนการคัดเลือกแบบมีเหตุมีผล ใช้ได้จริงในทุกองค์กร
หากคุณกำลังเริ่มต้นโปรเจกต์ DX หรืออยู่ระหว่างตัดสินใจเลือกพาร์ตเนอร์ นี่คือบทความที่ไม่ควรพลาด
TYPE
Thoughts
ศาสตร์แห่งการเลือก Vendor
หลายคนที่เคยทำ Digital Transformation คงทราบดีว่า ความสำเร็จของโปรเจ็กต์ไม่ได้เกิดจากทีมภายในอย่างเดียว แต่ต้องอาศัยพาร์ตเนอร์หรือ Vendor ที่ใช่ ซึ่งบางครั้งต้องมีมากกว่า 1 รายเข้ามาร่วมกันขับเคลื่อน
ASAP Project อยากแบ่งปันแนวคิดและวิธีการเลือก Vendor ที่เราใช้จริงในการทำโปรเจ็กต์ Digital Transformation เพื่อให้คุณเลือก “พาร์ตเนอร์” ที่จะร่วมทางไปได้ตลอดรอดฝั่ง
📍 ใครควรรับผิดชอบการเลือก Vendor?
การเลือก Vendor ควรเป็นหน้าที่ของผู้มีอำนาจตัดสินใจระดับสูง เช่น C-level หรือ Project Owner เพราะ:
Vendor แต่ละรายมี “แนวทาง” และ “ทิศทาง” ที่จะส่งผลกระทบระยะยาว
การเลือกผิดอาจทำให้ต้อง “ทิ้งของเก่า” หรือรื้อกระบวนการใหม่ทั้งหมด
ต้องการการมองภาพรวม ไม่ใช่แค่เชิงเทคนิค
การคัดเลือก Vendor ให้ดีควรจะมีส่วนงานที่เกี่ยวข้องได้แก่
เจ้าของโครงการ (ส่วนงานที่เป็นต้นคิดโปรเจ็กต์ เช่น ฝ่ายขายอาจจะเป็นเจ้าของโครงการในการหา CRM ใหม่ เป็นต้น)
ผู้ใช้งานหลัก (ที่ควรจะมีส่วนในการออกความคิดเห็นและความต้องการที่ชัดเจน)
ฝ่าย IT (โดยเฉพาะส่วนที่ดูแล Application ในองค์กร)
ฝ่ายที่ทำ Change Management (ฝ่ายที่เป็นผู้จัดการการปรับเปลี่ยนกระบวนการทำงานต่างๆ ในองค์กร)
ฝ่าย HR (เพื่อดูว่ามีทรัพยากรที่จะสามารถเข้าร่วมโปรเจ็กต์นี้มากน้อยเพียงใด)
ฝ่ายบริหาร (ขึ้นอยู่กับระดับในองค์กร อาจจะเป็นระดับ Manager หรือ Director หากเป็นองค์กรใหญ่)
ฝ่ายจัดซื้อ (เพื่อรับทราบงบประมาณที่จะเกิดขึ้น และประเมินความเสี่ยง)
การคัดเลือก Vendor ที่ดีควรจะมีกลุ่มงานที่ทำงานร่วมกันจากหลายๆ ส่วนงานช่วยกันพิจารณา ไม่ใช่ทีม IT หรือจัดซื้อเพียงทีมเดียว เพื่อให้สามารถรองรับบริบทของธุรกิจในภาพใหญ่ และควรจะถูกขับเคลื่อนด้วยเจ้าของโครงการที่ได้รับอำนาจการตัดสินใจในระดับหนึ่ง
✅ ทำไมการเลือก Vendor จึงสำคัญ?
การคัดเลือกผู้ให้บริการให้เหมาะกับการดำเนินการโปรเจ็กต์ในระยะยาวมีผลโดยตรงกับความสำเร็จของโปรเจ็กต์ โดยเราอาจจะย่อยความสำคัญมาให้เข้าใจง่ายๆ ใน 3 ข้อ ได้แก่
[1] การเลือก Vendor ที่ดีจะทำให้การตัดสินใจมีความเป็นกลาง รอบคอบ โปร่งใส และมีประสิทธิภาพ
กระบวนการในการคัดเลือกผู้ให้บริการอย่างมีขั้นตอน จะช่วยให้เราใช้เหตุผลและตรรกะในการวิเคราะห์ผู้ให้บริการแต่ละราย โดยไม่ใช้ความคิดเห็นส่วนตัวหรือความรู้สึกของคนทำงานท่านใดท่านหนึ่ง หรือคำนึงถึงส่วนได้ส่วนเสียของฝ่ายใดฝ่ายหนึ่งเป็นสำคัญ การตัดสินใจจะมีความโปร่งใส และตรวจสอบได้
[2] การเลือก Vendor ที่ดี จะเปิดโอกาสให้ทุกคนมีส่วนร่วมในการตัดสินใจ
ไม่ว่าจะเลือกผู้ให้บริการได้ถูกต้องหรือล้มเหลว ทุกฝ่ายควรจะมีความรับผิดชอบร่วมกัน และไม่ใช่ความรับผิดชอบของฝ่ายใดฝ่ายหนึ่ง การเลือกอย่างมีขั้นตอนควรจะเปิดโอกาสให้ส่วนงานที่ต้องทำโปรเจ็กต์นั้นร่วมกันได้มีส่วนออกความคิดเห็นด้วยกัน เพราะในระยะยาว ทุกคนจะต้องเคารพในผลของการตัดสินใจนั้นร่วมกัน และไม่มีการโยนความผิดให้กัน
[3] การเลือก Vendor ที่ดีทำให้องค์กรสามารถเข้าใจความเสี่ยงต่างๆ และเตรียมรับมือได้ล่วงหน้า
แน่นอนว่าไม่มีผู้ให้บริการรายใดที่ทำได้ดีทุกอย่างทุกด้าน การประเมินผู้ให้บริการอย่างครบถ้วนรอบคอบ ทำให้เราได้มีโอกาสพิจารณาจุดอ่อนของแต่ละรายได้ตั้งแต่แรกก่อนจะเริ่มโปรเจ็กต์ และหากจะเลือกรายใด เราก็จะเลือกโดยทราบถึงความเสี่ยงที่จะเกิดขึ้นได้ล่วงหน้า ทำให้สามารถหาวิธีลดหรือรับมือกับความเสี่ยงนั้นได้ล่วงหน้า
✅ ทำไมการเลือก Vendor จึงสำคัญ?
การคัดเลือกผู้ให้บริการให้เหมาะกับการดำเนินการโปรเจ็กต์ในระยะยาวมีผลโดยตรงกับความสำเร็จของโปรเจ็กต์ โดยเราอาจจะย่อยความสำคัญมาให้เข้าใจง่ายๆ ใน 3 ข้อ ได้แก่
[1] การเลือก Vendor ที่ดีจะทำให้การตัดสินใจมีความเป็นกลาง รอบคอบ โปร่งใส และมีประสิทธิภาพ
กระบวนการในการคัดเลือกผู้ให้บริการอย่างมีขั้นตอน จะช่วยให้เราใช้เหตุผลและตรรกะในการวิเคราะห์ผู้ให้บริการแต่ละราย โดยไม่ใช้ความคิดเห็นส่วนตัวหรือความรู้สึกของคนทำงานท่านใดท่านหนึ่ง หรือคำนึงถึงส่วนได้ส่วนเสียของฝ่ายใดฝ่ายหนึ่งเป็นสำคัญ การตัดสินใจจะมีความโปร่งใส และตรวจสอบได้
[2] การเลือก Vendor ที่ดี จะเปิดโอกาสให้ทุกคนมีส่วนร่วมในการตัดสินใจ
ไม่ว่าจะเลือกผู้ให้บริการได้ถูกต้องหรือล้มเหลว ทุกฝ่ายควรจะมีความรับผิดชอบร่วมกัน และไม่ใช่ความรับผิดชอบของฝ่ายใดฝ่ายหนึ่ง การเลือกอย่างมีขั้นตอนควรจะเปิดโอกาสให้ส่วนงานที่ต้องทำโปรเจ็กต์นั้นร่วมกันได้มีส่วนออกความคิดเห็นด้วยกัน เพราะในระยะยาว ทุกคนจะต้องเคารพในผลของการตัดสินใจนั้นร่วมกัน และไม่มีการโยนความผิดให้กัน
[3] การเลือก Vendor ที่ดีทำให้องค์กรสามารถเข้าใจความเสี่ยงต่างๆ และเตรียมรับมือได้ล่วงหน้า
แน่นอนว่าไม่มีผู้ให้บริการรายใดที่ทำได้ดีทุกอย่างทุกด้าน การประเมินผู้ให้บริการอย่างครบถ้วนรอบคอบ ทำให้เราได้มีโอกาสพิจารณาจุดอ่อนของแต่ละรายได้ตั้งแต่แรกก่อนจะเริ่มโปรเจ็กต์ และหากจะเลือกรายใด เราก็จะเลือกโดยทราบถึงความเสี่ยงที่จะเกิดขึ้นได้ล่วงหน้า ทำให้สามารถหาวิธีลดหรือรับมือกับความเสี่ยงนั้นได้ล่วงหน้า
✅ แนวทางในการเลือก Vendor (ฉบับ ASAP Project)
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] ความน่าเชื่อถือและประสบการณ์ของผู้ให้บริการ
ปัจจัยสุดท้ายที่ควรพิจารณาได้แก่ ความน่าเชื่อถือของผู้ให้บริการ และประสบการณ์ในการทำโปรเจ็กต์ที่ตรงหรือใกล้เคียงกับที่จะทำด้วยกัน
เพื่อให้สามารถมั่นใจได้ว่าผู้ให้บริการจะสามารถดูแลเราจนจบโปรเจ็กต์และต่อเนื่องหลังจากจบไปแล้วได้อย่างต่อเนื่อง ควรพิจารณาถึงอายุขององค์กร ทุนจดทะเบียน หรือหน้างบปีล่าสุด เป็นต้น ทั้งนี้ เราไม่ได้หมายความว่า หากบริษัทเพิ่งก่อตั้งจะไม่มีความสามารถ เพียงแต่ว่าอาจจะมีความเสี่ยงว่ารูปแบบหรือจุดประสงค์ของบริษัทของผู้ให้บริการนั้นๆ อาจจะมีการเปลี่ยนแปลงได้ในอนาคต ซึ่งอาจมีความเสี่ยง เช่น โซลูชันที่กำลังจะซื้อมาใช้ หรือบริการที่ได้รับอาจจะไม่ได้โฟกัสหลักของบริษัทในอนาคต เพราะมีการเปลี่ยนทิศทางขององค์กร เป็นต้น
ประสบการณ์ที่เกี่ยวข้อง หรือรายชื่อลูกค้าอ้างอิงจากประเภทธุรกิจใกล้เคียง ก็เป็นอีกข้อพิจารณาที่จะช่วยให้เราทราบได้ว่าผู้ให้บริการเข้าใจโจทย์และความต้องการของธุรกิจมากน้อยเพียงใด
✅ แนวทางในการเลือก Vendor (ฉบับ ASAP Project)
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] ความน่าเชื่อถือและประสบการณ์ของผู้ให้บริการ
ปัจจัยสุดท้ายที่ควรพิจารณาได้แก่ ความน่าเชื่อถือของผู้ให้บริการ และประสบการณ์ในการทำโปรเจ็กต์ที่ตรงหรือใกล้เคียงกับที่จะทำด้วยกัน
เพื่อให้สามารถมั่นใจได้ว่าผู้ให้บริการจะสามารถดูแลเราจนจบโปรเจ็กต์และต่อเนื่องหลังจากจบไปแล้วได้อย่างต่อเนื่อง ควรพิจารณาถึงอายุขององค์กร ทุนจดทะเบียน หรือหน้างบปีล่าสุด เป็นต้น ทั้งนี้ เราไม่ได้หมายความว่า หากบริษัทเพิ่งก่อตั้งจะไม่มีความสามารถ เพียงแต่ว่าอาจจะมีความเสี่ยงว่ารูปแบบหรือจุดประสงค์ของบริษัทของผู้ให้บริการนั้นๆ อาจจะมีการเปลี่ยนแปลงได้ในอนาคต ซึ่งอาจมีความเสี่ยง เช่น โซลูชันที่กำลังจะซื้อมาใช้ หรือบริการที่ได้รับอาจจะไม่ได้โฟกัสหลักของบริษัทในอนาคต เพราะมีการเปลี่ยนทิศทางขององค์กร เป็นต้น
ประสบการณ์ที่เกี่ยวข้อง หรือรายชื่อลูกค้าอ้างอิงจากประเภทธุรกิจใกล้เคียง ก็เป็นอีกข้อพิจารณาที่จะช่วยให้เราทราบได้ว่าผู้ให้บริการเข้าใจโจทย์และความต้องการของธุรกิจมากน้อยเพียงใด
✅ วิธีการคัดเลือก Vendor (ฉบับ ASAP Project)
ขั้นตอนที่เราใช้ในการคัดเลือกผู้ให้บริการประกอบได้ด้วย 5 ขั้นตอนหลัก ได้แก่
[1] สร้างเกณฑ์การตัดสินใจ
เริ่มต้นจากการเลือกเกณฑ์ที่จะใช้ในการตัดสินใจ โดยสามารถอ้างอิงจากที่เราอธิบายมาแล้วข้างต้น หรืออาจจะตัดบางข้อ หรือแตกบางข้อออกมาเพิ่มเติม แล้วแต่รูปแบบของแต่ละโปรเจ็กต์ ทั้งนี้ ต้องพิจารณาแล้วว่าเกณฑ์ที่จะใช้นั้นสามารถใช้เปรียบเทียบผู้ให้บริการทุกรายได้อย่างเท่าเทียมกัน
[2] ระบุน้ำหนักของเกณฑ์การตัดสินใจ
เมื่อได้หัวข้อเกณฑ์มาแล้ว ให้ใส่น้ำหนักเป็น % ในการตัดสินใจให้กับแต่ละข้อ โดยให้ทุกข้อรวมกันได้ 100%
การใส่น้ำหนักนี้จะเป็นตัวช่วยให้เห็นความสำคัญที่ต่างกันของแต่ละประเด็น เช่น อาจจะให้เรื่องงบประมาณสูงสุดที่จากทั้งหมด หากเป็นโปรเจ็กต์ที่มีงบประมาณจำกัดหรือไม่ยืดหยุ่น เป็นต้น
การระบุน้ำหนักของแต่ละหัวข้อ ควรมีการหารือกันในทีมทำงาน โดยให้ทุกคนช่วยกันลงความเห็น ถ้าตัดสินใจร่วมกันไม่ได้ อาจจะให้ทุกคนลงคะแนนแยก และใช้ค่าเฉลี่ยแทน
[3] ให้คะแนนในแต่ละเกณฑ์การตัดสินใจ
เมื่อได้น้ำหนักมาแล้ว ให้ทำการให้คะแนนให้แต่ละหัวข้อ โดยอาจจะใช้คะแนน 1-3 หรือ 1-5 แล้วแต่ความละเอียดที่ต้องการ ทั้งนี้ จะต้องมีกติกาที่ชัดเจนว่า การให้ 1 ไปจนถึง 5 คะแนนนั้นต่างกันอย่างไร
ตัวอย่างเช่น ในหัวข้อของระยะเวลาของโปรเจ็กต์ (Timeline) ให้ 1 คะแนนสำหรับรายที่ใช้ระยะเวลานานที่สุด หรือเกิน 15 เดือน และ 5 สำหรับสั้นที่สุดหรือต่ำกว่า 7 เดือน เป็นต้น
[4] สรุปคะแนนหลังถ่วงน้ำหนัก
เมื่อได้คะแนนมาแล้ว ให้สรุปคะแนนของแต่ละหัวข้อ สำหรับแต่ละผู้ให้บริการโดยคูณกับน้ำหนักที่ระบุแต่ละหัวข้ออีกครั้ง เพื่อให้ได้คะแนนที่บ่งบอกถึงระดับความสำคัญในการตัดสินใจด้วย
[5] สรุปและวิเคราะห์
เมื่อได้คะแนนของทุกรายมาแล้ว ให้ทำการวิเคราะห์อีกครั้งว่าการให้คะแนนนั้นบ่งบอกถึงความเป็นจริงของแต่ละรายมากน้อยเพียงใด ซึ่งหากเกณฑ์ในการให้คะแนนมีความชัดเจน คะแนนที่ได้จะเป็นความจริงระดับหนึ่ง
เมื่อทำการเรียงลำดับผู้ที่ได้คะแนนมากไปยังน้อยแล้ว ให้ประชุมร่วมกันเพื่อชี้แจงผล และเลือกรายที่จะเป็นผู้ให้บริการกับเราต่อไป
อย่างไรก็ตาม หลายครั้งที่ถึงแม้จะได้คะแนนออกมาแล้ว ก็ยังอาจจะต้องมีการทำสัมภาษณ์กับผู้ให้บริการที่จะถูกเลือกเพิ่มเติม เพื่อให้มั่นใจว่าสามารถแก้โจทย์ของเราได้อย่างแน่นอน เช่น การแจ้งปัญหาหรือความต้องการที่จะพัฒนาระบบในบางจุดที่เป็นปัจจัยความสำเร็จของโปรเจ็กต์ และให้ทางผู้ให้บริการลองออกแบบหรือนำเสนอไอเดียในการจัดการเรื่องเหล่านั้นแบบคร่าวๆ เพื่อดูว่าทิศทางในการทำงานไปในทางเดียวกันหรือไม่ เป็นต้น
ตัวอย่างตารางการเปรียบเทียบคะแนนผู้ให้บริการ

📍ปัจจัยเสริม
นอกจากที่เราอธิบายมาทั้งหมดนั้น จริงๆ ยังมีเกณฑ์อื่นๆ ที่เราเลือกใช้แล้วแต่ความจำเป็นของโปรเจ็กต์ ได้แก่ เกณฑ์ด้าน Behavioral Performance หรือ คะแนนพฤติกรรม ซึ่งเราจะมีการให้คะแนนในส่วนนี้หากเป็นโปรเจ็กต์ที่มีระยะเวลายาวนาน และมีงบประมาณสูง
ปฏิเสธไม่ได้จริงๆ ว่าทีมงานเป็นปัจจัยหลักในการทำให้การทรานส์ฟอร์มสำเร็จ ทั้งคนของเราและคนของผู้ให้บริการ ดังนี้ การลงรายละเอียดถึงปัจจัยด้านพฤติกรรมต่างๆ จึงอาจจะเป็นเรื่องที่จำเป็น เช่น ความกระตือรือร้นในการตอบรับ ความง่ายและรวดเร็วในการติดต่อ คุณภาพของเอกสารหรือข้อมูลที่ได้รับ ความเป็นมืออาชีพ เป็นต้น
✅ วิธีการคัดเลือก Vendor (ฉบับ ASAP Project)
ขั้นตอนที่เราใช้ในการคัดเลือกผู้ให้บริการประกอบได้ด้วย 5 ขั้นตอนหลัก ได้แก่
[1] สร้างเกณฑ์การตัดสินใจ
เริ่มต้นจากการเลือกเกณฑ์ที่จะใช้ในการตัดสินใจ โดยสามารถอ้างอิงจากที่เราอธิบายมาแล้วข้างต้น หรืออาจจะตัดบางข้อ หรือแตกบางข้อออกมาเพิ่มเติม แล้วแต่รูปแบบของแต่ละโปรเจ็กต์ ทั้งนี้ ต้องพิจารณาแล้วว่าเกณฑ์ที่จะใช้นั้นสามารถใช้เปรียบเทียบผู้ให้บริการทุกรายได้อย่างเท่าเทียมกัน
[2] ระบุน้ำหนักของเกณฑ์การตัดสินใจ
เมื่อได้หัวข้อเกณฑ์มาแล้ว ให้ใส่น้ำหนักเป็น % ในการตัดสินใจให้กับแต่ละข้อ โดยให้ทุกข้อรวมกันได้ 100%
การใส่น้ำหนักนี้จะเป็นตัวช่วยให้เห็นความสำคัญที่ต่างกันของแต่ละประเด็น เช่น อาจจะให้เรื่องงบประมาณสูงสุดที่จากทั้งหมด หากเป็นโปรเจ็กต์ที่มีงบประมาณจำกัดหรือไม่ยืดหยุ่น เป็นต้น
การระบุน้ำหนักของแต่ละหัวข้อ ควรมีการหารือกันในทีมทำงาน โดยให้ทุกคนช่วยกันลงความเห็น ถ้าตัดสินใจร่วมกันไม่ได้ อาจจะให้ทุกคนลงคะแนนแยก และใช้ค่าเฉลี่ยแทน
[3] ให้คะแนนในแต่ละเกณฑ์การตัดสินใจ
เมื่อได้น้ำหนักมาแล้ว ให้ทำการให้คะแนนให้แต่ละหัวข้อ โดยอาจจะใช้คะแนน 1-3 หรือ 1-5 แล้วแต่ความละเอียดที่ต้องการ ทั้งนี้ จะต้องมีกติกาที่ชัดเจนว่า การให้ 1 ไปจนถึง 5 คะแนนนั้นต่างกันอย่างไร
ตัวอย่างเช่น ในหัวข้อของระยะเวลาของโปรเจ็กต์ (Timeline) ให้ 1 คะแนนสำหรับรายที่ใช้ระยะเวลานานที่สุด หรือเกิน 15 เดือน และ 5 สำหรับสั้นที่สุดหรือต่ำกว่า 7 เดือน เป็นต้น
[4] สรุปคะแนนหลังถ่วงน้ำหนัก
เมื่อได้คะแนนมาแล้ว ให้สรุปคะแนนของแต่ละหัวข้อ สำหรับแต่ละผู้ให้บริการโดยคูณกับน้ำหนักที่ระบุแต่ละหัวข้ออีกครั้ง เพื่อให้ได้คะแนนที่บ่งบอกถึงระดับความสำคัญในการตัดสินใจด้วย
[5] สรุปและวิเคราะห์
เมื่อได้คะแนนของทุกรายมาแล้ว ให้ทำการวิเคราะห์อีกครั้งว่าการให้คะแนนนั้นบ่งบอกถึงความเป็นจริงของแต่ละรายมากน้อยเพียงใด ซึ่งหากเกณฑ์ในการให้คะแนนมีความชัดเจน คะแนนที่ได้จะเป็นความจริงระดับหนึ่ง
เมื่อทำการเรียงลำดับผู้ที่ได้คะแนนมากไปยังน้อยแล้ว ให้ประชุมร่วมกันเพื่อชี้แจงผล และเลือกรายที่จะเป็นผู้ให้บริการกับเราต่อไป
อย่างไรก็ตาม หลายครั้งที่ถึงแม้จะได้คะแนนออกมาแล้ว ก็ยังอาจจะต้องมีการทำสัมภาษณ์กับผู้ให้บริการที่จะถูกเลือกเพิ่มเติม เพื่อให้มั่นใจว่าสามารถแก้โจทย์ของเราได้อย่างแน่นอน เช่น การแจ้งปัญหาหรือความต้องการที่จะพัฒนาระบบในบางจุดที่เป็นปัจจัยความสำเร็จของโปรเจ็กต์ และให้ทางผู้ให้บริการลองออกแบบหรือนำเสนอไอเดียในการจัดการเรื่องเหล่านั้นแบบคร่าวๆ เพื่อดูว่าทิศทางในการทำงานไปในทางเดียวกันหรือไม่ เป็นต้น
ตัวอย่างตารางการเปรียบเทียบคะแนนผู้ให้บริการ

📍ปัจจัยเสริม
นอกจากที่เราอธิบายมาทั้งหมดนั้น จริงๆ ยังมีเกณฑ์อื่นๆ ที่เราเลือกใช้แล้วแต่ความจำเป็นของโปรเจ็กต์ ได้แก่ เกณฑ์ด้าน Behavioral Performance หรือ คะแนนพฤติกรรม ซึ่งเราจะมีการให้คะแนนในส่วนนี้หากเป็นโปรเจ็กต์ที่มีระยะเวลายาวนาน และมีงบประมาณสูง
ปฏิเสธไม่ได้จริงๆ ว่าทีมงานเป็นปัจจัยหลักในการทำให้การทรานส์ฟอร์มสำเร็จ ทั้งคนของเราและคนของผู้ให้บริการ ดังนี้ การลงรายละเอียดถึงปัจจัยด้านพฤติกรรมต่างๆ จึงอาจจะเป็นเรื่องที่จำเป็น เช่น ความกระตือรือร้นในการตอบรับ ความง่ายและรวดเร็วในการติดต่อ คุณภาพของเอกสารหรือข้อมูลที่ได้รับ ความเป็นมืออาชีพ เป็นต้น
💡 จงมั่นใจในการคัดเลือก
เมื่อเรามีเกณฑ์ที่ชัดเจน มีการให้ความสำคัญที่มาจากทุกคนที่มีส่วนร่วม และให้คะแนนอย่างเป็นธรรมแล้ว ให้เรา “Trust the Process” และเชื่อในผลที่ได้ เพราะไม่เช่นนั้น ก็จะกลับไปใช้ความรู้สึกในการตัดสินใจ และอาจมีปัญหาตามมา
ที่ ASAP Project เราใช้วิธีนี้ในการคัดเลือก Vendor จากกว่า 25 ประเภทซอฟต์แวร์/ซูโลชัน รวมถึงบริษัทรับพัฒนาระบบ (Developer) ซึ่งอาจจะต่างจากการคัดเลือกผู้ให้บริการซอฟต์แวร์เล็กน้อย เราได้ผู้ให้บริการที่สามารถตอบโจทย์ธุรกิจของลูกค้าของเราอย่างแท้จริง และสามารถทำงานกับลูกค้าได้อย่างราบรื่น โดยการคัดเลือกของเราจะเป็นการตัดสินใจร่วมกันระหว่างลูกค้าและทาง ASAP Project โดยเราจะเคารพน้ำหนักการตัดสินใจของลูกค้า และให้ความสำคัญกับการวางกฏเกณฑ์ที่เป็นกลางที่สุด
หากคุณกำลังพยายามคัดเลือกผู้ให้บริการเพื่อเข้ามาทรานส์ฟอร์มองค์กรของคุณ แต่ต้องการที่ปรึกษาที่จะช่วยชี้แนะให้อย่างเป็นกลาง รวดเร็ว และมีประสิทธิภาพ สามารถติดต่อเราได้ที่ hello@asapproject.co ครับ
#DigitalTransformation #VendorSelection

Feeling overwhelmed?
Let us help you find the right tools.

Feeling overwhelmed?
Let us help you find the right tools.

Feeling overwhelmed?
Let us help you find the right tools.

1448/18 Soi Ladprao 87 (Chandrasuk),
Klongchan, Bangkapi, Bangkok, 10240
© 2024 by ASAP Project Co., Ltd.
All Rights Reserved.

1448/18 Soi Ladprao 87 (Chandrasuk), Klongchan, Bangkapi, Bangkok, 10240
© 2024 by ASAP Project Co., Ltd.
All Rights Reserved.

1448/18 Soi Ladprao 87 (Chandrasuk), Klongchan, Bangkapi, Bangkok, 10240
© 2024 by ASAP Project Co., Ltd.
All Rights Reserved.