ปัญหาไอทีกับธุรกิจ

ปัญหาไอทีกับธุรกิจ
ถ้าคุณต้องตกอยู่ในสถานการณ์เพลี้ยงพล้ำดังกล่าวข้างต้น คุณจำเป็นต้องปล่อยวางทุกสิ่งทุกอย่างหรือไม่ก็เสแสร้งแกล้งทำเป็นว่า ทุกอย่างกำลังไปได้สวย นี่คุณคงไม่คิดหรอกนะว่า ไม่มีใครในวงการไอทีเคยประสบพบเจอกับสถานการณ์สุดเลวร้ายที่ไม่น่าจะเกิดขึ้นอย่างนี้มาก่อน คุณคิดผิดถนัดแล้วล่ะ เพราะผลการวิจัยจาก The Standish Group รายงานว่าโปรเจ็กต์ไอที 1 ใน 5 คว้าน้ำเหลวแทบจะในทันที และมากกว่าครึ่งเสร็จไม่ทันกำหนดหรือไม่ก็งบประมาณบานปลาย สาเหตุน่ะเหรอ? คำตอบมาตรฐานเชิงธุรกิจคงเป็นเพราะว่า “มันเป็นความผิดของระบบไอที” แล้วเลือกที่จะมองข้ามสาเหตุที่สามารถทำให้โปรเจ็กต์ล้มคว่ำไม่เป็นท่าได้พอๆ กันไปซะงั้น เช่น การจัดการข้อกำหนดที่ไม่ดี, การวางแผนธุรกิจที่ไม่เฉียบขาด, การสื่อสารที่ไม่ได้เรื่อง หรือแม้แต่ “ขอบเขตงานบานปลาย” ไปกันใหญ่เราจะยกตัวอย่างสถานการณ์สุดเลวร้ายด้านไอทีที่พบเห็นกันอยู่บ่อยๆ มา 5 สถานการณ์ ซึ่งโปรเจ็กเหล่านี้ล้วนประสบความล้มเหลวจนยากเกินจะเยียวยา ฝ่ายไอทีจะได้หาทางหลีกเลี่ยงจุดจบไม่สวยอย่างนี้ได้ เรื่องราวที่คุณจะได้อ่านต่อไปนี้เป็นเรื่องจริงแต่คงจะเปิดเผยข้อมูลบางส่วนออกมาไม่ได้ บางสถานการณ์ต้องย้อนกลับไปในยุค 90 ซึ่งเป็นยุคที่สำหรับเทคโนโลยีแล้วเสียเงินเท่าไรไม่อั้น ในขณะที่บางสถานการณ์ตัดตอนมาจากพาดหัวข่าว แต่บทเรียนที่มีค่าสามารถประยุกต์ใช้ได้กับทุกยุคทุกสมัยเลยทีเดียว
สถานการณ์ที่ 1: เอาต์ซอร์สออกอาละวาดย้อนกลับไปกลางยุค 90 บริษัทให้บริการเครื่องขายของอัตโนมัติต้องการที่จะประหยัดค่าใช้จ่ายด้วยการรวมศูนย์การทำงานทั้งหมดเอาไว้ที่ส่วนกลาง จึงว่าจ้างที่ปรึกษารายใหญ่ติดอันดับ 1 ใน 5 เข้ามาติดตั้งระบบ ERP มูลค่า 20 ล้านดอลลาร์ และนั่นก็เป็นต้นเหตุของความผิดพลาดครั้งใหญ่“เหตุการณ์กลับไม่เป็นอย่างที่คิด เพราะที่ปรึกษาได้แต่นั่งฝันหวานคิดจะสร้างระบบจัดการข้อมูลใหม่ทั้งหมดโดยไม่ใช้ของเดิมเลย แล้วคิดไปเองว่ารู้วิธีจัดการดีกว่าคนอื่น” Bob Price ซีอีโอคนก่อนของ Control Data และเป็นผู้แต่งหนังสือเรื่อง The Eye for Innovation: Recognizing Possibilities and Managing the Creative Enterprise (Yale University Press, 2005) กล่าว ผลก็คือเมื่อข้อมูลเก่าและใหม่มาเจอกันกลับล่มไม่เป็นท่า ราคาสินค้าในระบบ ERP กลับไม่ตรงกับราคาที่ปรากฎอยู่ในแค็ตตาล็อก ลูกค้าจึงปฎิเสธการชำระเงิน และที่แย่ไปกว่านั้น ระบบศูนย์กลางยังทำให้ราคาสินค้าแพงเกินกว่าจะเรียกเก็บเงินจากผู้ซื้อได้ รายรับดิ่งวูบลงทันที ผู้จัดการระดับกลางที่ไม่เคยได้รับการปรึกษาเกี่ยวกับระบบแต่ประการใดเลยประท้วงลาออกกันยกทีม ประธานบริษัทถูกไล่ออกเพราะผลงานชิ้นโบว์ดำสร้างความเสียหายให้กับบริษัท สุดท้ายซีอีโอบริษัทแม่ก็ต้องประกาศลาออกแสดงความรับผิดชอบด้วยเช่นกัน คุณจะทำอย่างไรดีถ้าที่ปรึกษาที่คุณคิดว่าสวรรค์ทรงโปรดส่งมาให้กลับกลายเป็นคนบดขยี้บริษัทคุณจนแหลกคามือ? 1. ประเมินความสามารถพนักงานในบริษัทเสียก่อน นี่เป็นเพราะว่าไม่มีใครในองค์กรเข้าใจโปรเจ็กอย่างแท้จริง จึงปล่อยให้ที่ปรึกษาบรรเลงเองเสียหมด ถ้าคุณไม่มีพนักงานที่มีความเชี่ยวชาญที่จำเป็นในงานนั้น หรือไม่สามารถว่าจ้างมืออาชีพที่มีความเชี่ยวชาญเข้ามาได้ ก็อย่าไปคิดทำโปรเจ็กแบบนี้ให้เปลืองเงินและเวลาเลย “เลือกทำธุรกิจในวิธีที่ไม่แพงจะดีกว่า” Price กล่าว “หากมัวไปฝืนทำงานที่คุณไม่เข้าใจ แล้วสุดท้ายมันก็คว้าน้ำเหลวอย่างนี้ สู้ไม่ทำอะไรเลยยังจะดีเสียกว่า”2. เลือกทางออกที่ตรงกับธุรกิจ กรณีนี้บริษัทพยายามอย่างสุดกำลังในการบีบให้โครงสร้างที่รวมอยู่ศูนย์กลางทับซ้อนพอดีกับแม่แบบธุรกิจที่กระจายอำนาจจากศูนย์กลาง แต่สุดท้ายแล้ว ระบบก็แก้ปัญหาด้วยการดึงข้อมูลยอดขายและรายการสินค้าไว้ไม่ให้ปรากฏ เลยทำได้แค่จัดการข้อมูลลูกค้าจากศูนย์กลางเท่านั้นเอง3. หลีกเลี่ยงเทคโนโลยีที่ไม่สามารถเข้าไปปรับเปลี่ยนได้ สำหรับกรณีนี้ ระบบ ERP เป็นระบบงานที่ต้องยืดหยุ่นได้ แต่ตัวโปรแกรมกลับเขียนไว้อย่างคลุมเครือด้วยภาษา ALGOL (Algorithmic Language) ซึ่งเป็นภาษาโปรแกรมที่กลุ่มที่ปรึกษาชอบใช้งาน แต่กลับไม่มีใครรู้วิธีใช้กันเลย Price บอก4. ควบคุมดูแลอย่างใกล้ชิด แม้แต่ข้อตกลงในการให้คำปรึกษาที่ว่าละเอียดอย่างที่สุดแล้วก็ยังไม่สามารถครอบคลุมรายละเอียดได้ครบถ้วนทุกสิ่งทุกอย่าง โดยเฉพาะเมื่อจำเป็นต้องเปลี่ยนแปลงหรือชี้แจงเพิ่มเติม ถึงแม้ว่าการใช้บริการที่ปรึกษาจะมีประโยชน์ คุณก็ยังจำเป็นต้องระบุลงไปในเงื่อนไขอย่างชัดเจนว่า คุณต้องการให้ที่ปรึกษาเข้ามาทำอะไรบ้าง แล้วคุณก็ต้องควบคุมดูแลอย่างใกล้ชิดด้วย Price กล่าว
สถานการณ์ที่ 2: โปรเจ็กต์บานปลายเกินกว่าจะทำให้สำเร็จลุล่วงไปได้เมื่อ 3 ปีที่แล้ว บริษัทให้บริการด้านเทคโนโลยีรายใหญ่ใน West Coast ตัดสินใจนำระบบการจัดการคอนเทนท์บนเว็บไซต์เข้ามาใช้เพื่อบริหารระบบสื่อสารภายใน รายการฟีเจอร์ที่ต้องการเริ่มบานปลายไร้ขีดจำกัด พวกเขาสามารถใช้ระบบเดียวกันนี้บริการลูกค้าได้หรือไม่ ? บริษัทที่รับรวมระบบงานรับปากเป็นมั่นเป็นเหมาะว่าได้แน่นอน แล้วการขายรายงานการวิจัยให้กับลูกค้าล่ะ? ก็ไม่มีปัญหาอีกเช่นกัน งบประมาณสำหรับโปรเจ็กนี้เลยพุ่งทะยานขึ้นไปถึง 100 ล้านดอลลาร์อย่างรวดเร็ว เหยื่อรายใหม่เข้ามาติดกับอีกแล้วใช่ไหม? ก็บริษัทที่รับรวมระบบงานเป็นคนขายซอฟต์แวร์สร้างระบบการจัดการคอนเท็นบนเว็บไซต์นั่นเอง ดังนั้นดูจะไม่มีเหตุผลใดที่ผู้ขายจะแก้ไขซอฟต์แวร์ของตัวเองแก้ไขไม่ได้ โดยเฉพาะเมื่อลูกค้าอัดฉีดเม็ดเงินมูลค่าหลายล้านดอลลาร์ในการพัฒนาระบบเพิ่มเติมตอนที่พวกเขาติดต่อเราเข้ามา บริษัทหมดเงินไปจวนจะ 280 ล้านดอลลาร์แล้ว แต่เปอร์เซ็นต์กรณีทดสอบที่ใช้งานได้จริงกลับเป็นศูนย์ George Kondrach รองประธานบริหารของ Innodata Isogen ซึ่งเป็นที่ปรึกษาด้านคอนเทนต์ supply chain กล่าว Innodata แนะนำให้ลดขนาดโปรเจ็กลงและเอาซอฟต์แวร์บริษัทอื่นเข้ามาจัดการงานในส่วนอื่นที่ระบบจัดการคอนเทนต์ไม่ได้เขียนขึ้นมาเพื่อตอบสนองงานนั้นจะดีกว่า Kondrach กล่าวว่า Innodata สามารถจัดการแก้ปัญหาโดยมีค่าใช้จ่ายเพียง 10 ล้านดอลลาร์เท่านั้นเอง แต่นั่นหมายความว่า ลูกค้าต้องกล้ายอมรับความล้มเหลว สุดท้ายแล้วลูกค้ากลับเลือกทุ่มเงินอีกหลายล้านอัดฉีดเข้าไปในแต่ละปีเพื่อพยายามทำให้ระบบใช้งานได้แต่ก็ยังไร้ซึ่งวี่แววจนป่านนี้คุณจะทำอย่างไรไม่ให้โปรเจ็กบานปลายยากเกินกว่าจะทำให้สำเร็จลุล่วงไปได้ 1. อย่าไปหลงเชื่อผู้ขายเสียทุกเรื่อง การว่าจ้างบริษัทรับรวมระบบที่สนใจอยู่แต่จะกอบโกยเงินเข้าตัวอย่างไรให้มากที่สุด หรือ มืออาชีพที่มีความเชี่ยวชาญอยู่กับสินค้าของผู้ขายเพียงรายเดียวล้วนเป็นสูตรสำเร็จที่นำไปสู่หายนะมานักต่อนักแล้ว Kondrach กล่าว ทางแก้ปัญหาใดก็ตามที่ไม่สามารถยืดหยุ่นได้จะพลอยทำให้เรามีทางเลือกน้อยลงไปด้วย2. รู้จักซอฟต์แวร์ เข้าใจความแตกต่างระหว่างฟีเจอร์ซอฟต์แวร์และประเภทสินค้าใหม่ อย่าหวังพึ่งระบบเดียวในการทำงานร่วมกับแอพพลิเคชันที่แตกต่างกัน ถึง 5 ชนิด3. อย่าปกปิดความผิด กล้ายอมรับความล้มเหลวเสียแต่เนิ่นๆ ซึ่งนับเป็นสิ่งดีที่คุณสามารถทำได้ “อย่าไปปั้นแต่งถ้อยคำสวยหรูให้กับโปรเจ็กที่กำลังล้มคว่ำไม่เป็นท่าว่า “กำลังคืบหน้าไปได้ด้วยดี” หรือ “กำลังพัฒนาอยู่” Kondrach กล่าว “บอกไปเลยดีกว่าว่า การตัดสินใจเกี่ยวกับโปรเจ็กเบื้องต้นไม่ประสบผลสำเร็จอย่างที่คาดการณ์ไว้”4. รู้ว่าเมื่อไรต้องหยุด “อย่าฝืนอัดฉีดเม็ดเงินเข้าไปทั้งๆ ที่รู้ว่ามันไม่มีประโยชน์” Patrick Gray ซึ่งเป็นประธานของ Prevoyance Group ซึ่งเป็นบริษัทที่ปรึกษาในนิวยอร์กกล่าว “ถึงแม้จะรู้ว่ามันเจ็บปวดที่ต้องสูญเงินไปเป็น 100 ล้าน แต่มันก็ยังดีกว่าสูญเงินจำนวนมหาศาลถึง 200 ล้านดอลลาร์


สถานการณ์ที่ 4 : ซอฟต์แวร์แห่งหายนะ ย้อนกลับไปตอนปลายๆ ยุค 90 ผู้ผลิตสินค้าบริโภครายใหญ่ใน Midwest คิดว่าระบบ ERP ใหม่เป็นเพียงแค่ใบเบิกทาง บรรดาผู้บริหารระดับสูงต่างพากันลงนามและแผนกไอทีก็งานยุ่งมาโดยตลอด หลายเดือนต่อมาหลังจากใช้จ่ายหมดไปแล้ว 40 ล้านดอลลาร์ โปรเจ็กก็เสร็จเรียบร้อยตามแผน แต่ยูสเซอร์กลับไม่เข้าไปใช้งานเลย “เมื่อพวกเขากดสวิตช์เปิดระบบ ยูสเซอร์ถึงกับนั่งอึ้งแล้วแทบจะไม่มีใครทำงาน เพราะไม่คุ้นเคยกับระบบใหม่” Phil Bloodworth ซึ่งเป็นผู้นำสำนักงาน U.S. ฝ่าย IT Effectiveness practice ของ PricewaterhouseCoopers (PwC) กล่าว ไม่มีใครคิดว่า ควรจะคุยกับคนที่องค์กรวางตัวให้เข้ามาทำงานร่วมกับระบบนี้ บางโมดูลก็ได้รับการแก้ไขให้เหมาะสมกับการใช้งานของแผนกอื่น แต่ส่วนใหญ่ของระบบก็ยังไม่มีใครยอมเข้าไปใช้งานอยู่ดี คุณจะทำอย่างไรไม่ให้โปรเจ็กราคาแพงกลายเป็นโปรเจ็กไม้ประดับสวยหรู ที่ไม่มีใครอยากใช้งาน? 1. พูดกับผู้ใช้เสียก่อน ยิ่งโปรเจ็กใหญ่แค่ไหน การสื่อสารก็ยิ่งสำคัญมากขึ้นเท่านั้น Joel Koppelman ซีอีโอของ Primavera Systems และเป็นผู้ผลิตซอฟต์แวร์บริหารโปรเจ็ก “โปรเจ็กอาจทำออกมาสมบูรณ์แบบก็จริง แต่ถ้าคนไม่ได้รับการเตรียมพร้อมให้รับมือกับการเปลี่ยนแปลงที่เกิดขึ้น โปรเจ็กก็ล้มเหลวอยู่ดีนั่นแหละ” 2. ทำให้โปรเจ็ก “เป็นที่รู้จัก” เชิญผู้ใช้ให้เข้ามามีส่วนร่วมในการให้ข้อมูลและคัดเลือกผู้เข้าร่วมในโปรเจ็ก Bloodworth แนะนำ “ให้ทุกคนเข้ามามีบทบาทด้วยการสอบถามถึงความต้องการ อะไรที่ระบบปัจจุบันทำได้ดีและอะไรที่ทำได้แย่ รวมถึงอะไรที่จำเป็นต้องใช้สำหรับงานนี้”3. หลีกเลี่ยงไม่ให้ “ขอบเขตงานบานปลาย” ตรวจสอบรายการฟีเจอร์ด้วยการระบุค่าใช้จ่ายลงไปทุกรายการที่ยื่นขอเปลี่ยนแปลง “การยื่นขอเปลี่ยนแปลงจากบรรดายูสเซอร์หรือผู้จัดการ “ที่ว่าสำคัญ” นั้น เอาเข้าจริงแล้วอาจลดทอนความสำคัญลงไปหากคำนวณเงินออกมาแล้วพบว่ามีค่าใช้จ่ายสิ้นเปลืองโดยใช่เหตุถึง 1.7 ล้านดอลลาร์” Gray กล่าว4. จัดฝึกอบรมอยู่เสมอ “คุณจำเป็นต้องจัดฝึกอบรมอยู่เสมอทั้งก่อนและหลังที่เปลี่ยนไปใช้ระบบใหม่แล้ว” Bloodworth กล่าว “บอกกับยูสเซอร์ว่า ‘ แบบฟอร์มรายงาน (เก่า) ตอนนี้เปลี่ยนหน้าตาเป็นแบบฟอร์มใหม่แล้ว และหน้าจอใหม่ของคุณจะเป็นแบบนี้’” 5. แบ่งงานออกเป็นส่วนย่อย “โปรเจ็กไอทีที่ใช้เวลาหลายปีและมีขนาดใหญ่เป็นสูตรสำเร็จที่นำมาซึ่งความล้มเหลวมานักต่อนักแล้ว ” Michael Hugos ซึ่งเป็นซีไอโอคนก่อนของสหกรณ์ตัวแทนจำหน่ายมูลค่าธุรกิจ 8 พันล้านดอลลาร์ และผู้แต่งหนังสือเรื่อง Building the Real-Time Enterprise:An Executive Briefing (John Wiley & Sons, 2004) “กุญแจสำคัญไขสู่ความสำเร็จก็คือการซอยโปรเจ็กใหญ่ออกเป็นส่วนย่อยที่สามารถแยกเป็นอิสระจากกันได้ และต้องสามารถใส่กลับเข้าไปรันต่อในโปรเจ็กใหญ่ได้ภายใน 3 – 9 เดือน” ในแง่ของธุรกิจ เราจะมองเห็นได้ว่าอะไรกำลังสร้างรายได้ และในขณะเดียวกันก็เตรียมตัวเตรียมใจทำแท้งโปรเจ๊กหากมันล้มเหลวไม่เป็นไปตามที่คาดหวังได้ทันท่วงที

สถานการณ์ที่ 5 : แผนกไอทีเรียนผูก แต่ไม่เรียนแก้Bloodworth จาก PwC กล่าวว่า เขาเคยถูกเรียกตัวเข้าไปให้คำปรึกษากับสถานประกอบการธุรกิจบันเทิงขนาดใหญ่ใน Midwest ที่ซึ่งเทคโนโลยีถูกมองว่าเป็นตัวการเลวร้ายที่จำเป็นต้องใช้ เนื่องจากไม่ได้เชื่อมโยงโดยตรงกับธุรกิจหลักของบริษัท แม้แต่การแก้ไขอะไรง่ายๆ ยังต้องใช้เวลานานมาก อีกทั้งงานเก่าที่สุม ๆ พอกรวมกันก็มีอยู่อีกไม่ใช่น้อย และที่สำคัญก็คือไม่เคยมีอะไรเสร็จอย่างที่ต้องการ อีกทั้งฝ่ายไอทีก็ดูจะเป็นต้นเหตุของความผิดพลาดและดูเหมือนจะต้องเป็นผู้รับผิดชอบแต่เพียงผู้เดียวเสียด้วยแต่ Bloodworth กลับค้นพบว่าความผิดพลาดนั้นไม่ได้เกิดจากแผนกไอที แต่เกิดจากวิธีการที่บริษัทบริหารต่างหาก หรือจะพูดให้ถูกก็คือบริหารโปรเจ็กผิดพลาด เพราะไม่มีความคืบหน้าในการอนุมัติโปรเจ็ก, จัดลำดับความสำคัญของงาน หรือ จะมีใครฟันธงได้ว่า โปรเจ็กไหนเก่าไปแล้วหรือไม่คุ้มทุนที่จะฝืนทำต่อไป “เราพบสมุดงานโปรเจ็กเป็นร้อยๆ ที่ทำไปเยอะแล้ว” เขากล่าว “ไอทีแค่จัดทรัพยากรไปให้กลุ่มที่เรียกร้องมากที่สุดเท่านั้นเอง” คุณจะตัดความต้องการที่ยุ่งเหยิงแล้วทำให้ไอทีกลับมาใช้การได้อย่างไร? 1. พูดความจริงกับผู้มีอำนาจ “คุณจำเป็นต้องมีใครสักคนในองค์กรที่สามารถถอยกลับไปตั้งหลักและพูดได้ว่า “เราควบคุมไม่ไหวแล้ว โปรเจ็กมีปัญหาและต้องหยุดเพื่อแก้ไขเสียก่อน” Bloodworth กล่าว “ถ้าไม่มีใครเต็มใจขับเคลื่อนโปรเจ็กไปข้างหน้า คุณอาจต้องว่าจ้างที่ปรึกษาภายนอกที่สามารถรายงานผลให้ซีอีโอทราบได้ว่า “ เรามีปัญหาเรื่องอำนาจสั่งการ และคุณต้องเข้ามาจัดการ”2. จำกัดจำนวนคนที่สามารถตัดสินใจได้ สิ่งแรกที่ PwC ทำคือ จัดตั้งคณะกรรมการระดับบริหารเพื่ออนุมัติโปรเจ็ก ตามมาด้วยคณะกรรมการระดับสองเพื่อบริหารจัดการรายวัน รวมถึงกระตุ้นให้ทุกคนเข้ามามีส่วนร่วมและรับผิดชอบค่าใช้จ่าย “การทำแบบนี้ช่วยแก้ไขปัญหาให้พวกเขาได้จริงๆ ” Bloodworth กล่าว 3. วิเคราะห์ สมุดงานโปรเจ็ก ทิ้งอะไรก็ตามที่เก่าเก็บหรือไม่สอดคล้องกับเป้าหมายธุรกิจหลัก แล้วจัดลำดับความสำคัญของสิ่งที่เหลือซะ4. ประเมินสถานะไอทีที่เป็นอยู่ ไอทีจะต้องเป็นมากกว่าการประสานระบบเข้าด้วยกัน Scott Christian ผู้อำนวยการฝ่าย IT Effectiveness practice ของ PwC กล่าว ในการสร้างสภาพแวดล้อมที่เทคโนโลยีได้รับการมองว่า เป็นตัวขับเคลื่อนสำคัญของธุรกิจ องค์กรต้องมอบอำนาจสั่งการให้พวกไอทีสามารถคิดเชิงกลยุทธ์เพื่อธุรกิจได้ ไม่ใช่ทำแค่เพียงรอคอยฟังคำสั่ง พวกเขาอาจจำเป็นต้องจุดประกายให้ซีไอโอเห็นพ้องต้องกัน ซึ่งซีไอโอก็ควรจะเป็นทั้งนักธุรกิจและนักไอทีด้วย