เริ่มกันแล้ว
โครงการที่ใหญ่ และ ซับซ้อน การทำงานจะทำตามแผน ตามลำดับ
ทบทวนจุดยืนของระบบฯ
- เนื่อหา "ครบถ้วน" ตาม "พื้นฐาน" ... ระบบงานปัจจุบันจะดูขาดๆ เกินๆ
บาง table มีจำนวน field มากถึง 700 field ... แค่จำความหมาย ก็ยากแล้ว
- มี ขั้นตอน ที่เข้าใจง่าย ... ระบบงานปัจจุบันจะดู วกวน
ขั้นตอนทางธุรกิจ ที่เป็นที่ยอมรับทั่วไป กับ วิธีการคุ้นเคยในแต่ละองค์กรจะมีความเหมือนและต่างกันพอสมควร
-------------------------------------------------------------------------
"ต้องตัด" ความซับซ้อน สิ่งพิเศษ ที่เกิดจากการพัฒนากันเอง
-------------------------------------------------------------------------
ข้้นตอนทาง IT
- ตรวจ/เก็บกวาด สถานะของ Info ปัจจุบัน
ตัวที่หยุดใช้แล้ว, มีความหมายที่ไม่ตรงกับที่เห็น หรือไม่อย่างไร
- อธิบาย นิยามของ Table ใหม่
- จับคู่ Mapping
- ทำขั้นตอน โอนย้าย โดยทดสอบ
(ความเห็น)
ขั้นตอนดังกล่าว ดูธรรมดา มาก
แต่เมื่อทำงานจริง จะพบ ปัญหาจุกจิก เกิดขึ้นมาก
ให้หาว่า file อะไร น่าจะหยุดใช้งาน ... 1000 file จะตรวจอย่างไร ?
แต่ละ Field ใช้หรือไม่ ?
ต้องได้ความถูกต้อง "สูง"
ถ้าทีมงาน เริ่มรู้สึก "เหนื่อย, ต่อต้าน" ผลลัพธ์ข้างต้นจะออกมาผิดพลาด "สูง"
>> ต้องทำเวลาทำ ข้างต้น "เร็ว" และ "ง่าย"
การปิด "จุดอ่อน" เล็กๆน้อย โดยทำก่อน หรือ พัฒนาระหว่างทำจะช่วยได้มาก
ขั้นตอนทาง Biz
- หลังจาก กำหนดตัวแทนของ User แล้ว
และ บริษัทที่ปรึกษาได้ ศึกษาระบบขั้นต้น
- จะมีการเชิญ User มาคุย
เก็บรายละเอียด เพิ่มเติม มักจะเป็นคำศัพท์เฉพาะ, ขั้นตอนพิเศษ
รวมทั้งถือโอกาส แจ้ง "จุดยืนของระบบฯ"
หลักการแบบ "ย่อ" มักใช้พูดเพื่อความเข้าใจง่ายๆ
เปลี่ยน แล้วจะดี อย่างโน้น อย่างนี้ ...
แต่เมื่อจะลงมือทำ รายละเอียด "ที่ชัดเจน" เป็นสิ่งที่ช่วยผลักดัน คนทำงาน
พร้อมเดินหน้า ฝ่าอุปสรรคต่างๆไป
เป็นการยาก ที่จะบอก User ว่า หลังจากย้ายระบบฯ แล้ว
ขั้นตอนนั้น นี้ จะต้องหยุด หรือ ต้องทำหลายขั้นตอน แทนที่
สิ่งที่ "บอก" ไว้ ยังเป็นตามนั้น ใช่หรือไม่ ?
(ความเห็น)
จุดนี้เป็น "สิ่งสำคัญ" มาก
งานจะสำเร็จ หรือ ล้มเหลว อยู่ที่การ "ยอมรับ" การเปลี่ยนแปลง
User จะรับรู้ว่า จะได้ คุ้มกับ เสีย หรือไม่ ?
นอกจาก ระบบใหม่ ต้องพิสูจน์ตนเองได้ดีแล้ว
Key Man ทุกคน ต้องเลือกคนที่เหมาะสมรอบด้าน
ทั้งความรู้ "เฉพาะงาน" "องค์รวม" รวมทั้ง เทคนิคการจัดการ
สิ่งที่ได้ยินมา
- หน่วยงาน มีการ "สร้าง" ขั้นตอนการทำงาน ที่เหมาะกับ "วัฒนธรรม" การทำงาน
แต่ดูไม่เป็น "มาตฐาน" เช่น การจัดองค์กรแบบรวมศูนย์ ในขณะที่ทางกฏหมายแยกบริษัทกัน
วัฒนธรรม คือ ความไว้เนื้อเชื่อใจ แต่ มาตฐานคือ แยกการจัดการ เป็นต้น
วิธีการตามวัฒนธรรม การรวมกันทำให้เกิดความ รวดเร็ว ใช้คนน้อย โดยผ่านคนที่ไว้เนื้อเชื่อใจได้
ในขณะที่ มาตรฐาน ทำให้แยกขั้นตอนได้ ชัดเจน รองรับการเปลี่ยนกำลังคน
ไม่ว่า วิธีไหน ก็มีจุดเด่นในตัว - การเปลี่ยนต้องระวัง ผลกระทบไว้มาก
