เมื่อเร็ว ๆ นี้ได้มีโอกาสพูดคุยกับรุ่นน้อง (เจ้าของกิจการ) ที่ประกอบธุรกิจที่ไม่เกี่ยวกับ IT เลย แต่มีความต้องการที่จะเอาระบบ IT มาจัดการกับคลังสินค้า ซึ่งเมื่อได้พูดคุยก็พบว่าน้องเขาก็ยังไม่ได้ตระหนักว่าการแค่คิดจะสร้างระบบ IT มาใช้งาน มันยังมีขั้นตอนที่ต้องรับทราบก่อน เพื่อที่การลงทุนนี้จะได้ผลลัพธ์ที่คุ้มค่ากับการลงทุน และไม่เป็นโครงการ IT ที่ล้มเหลวอันเนื่องจากปัญหาที่คิดไม่ถึงทั้งหลาย
ข้อมูลเบื้องต้น
จากที่พูดคุยหลายครั้งพอจะสรุปข้อมูลได้ตามรายการนี้
ปัญหาที่อยากจะแก้ : การจัดการคลังสินค้าซึ่งไม่ได้เป็นแบบรวมศูนย์ (ของกระจายไปตามสาขา) และยังมีเรื่องของหน่วยสินค้าที่ไม่ค่อยซื่อตรง (ไม่อาจจะจัดรูปให้ออกมาเป็นหน่วยมาตรฐานได้)
กลุ่มผู้ใช้งาน : ผู้มีอายุ และไม่ค่อยประสีประสากับการใช้งานคอมพิวเตอร์
รูปแบบการทำงานปัจจุบัน : ส่งข้อมูลการเบิก/ขายทาง Line มีคนช่วยรวมข้อมูลนี้ และทำข้อมูลลง Sheet ใน Google Docs
จาก 3 ข้อมูลนี้ ก็ถือว่าเป็นความต้องการหลัก (Core requirement) ที่ค่อนข้างแข็งแรงเลย มีเป้าหมายว่าอยากได้อะไร รู้ว่าใครเกี่ยวข้อง และเหมือนจะมีข้อมูลว่าคาดหวังอะไรกับผู้ใช้ได้บ้าง
ความรู้เบื้องต้นสำหรับการจัดหาระบบ IT
โจทย์ที่รับมานี่ถือว่าค่อนข้างดี เพราะแสดงว่าเจ้าของกิจการ ตระหนักแล้วว่า ข้อมูลที่อยู่ในระบบ จัดการง่ายกว่าข้อมูลที่อยู่ในกระดาษ (นี่ก็เป็นส่วนเล็ก ๆ ของกระบวนการ Digital Transformation นะ เพราะผมก็ไม่ทราบว่าในใจของน้องเขาคิดจะทำอะไรกับข้อมูลในระบบเหล่านี้อีก ในแง่ Business Intelligence หรือ Automation) แต่ด้วยความเชี่ยวชาญส่วนตัวที่ไม่ได้เกี่ยวอะไรกับ Inventory หรือ CRM เลยผมก็บอกกับตัวเองว่า นี่ไม่ใช่สนามที่เราจะ implement ให้เองแน่ (จริง ๆ น้องเขาก็มีตัวเลือกของซอฟต์แวร์ที่อยากจะใช้แล้ว) แต่ด้วยความเป็นห่วงที่รู้สึกว่าน้องเขายังต้องสู้กับอะไรอีกหลายอย่าง และดูยังไม่มีความเข้าใจว่าโครงสร้างราคาของงาน IT คืออะไร ผมจึงได้อธิบายประสบการณ์จากการทำงานสายนี้ให้น้องเขาทราบตามรายละเอียดที่จะกล่าวถึงต่อไปนี้
ทำไมจึงขายเป็นราคาเช่าใช้?
CRM ยี่ห้อหนึ่งที่ถูกเลือกขึ้นมา เป็น Open source แต่มี Implementor ในไทยให้บริการในลักษณะ Cloud service โดยผมคาดว่าน่าจะพ่วงฟังก์ชั่นเกี่ยวกับการออกเอกสารที่เกี่ยวข้องกับระบบภาษีของประเทศไทยเข้าไปด้วย (ในเว็บไซต์ของ Implementor มีหน้าตารูปแบบไฟล์ที่ออกมาจากระบบ) ส่วนราคาก็มีให้เลือกหลายรูปแบบ คำถามที่น้องเขาถามคือ ทำไมราคาจึงเป็นแบบนี้?
คำตอบของผมในมุมมองคนที่ทำระบบแบบ On-premise (ตั้งในที่ตั้ง, Data Center ที่ลูกค้าเข้าถึงได้) มาตลอดคือ ราคานี้เกิดจาก
- ค่าตั้งระบบ
- ค่าพัฒนาส่วนประกอบเพิ่มเติม (ถ้ามี)
- ค่าสนับสนุนการใช้งาน -- การตอบคำถามการใช้งาน, ช่วยเหลือเมื่อเกิดปัญหาจากการใช้งาน
- ค่าดูแลให้ระบบสามารถใช้งานได้ตามเงื่อนไขที่ระบุไว้ในสัญญา -- (ทำให้ระบบใช้งานได้ต่อเนื่อง, ปรับปรุงตัวซอฟต์แวร์, สำรอง/กู้ข้อมูล)
ไม่รอช้าผมก็โยนคำถามกลับไปหาน้องว่า
- ถ้าต้องตั้งระบบเอง (ก็ซอฟต์แวร์มันฟรี + มีอุปกรณ์เหลือที่จะทำ + มีคนทำให้) แล้วมีแรงสนับสนุนการใช้งานจากผู้ใช้เหรอ?
- มีแรงจะดูแลไม่ให้มันล่มหรือหากเกิดเหตุไม่คาดฝันจะต้องกู้ข้อมูลกลับมามีแรงทำเหรอ?
ใช่ครับ สิ่งเหล่านี้มีมูลค่าของมันหมดทั้งนั้น พอพูดถึงจุดนี้น้องเขาก็เริ่มคิดถึงแรงงานคน + ความสามารถที่จะต้องใช้เพื่อ 2 งานนี้ ก็พบว่ามันก็ไม่ใช่เรื่องเล่น ๆ เลย (นี่ยังไม่ได้คิดถึงเรื่องมาตรฐานการบริการต่าง ๆ ด้วย เพราะยิ่งเยอะก็ยิ่งแพง)
ผมคงไม่สามารถตอบได้ว่าตัวเลขราคาที่ได้มานั้นถูกหรือแพง แต่อย่างน้อยการให้ที่มาของราคานี้ไปก็คงทำให้น้องตัดสินใจได้ว่า ตัวเลขที่เห็นอาจจะไม่ได้แพงแบบไม่มีเหตุผล
ความคิดว่า แค่จ่ายเงินค่าบริการ/ค่าจ้าง ก็จบแล้ว มันแค่นั้นจริงเหรอ?
หัวข้อนี้ผมยังไม่ได้กล่าวไปถึงความต้องการที่เพิ่มขึ้นในอนาคต หรือการออกแบบซอฟต์แวร์ที่ดีอะไรทั้งสิ้น แต่กล่าวถึงปัญหาจากการเอาสิ่งแปลกปลอมเข้ามาสู่กระบวนการทำงาน กับคนที่ไม่ประสีประสากับคอมพิวเตอร์
ใช่ครับ เราไม่อาจจะคาดเดาได้ว่ามันจะมีแรงต่อต้านแค่ใด ซอฟต์แวร์ที่เจ้านายเห็นว่าดีแสนดี (เพราะเจ้านายอาจจะเชื่อแค่สไลด์นำเสนอของผู้ผลิต หรือลมปากของเซลล์) อาจจะเป็นฝันร้ายของลูกจ้างก็ได้ (และมันก็มักจะเป็นแบบนี้ในหลายองค์กร ที่บริหารแบบ Top-down ด้วยอำนาจที่ค่อนข้างเด็ดขาด) คำแนะนำที่ผมให้น้องไปคือ
ก่อนจะเลือกซอฟต์แวร์ใด ๆ มาใช้ ต้องแน่ใจว่ามันแก้ปัญหาที่เราอยากจะแก้จริง ๆ
แม้ว่าซอฟต์แวร์จะหน้าตาสวยงามใช้งานง่ายแค่ใด แต่ถ้าไม่สามารถแก้ปัญหา คลังสินค้าที่สินค้ามีหน่วยที่ไม่สามารถจัดให้อยู่ในรูปแบบมาตรฐานได้ ได้ มันก็คือการลงทุนที่อาจจะไม่ค่อยประสบผลสำเร็จเท่าไร เพราะจริง ๆ นี่คือปัญหาหลักที่ธุรกิจนี้ประสบอยู่ คือไม่สามารถตรวจสอบได้อย่างแม่นยำว่ามีสินค้าเหลือเท่าไรกันแน่ ทำให้มีความเสี่ยงที่จะเก็บสินค้ามาก/น้อย เกินไป และก็ยังนำมาสู่ปัญหาอื่น เช่น ภาระในการขนย้ายสินค้าที่เกิดขึ้นจากการไม่สามารถคาดการณ์การจัดเก็บที่เหมาะสมในแต่ละที่ได้ มูลค่าความเสียโอกาสที่เกิดจากปัญหานี้เป็นเรื่องที่แต่ละองค์กรต้องไปตีมูลค่าเอาเองเพื่อพิจารณาว่าราคาซอฟต์แวร์ที่จะจัดหามาใช้นั้นมันคุ้มค่าการลงทุนหรือไม่
เมื่อเลือกซอฟต์แวร์ได้ ก็ต้องมีกระบวนการนำผู้มีส่วนเกี่ยวข้อง (อาจจะใช้กลุ่มเล็กที่หลากหลาย หรือเอาแต่กลุ่มที่เปิดใจก็ได้ ซึ่งผลตอบรับก็จะได้มาคนละแบบ) มาทดลองใช้ซอฟต์แวร์ที่เลือก เพื่อดูว่าจะต้องมีการปรับแต่งหน้าตาซอฟต์แวร์ (ถ้าทำได้), เพิ่มฟีเจอร์, หรือจัดทำคู่มือเพื่อทำให้ผู้ใช้งานสามารถใช้ซอฟต์แวร์ได้อย่างมีประสิทธิภาพ ซึ่งในกระบวนการนี้เราก็สามารถตรวจสอบแรงต่อต้านที่อาจจะเกิดขึ้นจากการปรับเปลี่ยนกระบวนการทำงานนี้ รวมถึงอาจจะสามารถประเมินกำลังว่าต้องเตรียมการสำหรับสนับสนุนการใช้งานซอฟต์แวร์ในรูปแบบใด
กระบวนการนี้ในการพัฒนาซอฟต์แวร์ระดับองค์กรมันก็คือขั้นตอนของ Develop, Test, และ User Acceptance Test นั่นเอง ซึ่งก็สามารถปรับความเข้มข้นได้ตามงบประมาณที่มี (รวมไปถึง เงิน, เวลา, แรงงาน/แรงใจ)
ต้องมีแผนสำรองไหม?
หากซอฟต์แวร์ที่เลือกมามันไม่สามารถต่อสู้กับแรงต้านของผู้ใช้ (แน่นอนขั้นตอนที่ได้กล่าวถึงในย่อหน้าที่แล้วนั้นมันคือสถานการณ์แบบสมบูรณ์แบบ ซึ่งก็อาจไม่เกิดขึ้นก็ได้) สุดท้าย ก็ต้องมีแผนสำรองว่าจะมีกระบวนการ IT อื่นใดที่สามารถแก้ปัญหาหลักได้ เพื่อที่อย่างน้อยแผนที่จะเอาระบบ IT เข้าสู่กระบวนการธุรกิจมันจะได้ไม่สูญเปล่า มันอาจจะเป็นซอฟต์แวร์ตัวอื่นที่เอากลับเข้ามาในกระบวนการข้างต้นที่ได้กล่าวไป หรือวิธีการอัตโนมือก็ดีกว่าแบบเดิมอีกนิดหน่อยก็ได้
ความยากในเรื่องนี้คือ การที่เอาความรู้ใหม่ ๆ ให้กับลูกจ้างที่เขาอาจจะไม่ได้รู้สึกอยากจะกระตือรือร้นอะไรมาก (แต่ก็เป็นงานที่อาจจะหาคนมาทำแทนยาก) ถ้าต้องป้อนเรื่อย ๆ ก็อาจจะเป็นเหตุให้เกิดดราม่าในองค์กรได้ (จะให้ฉันเรียนอะไรยาก ๆ บ่อย ๆ อะไรนักหนา?) การจะตัดสินใจบังคับคนที่ไม่ค่อยจะเปิดใจให้เรียนรู้มันอาจจะทำไม่ได้บ่อย การเลือกก็ควรจะต้องค่อนข้างแน่ใจในระดับที่สูงมากและถ้าต้องเสียคนส่วนน้อยออกไป (ชั่งน้ำหนักว่าแล้วว่าต้องทำ) เพื่อสิ่งใหม่ที่ดีขึ้นก็จำเป็นต้องใช้ความกล้าในการตัดสินใจของผู้นำองค์กร นี่ก็อาจจะเป็นการพิสูจน์ว่าผู้บริหารรู้เรื่องเกี่ยวกับพนักงานของตัวเองแค่ใดด้วย
ทิ้งท้าย
คิดว่าหากผู้อ่าน อ่านมาจนถึงหัวข้อนี้ก็น่าจะพอเห็นภาพของขั้นตอนในการจัดหาระบบ (ซอฟท์แวร์) รวมถึงอุปสรรคที่อาจจะต้องเจอแบบคร่าว ๆ แล้ว อาจจะมองว่ามันเป็นขั้นตอนที่ดูไม่จำเป็นและเสียเวลา ซึ่งผมก็คงไม่ปฏิเสธในเรื่องนี้เพราะทั้งหมด มันอยู่ที่งบประมาณที่มี แต่ถ้าสามารถทำได้ มันจะช่วยลดความเสี่ยงของโครงการ IT ที่สิ้นเปลือง/ล้มเหลวได้