ซอฟท์แวร์ ERP (Enterprise Resources Planning) หากกล่าวตามความหมายเดิม คือ ซอฟท์แวร์ที่ช่วยบริหารทรัพยากรทั้งองค์กร รวมทั้งระบบบัญชี (Accounting) การเงิน (Financial) การจัดส่ง (Logistic) จัดซื้อ (Purchasing) การขาย (Sales Processing) การผลิต(Manufacturing) บุคคล (Payroll) และ ทรัพยากรมนุษย์ (Human Resources) แต่ในปัจจุบันซอฟท์แวร์บางตัว ไม่มีระบบบริหารการผลิต ไม่มีระบบบริหารทรัพยากรมนุษย์ ก็เรียกตัวเองว่าเป็น ERP Software แล้ว ดังนั้นความหมาย ERP ที่กล่าวนี้ จะหมายถึง ซอฟท์แวร์ที่ครอบคลุมถึงระบบ Financial Account และ Distribution เป็นอย่างน้อย

17 ขั้นตอนสำคัญที่ควรทำในการพิจารณาเลือกซื้อซอฟท์แวร์ERP

    1.Steering Committee (Optional)

     ขั้นตอนการแต่งตั้ง Steering Committee นี้เหมาะสำหรับองค์กรธุรกิจขนาดใหญ่ ที่จำเป็นต้องร่วมกันตัดสินใจในโครงการ
ที่สำคัญ หรือที่มีผลกระทบกับองค์กรโดยส่วนรวม ซึ่งหากเป็นองค์กรขนาดกลางถึงเล็ก อาจข้ามขั้นตอนนี้ไปได้ เพราะผู้มี
อำนาจสูงสุดในการตัดสินใจอาจเป็นบุคคลเพียงคนเดียว เช่น เจ้าของ กรรมการผู้จัดการ(Managing Director) ผู้จัดการทั่วไป(General Manager) เป็นต้น คณะกรรมการชุดนี้ ไม่ได้มีเพื่อเข้าไปทำงานโดยตรง แต่จะเป็นคณะทำงาน
ที่คอยเฝ้าดู กำกับให้การคัดเลือกซอฟท์แวร์ เป็นไปในทิศทางที่องค์กรต้องการ กำหนดงบประมาณในการลงทุน และสุดท้าย
เป็นผู้ตัดสินใจ ในการสรุปเลือกซอฟท์แวร์ กรรมการชุดนี้ ควรมีขนาดตั้งแต่ 3-5 คน แต่ไม่ควรมีเกินกว่า 7 คนเพราะจะทำให้
เกิดความไม่คล่องตัว กรณีต้องประชุมเพื่อร่วมกันตัดสินใจ คณะกรรมการ อาจคัดเลือกมาจากหัวหน้างาน ในแต่ละฝ่าย ที่มีผล
กระทบจากการใช้ซอฟท์แวร์ ERP ส่วนประธานคณะกรรมการ อาจเป็นบุคคล ที่ได้รับมอบหมายหรือเป็น CEO ก็ได้

2.Working Team
     เป็นขั้นตอนการตั้งทีมงาน หรือคณะทำงาน เพื่อศึกษาในรายละเอียด ของการเลือกซอฟท์แวร์ (Software Selection) ซึ่งทีมงานนี้ จะประกอบไปด้วย ตัวแทนจากฝ่ายหรือแผนกต่างๆ ที่จะมีผลประทบ จากการใช้งานซอฟท์แวร์ ERP ซึ่งบางคน
อาจจะอยู่ทั้งใน Working Team และ Steering Committee ด้วยก็ได้ องค์กรขนาดเล็ก อาจมีทีมงานไม่กี่คน ส่วนองค์กรใหญ่ ก็จะจำนวนมากขึ้นตามสัดส่วน

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

4. Prepare Budget and Time Frame
     เมื่อทีมงาน ได้วิเคราะห์ถึงข้อดีข้อเสีย และความคุ้มค่า ในการใช้ซอฟท์แวร์ เพื่อแก้ปัญหาต่างๆ และมีข้อสรุปว่า จะต้องเปลี่ยน หรือจัดหาซอฟท์แวร์ใหม่ และได้นำเสนอ Steering Committee แล้ว ควรจะได้ข้อสรุปจาก Steering Committee ถึงงบประมาณการลงทุน อย่างคร่าวๆ และระยะเวลาของแผนงาน เพื่อทีมงานจะได้มั่นใจว่า เมื่อเลือกซอฟท์แวร์ได้แล้ว องค์กรจะมีงบประมาณ จัดซื้อจัดจ้างได้ และมีแผนงานการปฏิบัติงานที่ชัดเจน

5. Hire an Independent Consultant (Optional)
     ในบางองค์กร โดยเฉพาะองค์กรขนาดใหญ่ มักมีการว่าจ้างที่ปรึกษา หรือบริษัทรับปรึกษา มาทำการเลือกซอฟท์แวร์ ซึ่งที่ปรึกษาเหล่านี้ โดยเฉพาะในรูปนิติบุคคล มักมีค่าบริการที่ค่อนข้างแพง และมักมีความรู้ความเชี่ยวชาญ ในซอฟท์แวร์แค่
บางตัวเท่านั้น ดังนั้นหากทีมงานคิดว่า ตนไม่มีความรู้ความสามารถเพียงพอ ที่จะรู้ว่าองค์กรต้องการอะไร องค์กรมีปัญหาอะไร
ที่ต้องการแก้ไข หรือต้องการใครสักคนมาเป็น “แพะ” กรณีเลือกซอฟท์แวร์แล้วผิดพลาด ก็นับว่ามีเหตุผลในการจ้างที่ปรึกษา

6. Requirements Listing
     ในขั้นตอนนี้ ทีมงานจะต้องทำการ สรุปความต้องการ หรือ Requirements ขององค์กร จากฝ่ายต่างๆ แผนกต่างๆหรือ
หน่วยงานต่างๆ ว่าต้องการซอฟท์แวร์ที่มีความสามารถ (Features) อะไรบ้าง ออกมาเป็นข้อๆ เช่น ระบบบัญชีต้องการ
ความสามารถ Consolidate ข้ามบริษัท ระบบขายต้องการความสามารถ Multi Currency เป็นต้น ความต้องการด้าน
เทคโนโลยีเป็นอย่างไร เช่น ต้องการ Server เป็น Windows2000หรือ UNIX ใช้ฐานข้อมูลเป็น File Base หรือ Database เป็นต้น

7. RFP (Optional)
     เมื่อสรุปความต้องการได้แล้ว บางองค์กรอาจมีการทำ RFP (Request For Proposal) ที่สรุปความต้องการทั้งหมด เป็น
เอกสารเพื่อเตรียม สำหรับผู้เสนอขายซอฟท์แวร์ (Vendors) ซึ่งใน RFP มักมีการอธิบายถึงองค์กรอย่างคร่าวๆ เพื่อให้ผู้เสนอ
ซอฟท์แวร์ รู้จักองค์กรในบางส่วน และ List รายละเลียด Features ของซอฟท์แวร์ที่ต้องการ รวมถึงคำถามต่างๆ ที่องค์กร
ต้องการทราบจากผู้ขาย เช่น ประวัติบริษัท ข้อเสนอด้านเทคนิค ราคา แผนการ Implement แผนการติดตั้ง แผนการอบรม แผนการบำรุงรักษา เป็นต้น

8. Call Vendors
     จากนั้นจึงหาข้อมูลจากหลายๆแหล่ง เช่นจากโฆษณาตามนิตยสาร สิ่งพิมพ์ หนังสือพิมพ์ อินเตอร์เน็ต หรือจากคู่ค้าที่ใช้ซอฟท์แวร์ต่างๆ เพื่อรวบรวมรายชื่อผู้ขายซอฟท์แวร์ ERP ทั้งหมด ที่คิดว่าจะติดต่อได้ เพื่อแจ้งให้ทราบว่าองค์กรมีความต้องการระบบ ERP และเรียกให้ผู้ขายทั้งหลายมารับ Requirements หรือ RFP เพื่อนำเสนอเป็น Proposal ต่อไป

9. Evaluate Proposal
     เมื่อผู้ขายทั้งหลายมีการเสนอ Proposal ตามเวลานัดหมายแล้ว คณะทำงานก็จะต้องศึกษา Proposal ของผู้ขายรายต่างๆ ว่า เสนอมาตรงกับความต้องการหรือไม่ อย่างไร โดยอาจทำเป็นตารางด้วยโปรแกรม Spreadsheet เปรียบเทียบ เช่น เสนอระบบ
อะไรบ้าง ราคาเท่าไร โดยอาจเปรียบเทียบ เฉพาะประเด็นที่สำคัญๆก่อน เช่นราคา เทคโนโลยี ระบบหลักที่เสนอ ระยะเวลาการ Implement เป็นต้น

10. Eliminate Poor Choices
     เมื่อได้ตารางเปรียบเทียบแล้ว ก็ทำการตัดผู้ขายบางรายที่น่าสนใจน้อยออกไปก่อนโดยค่อยๆตัดไปทีละรายเช่น เสนอราคา
เกินงบประมาณไปมาก จนคิดว่าไม่น่าจะต่อรองราคาได้ หรือ เสนอระบบที่เป็นสาระสำคัญไม่ครบ หรือมีเทคโนโลยีไม่เหมาะสม
กับองค์กร เป็นต้น ขั้นตอนนี้ควรคัดเลือกให้เหลือเพียง 3-5 ราย ตามความเหมาะสม

11. Software Demonstration
     เมื่อเลือกผู้ขายได้ 3-5 รายแล้ว จึงนัดผู้ขายแต่ละราย มาทำการสาธิตซอฟท์แวร์ ให้ทีมงานดู ขั้นตอนนี้เป็นขั้นตอนที่สำคัญ
มาก ขั้นตอนหนึ่ง เพราะทีมงานจะได้มีโอกาสเห็น ถึงการทำงานของซอฟท์แวร์ และได้มีโอกาสซักถาม ถึงรายละเอียดของ
ซอฟท์แวร์ จากผู้ขายโดยตรง ในการดูการสาธิต ของซอฟท์แวร์แวร์ควรดูไปตาม Flow ของการทำงานจริงขององค์กร เพื่อจะ
ช่วยให้มีความเข้าใจได้ง่าย และสามารถเปรียบเทียบ กับสภาพการทำงานจริง ไม่ควรดูกระโดดข้ามไปข้ามมา ซึ่งหากมีข้อสงสัย
ประการใด ควรจะซักถามผู้สาธิตทันที ถ้าผู้สาธิตตอบได้ไม่ชัดเจน ควรจำลองสถานการณ์ แล้วให้ผู้สาธิตทำให้ดู ไม่ควรแค่ถาม
ว่า ซอฟท์แวร์ทำได้หรือไม่ แต่ควรดูในรายละเอียดลงไปว่า ทำได้อย่างไร ผลการทำงานถูกต้องหรือไม่ วิธีการของซอฟท์แวร์ มีความเป็นไปได้ เมื่อนำมาปฏิบัติงานจริง ซึ่งจะต้องทำทุกวัน หรือเมื่อมีรายการจำนวนมากๆหรือไม่การดูการสาธิตนี้ ไม่ควรจะ
เร่งรัดจนเกินไป เพราะอาจจะตกหล่นในบางรายละเอียด เพราะซอฟท์แวร์ ERP หรือ ซอฟท์แวร์ด้านบัญชีนั้น หากดูคร่าวๆ แล้วจะคล้ายคลึงกันมากๆ จะแตกต่างกัน ก็แต่ความสามารถ ในรายละเอียดปลีกย่อยลงไป หากการสาธิต ไม่สามารถดูได้จบ ภายในวันเดียว อาจจัดให้มีการสาธิตหลายวันได้ ซึ่งเป็นสิทธิของผู้ซื้อ ที่จะขอดูการสาธิต จนกว่าจะเข้าใจหรือมั่นใจ ขณะดู
การสาธิตควรมีการทำ Check List ของซอฟท์แวร์แต่ละราย เพื่อป้องกันการสับสน เมื่อผ่านการดูไปหลายๆราย ซึ่ง Check List นี้ ก็คือ List ของ Features ที่องค์กรต้องการ หรือเป็น List Features ที่ดีๆที่ซอฟท์แวร์บางตัวมีให้และสามารถนำมาใช้
ประโยชน์ได้ หากซอฟท์แวร์ตัวใดที่มี Features มากเกินกว่าที่องค์กร จะมีโอกาสได้ใช้ภายใน 5 ปี ก็ควรสรุปเพิ่มเติม เป็น
หมายเหตุไว้ เพราะการมี Features ที่มากมายเกินไป นอกจาก จะไม่ได้ช่วยเพิ่มประสิทธิภาพ ในการทำงานแล้ว ยังทำให้การ Implement และเรียนรู้ได้ยากตามไปด้วย

12. Software Testing (Optional)
     เมื่อดูการสาธิตของซอฟท์แวร์แล้ว หากต้องการเพิ่มความมั่นใจมากขึ้น อาจขอให้ผู้ขายทำการทดสอบซอฟท์แวร์ ใน
สถานการณ์จำลองจากการทำงานจริง โดยอาจนำข้อมูลขององค์กรย้อนหลัง 15-30 วัน ทดลองป้อนข้อมูลเข้าซอฟท์แวร์
มาตรฐาน เพื่อดูความมีเสถียรภาพ ความเร็ว และความถูกต้องของซอฟท์แวร์ เพราะในขั้นตอนการสาธิต จะไม่สามารถเห็น
ความมีเสถียรภาพ ความเร็วขณะใช้งานจริง และความถูกต้องของรายงานได้ เนื่องจากผู้ขายอาจหลีกเลี่ยงที่จะสาธิตบาง Features หาก Features นั้นทำงานได้ไม่ดีหรือยังมี Bug ได้ซึ่งขั้นตอนการทดสอบนี้ ซอฟท์แวร์บางตัวอาจสามารถ
ทำได้โดยง่าย หากเป็นซอฟท์แวร์ที่สามารถติดตั้ง เรียนรู้และใช้งานได้ง่าย และไม่เป็นภาระมากเกินไปทั้งฝ่ายผู้ซื้อและผู้ขาย แต่ซอฟท์แวร์บางตัวอาจทำได้โดยยาก เพราะมีค่าใช้จ่ายในการอบรมและ Implement ที่สูง นอกเสียจากว่าจะสามารถตกลง
กับผู้ขายได้ ในเรื่องเงื่อนไขและค่าใช้จ่ายในการทดสอบนั้น

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

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

15. Negotiation
     ขั้นตอนการเจรจาต่อรองเป็นขั้นตอนหลังจากที่ได้ข้อมูลเพื่อประกอบการตัดสิน ใจด้านต่างๆ ครบถ้วนแล้ว จากนั้นจึงนำ
ข้อมูลที่ได้มาทำการวิเคราะห์ ให้คะแนน ถ่วงน้ำหนักในประเด็นต่างๆ ที่องค์กรให้ความสำคัญสูงสุดและรองลงไป เช่นให้น้ำหนัก Features ของซอฟท์แวร์ 50% ราคา 30% การบริการ 10% แผนการ Implement 10% เป็นต้น แล้วจึงเรียงลำดับผู้ขายที่ได้
คะแนนรวมจากสูงสุดไปต่ำสุด เมื่อได้ชื่อของผู้ขายที่คิดว่า น่าสนใจที่สุด 3 อันดับแรก หากได้คะแนนใกล้เคียงกันมากควรเรียก
ทั้ง 3 รายมาเจารจาต่อรองเพื่อหาข้อเสนอที่คิดว่าดีที่สุด เป็นประโยชน์ต่อองค์กรมากที่สุดแล้วจึงนำเสนอ Steering Committee เพื่อตัดสินใจขั้นสุดท้ายอีกครั้ง แต่หากผู้เสนออันดับที่ 1 มีคะแนนนำอันดับ 2 และ 3 สูงมาก ก็ควรเจรจากับผู้ขายอันดับที่ 1
เพียงรายเดียว หากข้อเสนอต่างๆสามารถที่จะตกลงกันได้ ก็ไม่ควรเลือกอันดับรองลงไปมาเจรจาอีก เพราะนอกจากจะเป็น การ
เสียเวลาแล้ว ผู้ขายอันดับที่สอง เมื่อรู้ตัวว่ามีคะแนนห่างจากอันดับแรกมาก อาจต้องการชักใบให้เรือเสีย แกล้งเสนอตัดราคา
และเงื่อนไขที่จูงใจมากๆเพื่อดึงดูดใจคณะทำงานให้หันมา พิจารณา ทั้งๆที่คะแนนโดยรวมแล้วสู้ไม่ได้ และด้วยข้อเสนอที่จูงใจ
เกินไป อาจเป็นไปได้ยากที่ผู้ขายรายนั้นจะทำโครงการให้ได้ดี เนื่องจากต้องไปลดต้นทุน การบริการในภายหลัง ซึ่งท้ายที่สุด
ผู้ซื้อจะได้รับผลกระทบจากการลดราคามากเกินไปอยู่ดี

16. Make Decision
     เมื่อทีมงาน นำเสนอทางเลือกต่างๆ เข้าสู่ที่ประชุม Steering Committee เพื่อพิจารณาตัดสินใจในขั้นสุดท้าย หากได้รับ
ความเห็นชอบก็ดำเนินการเตรียมสัญญาเพื่อจัดซื้อจัดจ้างต่อไป แต่หากมีบางประเด็นที่ต้องทบทวน ก็อาจต้องเรียกผู้ขายเข้า
มาเพื่อชี้แจงหรือเจรจาต่อรองกันใหม่ จนกว่าจะได้ข้อสรุปเป็นที่พอใจกันทั้ง 2 ฝ่าย

17. Review Contract
     เมื่อได้ข้อสรุปข้อเสนอต่างๆจากผู้ชนะการคัดเลือกแล้ว หากมูลค่าการลงทุนเป็นมูลค่าที่ค่อนข้างสูงหรือมีรายละเอียดข้อตกลง
ปลีกย่อย ค่อนข้างมาก ควรมีการทำสัญญาการซื้อขาย หรือสัญญาว่าจ้างไว้เป็นหลักฐาน เพื่อป้องกันกรณีเกิดความเข้าใจ
ไม่ตรงกันในภายหลัง และจะได้เป็นกรอบ กติกาและบรรทัดฐานในการทำงานต่อไปหลังจากที่ได้ตกลงซื้อขายกันเรียบร้อยแล้ว

     การพิจารณาเลือกซื้อซอฟท์แวร์ ERP หรือ Accounting Software หากทำตามแนวทาง 17 ขั้นตอนดังกล่าวแล้วอาจมีข้อเสีย
คือ มีขั้นตอนที่ต้องใช้เวลาอยู่บ้าง ซึ่งองค์กรควรจะมีแผนงานที่ชัดเจนและมีการเตรียมการไว้ล่วงหน้า ว่าจะใช้เวลาไปกับ 17 ขั้นตอนนี้นานเท่าใด ซึ่งโดยปกติ ควรอยู่ในระดับ 1-4 เดือนเป็นอย่างน้อย แต่การทำงานอย่างมีขั้นตอนนี้จะมีข้อดีคือ จะทำให้
องค์กรได้ซอฟท์แวร์ที่ตรงกับความต้องการมากที่สุด ลดความเสี่ยงจากการซื้อมาแล้วแล้วใช้ไม่ได้ นอกจากนั้นการทำงาน
ในรูปแบบของทีมงานหรือคณะบุคคล ยังเป็นการระดมความคิด เปิดโอกาสให้แค่ละคนมีส่วนร่วมในการตัดสินใจ และลดโอกาส
ในการทุจริตประพฤติมิชอบอีกด้วย

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