เมื่อรู้ว่าต้องย้ายไป SAP
ในการประชุมประจำปี (ต้นปี) ผู้จัดการ IT บริษัทแม่ มีบอก "แนวคิด" จะย้าย ระบบฯ ไปใช้ SAP
ด้วยเหตุผล ... (ไปดูโฆษณา ข้อดีของการซื้อ SAP ได้ครับ)
โดยผู้จัดการ ได้อ้างว่า ใช้เวลารวบรวม มาประมาณ 6 ปี
(3 ปี แรก ยังเป็นผู้ช่วย เริ่มเรียนรู้งานภาพรวม 3 ปีหลัง เป็นช่วงที่เป็นผุ้จัดการเต็มตัว)
สภาพ ณ.เวลานั้น ส่วนตัวฟันธงว่า ต้องเกิดขึ้นแน่
แต่ผู้จัดการ IT ก็ยังมีอุปสรรคคือ
ประธาน ส่งเรื่องกลับให้ไปทบทวนใหม่ เพราะราคาที่เขียนมา "แพงมาก"
ผ่านไป 9 เดือน ในที่สุดก็ถึง วันที่ได้รับการยืนยันว่า ต้องย้าย Legacy ไป SAP
(จดหมายจากประธาน)
ปิดฉาก "ความไม่ชัดเจน" และการโยนหินถามทาง (ข่าวถูกปล่อย มาถามทิศทางเป็นระยะๆ)
ส่วนตัว ถือว่า "ชัดเจน" ดีกว่า ปล่อยให้เป็นเรื่องที่คุยกันแบบ "ไร้ทิศทาง"
ใครที่ใช้ระบบที่พัฒนาขึ้นมาเอง -> เปลี่ยนไปใช้ระบบฯ ที่มีความเข้มงวดสูง
- มีปฏิกิริยา ต่อต้าน มากมาย
คนที่เกี่ยวข้อง มากกว่า 98% "ไม่รู้จัก"
- มีปฏิกิริยา ต่างๆ รออยู่มาก (อยากลอง, ไม่อยากเปลี่ยนแปลง, กลัว,...)
ช่วงเวลาที่ "ไม่ชัดเจน" ทำให้ เวลาทำทำงาน มาคุยเรื่องที่ "ไม่รู้" ซ้ำๆๆๆๆๆๆๆๆ
ขั้นต่อไป
SAP จะเป็นตามคำล่ำลือ Sad After Purchase หรือไม่ ?
เป็นหน้าที่ของผู้นำ ที่จะบริหาร "การเปลี่ยนแปลง" ครับ
ที่มา
หลายๆ คนที่คิดจะเปลี่ยน คงเคยอ่านจากบทความต่างๆ
ซึ่งมีการเรียงลำดับไว้อย่างดี แต่มันยาววววว
มาลองดู ที่มา อีกรูปแบบหนึ่ง
Key Man
เป็นผลมาจากการเปลี่ยน Key Man สำคัญ- เปลี่ยน ประธาน ที่เก่ง + มีความรอบรู้มากขึ้น
เคยแสดง ฝีมือผ่านการบริหาร โรงงานขนาดกลาง (ทำสิ่งที่ต่างกับ คนก่อนๆ)
- การทำให้ พนักงานรู้สึกใกล้ชิดกับ ผู้นำ (รับรู้ปัญหา,คิดอะไร อยู่ ผ่านวารสารประจำเดือน)
(ต่างจาก บทความประจำปี,งวด ซึ่งจะพูดแต่ภาพกว้าง เหมาะกับ ให้คนบริษัทอื่นมาอ่าน 555)
ผมมีโอกาส ที่เข้าร่วมประชุม ขณะที่ ผู้จัดการ IT อธิบาย S/w ตัวหนึ่ง
ประธาน พูดออกมาว่า S/w นี้่มีมานานแล้ว เขาไม่เคยรู้ว่า "มี"
ขอให้อธิบายว่ายังมีสิ่งดีๆ อื่นๆ หรือไม่ ?
- เปลี่ยน ผู้นำด้าน IT ที่เก่ง+ ความรอบรู้มากขึ้น
เคยแสดง ฝีมือเปลี่ยน H/w ที่ไม่มีใครกล้าเปลี่ยน 20 ปี
โดยการ (ให้เกียรติ) "รอ" จน คนที่ดูแลใกล้เกษียณ แล้วโอนย้ายงาน มาทำเอง
เป็นผู้ออกแบบระบบการเงิน/การบัญขี ที่ดีมากตัวหนึ่ง
ช่วง 3 ปีที่เริ่มเป็นผู้จัดการ 2 ปี มุ่งเน้นไปด้าน Hw (ที่ตนเองไม่ถนัด) และ 1 ปี
ถัดไป ไปทดสอบแนวคิดกับการผลิต
ทำให้ วิธีการ "ชั่งน้ำหนัก" ทางเลือกกันใหม่หมด
จะตอบว่า ของเดิมดีแล้ว, เปลี่ยนไม่ได้, เปลี่ยนยาก (กลัว จนแทบไม่ต้องทำอะไ)
หรือ พอจะเปลี่ยนได้ (มีตัวเลือก ...)
คนอื่นๆ - องค์กรไม่ได้ทำงานแค่ 2 คน ต้องมีคนอื่นๆช่วย
ปรกติ ผู้นำ จะเตรียม Key Man ระดับต่างๆ มาช่วย สัมพันธ์กับแผน (ที่ใช้เวลานาน)
การสร้าง/เตรียม คน "ต้องใช้" เวลา
ดังนั้นการวางแผนที่ดี จะเป็นการลดความเสี่ยงได้มาก
Technology
20 ปีที่แล้ว ผมเริ่มทำงานบนเครื่่อง IBM S/38
เป็นช่วงที่กำลังทิ้งเครื่องรุ่น S/36 (รุ่นเก่า) และกำลังเริ่มติดตั้ง IBM AS/400 (เครื่องใหม่กว่า)
หลังจากนั้น ผมก็ได้เห็นการเปลี่ยนเครื่อง ทุกๆ 5 ปี, 3 ปี (เปลี่ยนถี่ขึ้นน๊ะ)
ในอดีต User จะเห็นเครื่องที่มีตาพิสดาร (เครื่องใหญ่มาก, อุปกรณ์ประกอบแปลกๆ)
ถ้าบอกว่า แพง ก็รู้สึก สมเหตุสมผล (ความรู้สึก > ความจริง)
มาวันนี้
- ตัวเครื่อง หน้าตาเหมือนกับ PC Server ทั่วไป
User แยกไม่ออกว่า เราใช้อะไรอยู่ = ผู้บริหาร จะรู้แค่ว่า ภาพรวมมันแพงกับ PC Server ธรรมดา
- มีทางเลือกใหม่ (ศัพท์ใหม่) มากขึ้น บางเรื่อง "คนทั่วไป" ก็รู้ละเอียดมาก (กว่า ฝ่าย IT)
ฝ่าย IT จะมาบอกว่า "ไม่รู้" "ยังไม่พร้อม" ... คงตอบได้ไม่นาน
คิดว่าจะใช้ เทคโนโลยี VM คิดมา 5 ปีแล้ว เพิ่งจะตัดสินใจ "ซื้อ"
(เกิดเทคโนโลยี Cloud มีหลายบริษัท อื่นเริ่มเข้าไปใช้งานกันแล้ว) ... คิดนานไปหรือเปล่า ?
Q: ทำอย่างไร ? ให้ขั้นตอนที่ช้า ให้เร็วขึ้น ?
A: ทำตามสิ่งที่ควรเป็น มากกว่า ทำตามคำสั่ง (สั่งไม่ครบ ก็ไม่ทำ)
การจัดการ
การบริหาร "การเปลี่ยนแปลง" ที่ผ่านมา
คือ เปลี่ยนให้น้อยที่สุด (รู้สึกไม่เปลี่ยน) ทำให้เกิดความ "เคยชิน" (อันนี้ไม่ดีแล้ว)
ตัวอย่าง เช่น การเปลี่ยน H/w, S/w ที่ User รู้สึก เหมือนไม่เปลี่ยนแปลง
,ฝ่าย Admin เรียนรู้เพิ่มเติมเล็กน้อย
- Hw : IBM S/36 -> S/38 -> As/400 -> iSeries
- RPG II -> RPG III -> RPG/400 -> RPG ILE + SQL (มีใช้ <10% ที่เหลือใช้ของเดิม)
ในด้าน H/w บริษัทได้สร้างทีมงาน ไว้หลายคน (มีทีมงานปรึกษากัน)
แต่เมื่อเวลาเปลี่ยนไป
- รูปแบบการทำงานที่แยกหน้าที่ั่ชัดเจน (ทีมลดขนาดลง)
- "จำกัด" การเรียนรู้ (ลด งบฯ)
- และ บริการที่ดีขึ้นของ Vendor
(คุณไม่ต้องเสียเวลา/เงิน เตรียมคน เพียงแค่จ่ายค่าบริการเพิ่มอีกนิด)
>> เส้นทาง ดังกล่าว ดีมากเมื่อทุกจุดทำงานได้ดีเยี่ยม
แต่จะแย่มาก เมื่อทุกจุดด้านบน "ทำไม่ได้" จะเป็นการบีบให้ตัวเลือก "มีน้อยลง"
Vendor ที่ดูแลเครื่อง IBM iSeries (H/w เฉพาะ) ในไทย มีกี่ราย, ที่เก่งจริงๆ มีกี่ราย
ทีมงานที่น้อย (จำกัด) เมื่อต้องเลือก "ทำ" (เพิ่มงาน) หรือ "ไม่ทำ" จะเลือกอะไร ?
>> แสดงให้เห็นว่า รูปแบบ ที่คิดว่าดี แต่เมื่อเวลาผ่านไปนานขึ้น วิธีดังกล่าวอาจจะไม่เหมาะ
ที่ผ่านมามีการเปลี่ยนแปลง "รุนแรง" สำหรับ User
แต่เป็นไปทิศทางที่ดี (แรงส่งดี) แต่ทีมงาน ที่จำกัด ก็จะบอกว่ายุ่งยาก(มาก) เช่น
- การเลือกใช้ eMail (Lotus Note)
- การอนุญาตให้ใช้ IE บน Windows -> เพิ่มรายงานในรูปแบบ Web
- การเปลี่ยน MS Office จาก XP เป็น 2007
ถ้าผู้นำ มีความเชื่อว่า ไม่ต้องอธิบาย(เป็น sw ส่วนบุคคล), แค่อธิบายสั้นๆ ครั้งเดียว User จะทำได้เอง
(คิดในมุมที่ว่า โปรแกรมเมอร์ ไม่ได้มีหน้าที่สอน)
โดย ไม่มองว่า
User ที่ไม่เข้าใจ = ใช้ s/w ได้ไม่เต็มที่
แผนก Help desk (ก็ของตนเอง) ต้องรับผลกระทบ จากแนวคิดข้างต้นมาก
>> แสดงให้เห็นว่า "แนวคิดผู้นำ และ วิธีการที่ดี" จะช่วยแก้ปัญหาได้
Budget
ไม่พูดถึงไม่ได้บริษัทขนาดใหญ่ คนที่จะเสนองบฯ ประมาณ ก็จะรุ้ขั้นตอน/วัฒนธรรมภายในอยู่แล้ว
เช่น มักจะมีขีดจำกัดการลงทุน ด้าน IT (ของบฯ พิเศษ ต้องมีจังหวะที่เหมาะสม)
แสดงข้อมูล ให้ ประธานเข้าใจตรงกันว่า
ทางเลือกที่เสนอ (สภาพ ณ เวลานั้น) เป็นทางเลือกที่ดีที่สุดจริง (บริษัท ได้ประโยชน์จากการลงทุน)
อุปสรรคใหญ่ เพียงอย่างเดียว คือ ไม่เชื่อ!
ไม่มีความคิดเห็น:
แสดงความคิดเห็น