วันเสาร์ที่ 11 กุมภาพันธ์ พ.ศ. 2560

กลับไปที่ Learning by Doing

การเรียนรู้ - คนส่วนใหญ่ พูดตรงกันว่า  Learning by Doing เป็นวิธี  "ที่ดีที่สุด"

เรื่องตลก !

คนส่วนใหญ่ ไม่สนใจในการ  "สอน" หรือ "สร้างคน"
แนวคิดด้านบน  จึงเป็น "ทางลัด" ที่ทเข้าใจกัน "ง่าย"

ความเห็นของผม  

วิธีนี้  เหมาะกับ  สภาพแวดล้อมที่  "มีคนรู้ จำนวนมาก  มีคนใหม่ จำนวนน้อย"
ปัญหา จากคนใหม่  จะมีน้อยมาก และ  คนที่รู้ มาช่วย แก้ปัญหาอย่างรวดเร็ว

  สภาพแวดล้อม  ที่ทุกคน เป็น "คนใหม่" - แนวคิดนี้  ใช้ได้หรือ ?
  ทุกคนจะเห็น  ปัญหา ตอนเริ่ม  ทำงานจริงพร้อมกัน

Note : ใน 20 ปีนี้  ผมสอน,สร้างคน มาหลายรุ่น รวมทั้งทำนอกบริษัทฯ

หลังจากผ่าน การเรียน "จัดให้มีซ้ำๆ" 

- User จะได้เข้า  เรียนหรือฟัง  มากกว่า 2 ครั้ง
- บางคน จะได้เข้า เรียน "มากกว่า" 3 ครั้ง

ผู้เขียนได้เข้าฟัง 3 ครั้ง (ภาพรวม 2 ครั้ง เข้า workshop 1 ครั้ง)

อุปสรรค มีหลากหลาย

- เข้าใช้  "ไม่ได้" (ไม่มี Notebook, ไม่ติดตั้งโปรแกรม,  ถูกจำกัดสิทธิ บางโปรแกรม)
- จำไม่ได้ : ศัพท์ใหม่ มีมาก , หลายขั้นตอน
        หน้าจอ  อักษรขนาดเล็ก , ต้องดูเทียบหลายหน้าจอ (จำไม่ได้)
        ความสามารถ  ในการ  "จำภาพ" (ต่างกัน)
- ช้า : ต้องเสียเวลา สร้างความคุ้นเคย "นาน"
- ต้องเลือก : ฟังอย่างเดียว เข้าใจดี  หรือ ทำตามตลอดเวลา
        สอนเร็ว, ต่อเนื่อง จนไม่มีเวลาคิด

ผลลัพธ์  ก็มีหลากหลาย ครับ

- เข้าใจ  และทำตามทัน   ... 1 ใน 4
- ฟังรู้เรื่อง  แต่ทำไม่ได้    ... 1 ใน 4
        ต้องกลับไปทำภายหลัง - แต่  ไม่มีเวลา,  ทำซ้ำไม่ได้  จำไม่ได้, ไม่มีคู่มือ, ...
- ฟังแล้วไม่ได้อะไร ...  (งานเก่า ไม่ต้องทำ งานใหม่ก็ต้องทำ, ไม่สนใจ, ...)

>> ทีมงานคาดหวัง ว่า หลังเรียน Key Man ต้องทำได้ 100%
      แต่จากข้างต้น  จะเห็นว่า  ได้แค่ 1 ใน 4 เท่านั้น

Q: แล้วต้องพัฒนา กันอย่างไร ?

A: "รอ" สิ่งมหัศจรรย์ ?

ในสภาวะ "คับขัน" มักจะเกิด "สิ่งมหัศจรรย์"
ในกรณีนี้  เกิด  คนที่เสียสละ เริ่มทำ  "สิ่งที่ไม่เคยทำ"  
แน่นอน เหนื่อยมากๆๆๆ + ทำแบบโดดเดี่ยว
ในสภาพนี้ : ผลลัพธ์  ก็แค่ เสมอตัว หรือ ติดลบ  - แต่  ตนเอง ได้เต็มๆ
>> ข่าวดี  มีเกิดขึ้นจริง  น๊ะครับ แต่มีน้อย  ในกลุ่มคนหมู่มาก 

A: ทยอย "ลด" อุปสรรค

ข่าวดี ผู้สอน ยอมรับสภาพที่ต้อง "สอนซ้ำๆ"
(ตอนแรก ผมคิดว่า จะมีแรงต่อต้าน  เนื่องจาก  ทีมงานไม่เก่ง ด้านการสอน)

"ก่อนเข้าเรียน" เตรียมให้พร้อม
- Notebook สำรอง (กรณีที่ไม่มีเครื่อง)
- โปรแกรม ใน Notebook  
- ลงทะเบียน ก่อนเรียน
- คู่มือ ที่กลับมา  ดุซ้ำได้ ภายหลัง!
- ผู้ช่วย ต้องใช้เป็น หรือ รู้วิธีแก้ปัญหา (จะต้องติดต่อใคร)

"ขณะเรียน"
- ผู้สอน มีความเชี่ยวชาญ (จริงๆ ก็ไม่รู้อะไรมาก)
- ผู้ช่วย  แนะนำตามโต๊ะ

"หลังเรียน"
- VDO ที่กลับมา ดูซ้ำได้ ภายหลัง!
- เปิดดู VDO ได้สะดวก

- สรุปปัญหา และ ทางแก้ไข
        เช่น พบว่า  คนเรียนส่วนหนึ่ง  ไม่มี notebook
                         ,คนเรียนส่วนหนึ่ง  เข้าใช้ไม่ได้ (ไม่รู้จะถามใคร)
                         ,คนเรียนส่วนหนึ่ง  ไม่ทำตาม (เร็วไป, ฟังไม่รุ้เรื่อง, ไม่สนใจ)

Q: ได้ทำ เพื่อ "ลดปัญหา" ได้จริง ครบ หรือไม่ ?

Hint - วิธี Change Management , Knowledge Management เป็นแนวทาง ที่ทำให้ได้ตามเป้าหมาย
      แทน "ก็ทำแล้ว" ก็พอแล้ว (แค่ได้เริ่มทำ) - ไม่สนใจ  เป้าหมาย ซะแล้ว

ตย. อุปสรรค เพิ่มเติม ที่ทำให้ "ไม่ได้ตามเป้าหมาย"
- Mail แจ้งแล้ว  ไม่ทำตามกันเอง  (ส่งอะไรที่อ่านไม่รู้เรื่อง, ส่งไปหัวหน้า เท่านั้น, ...)
- คู่มือ มี  "ไม่ครบ" , "ไม่ทันสมัย" , "ไม่ตรงกับที่สอน"
- VDO ทำยาก , ทำแล้ว    ไม่ต้องตั้งชื่อ  ไปหากันเองได่
- หลักการ = ?

(แนวทาง) ความเห็น ส่วนตัว

- ช่วงแรก
       ต้องสร้างความ "คุ้นเคย" กับ Application - กด/ใช้ ได้เร็ว
            สร้างโจทย์ง่ายๆ และ ให้ฝึกทำ  เช่น  ให้ "ลอง"  เรียกใช้ report
       พร้อมทั้ง แทรก "ศัพท์ใหม่" - พูดซ้ำหลายครั้ง จน คนฟังชิน
           ศัพท์ จะช่วยลด  การอธิบาย ยาวๆ
           การจำศัพท์ใหม่ ใช้เทคนิค พูดซ้ำ เหมือน รายการ TV Direct
           "ศัพท์ใหม่" จะถูกผูกเป็นเรื่องราว "ในหลักการ MRP" (ทุกคน ต้องปรับให้ คิดเหมือนกัน)

       Hint   การใช้ตัว  "ค้นหา"
                 สร้าง Favorite

- หลักการ -> ขั้นตอน
       ขั้นตอน ทำตาม "หลักการ"
        - แก้ปัญหา จาก "ความเข้าใจ" แทนการ "ท่องจำ"
       - เลือกกลยุทธ์ Make to Stock - Sale Order จะไม่ถูกนำมาวางแผน (อย่า นำมาปน)
       - การ auto ตามลำดับ  1-2-3

       Hint  ทำแบบที่ "คุ้นเคย" (สั้นที่สุด) ให้ได้ก่อน
                 แล้วเริ่ม  เปลี่ยน  เป็นกรณีต่างๆ  (มักจะพบในงานจริง  20-30%)
                 แก้ปัญหา โดย "หลักการ"


วันอาทิตย์ที่ 23 ตุลาคม พ.ศ. 2559

เมื่อบริษัทฯ แม่ เริ่มขยับ-2 Web Performa

เมื่อบริษัทฯ แม่ เริ่มขยับ-2

ทบทวน
หลังจาก ประกาศ
"เราจะย้าย  Legacy จาก RPG ไปใช้ SAP"  เพื่อ ...

SAP มีรายละเอียด "มาก"
รู้ทิศทางแล้ว  แต่  ขาดรายละเอียด (รอประกาศ ตามมา)

ช่วงแรก จะได้ยิน "ความฝัน"  แทรกมาด้วย (ทำได้ยาก)
เช่น จะทำ BI (Business Intelligence)  สร้าง รายงานผู้บริหาร  เป็นต้น


เมื่อเวลา ผ่านไป  รายละเอียด  ต่างๆ ก็จะชัดเจนขึ้น เช่น
  # SAP จะเน้นทำ  เรื่องนี้ ... (ชัดขึ้น)
     เรื่องอื่นๆ  นอกนั้น  "ไม่ทำ"  "ทำได้  แต่ไม่ดี"
  # BI  กำลัง วางแผนกันอยู่ ยังจะไม่มีให้ใช้ ในช่วงเวลานี้
     ต้องกลับไป  นำรายงานในระบบ "เก่า"  กลับมาใช้
  # หลายงาน  ต้องการ  "KeyMan" และ ทำงานในสไตล์ใหม่
     KeyMan ที่ทำงานแบบเดิม   ก็มีแนวโน้มว่า ผลลัพธ์ จะได้  ไม่ถึงเป้า
  # ...


# ผมคิดว่า    ใครที่จะทำ  ต้องสร้าง "KeyMan"  หลายคน
                     มีความรู้ความเข้าใจ  "ดีมาก" ทั้งเทคนิค และ วัฒนธรรมการทำงาน
                     รวมทั้ง  คล่องตัวสูง  พร้อมรับ  "การเปลี่ยนแปลง"  
           พูดง่าย แต่ทำยาก  ต้องดึงผู้เชี่ยวชาญ หรือใช้เวลา "สร้างคน"


กลับเข้าเรื่อง

ช่วงเวลานี้   ผมได้รับการสื่อสาร ในลักษณะนี้
กว่าจะสรุปได้  ก็เสียเวลาไป  หลาย ชม.
จนถึงตอนนี้ ก็ยังไม่แน่ใจว่า สรุปได้ถูกต้องหรือไม่ ?
      การฟังคน  บอกความฝัน  ให้คิดตาม   แล้วพูด "ดัก" (ตีกรอบ) ไว้ด้วย
      ทำให้รู้สึกเหมือน  ว่า  "ถูกสั่งให้ทำตาม  และ  ทำในกรอบที่กำหนด"  (ห้าม! ทำเกิน)

# ผมคิดว่า   
        ถ้า  เรียง  ลำดับ  ความคิดให้ดี จะใช้เวลา "สั้น"
        แนวคิด  ที่คิดไปพูดไป   สด  น่าจะเหมาะกับ คุยกันเรื่อยๆ  มากกว่า

ผมสรุปได้ประมาณนี้

Vision    "Bye Bye RPG"
Mission  เลือกใช้  Tool  แทน  เลือกใช้ Web Performa (S/W จาก Cannon)
Task        ที่ไทย   จัดซื้อ License ให้ใช้ทดลองใช้  "บางส่วน"
                             จะจัดให้ ผู้สอน ภายในจากญีปุ่น  มาสอนในไทย (ต้องรอ 2 เดือน)
                             ให้กำหนด  ชื่อ คนเรียน และ ให้ตั้งโครงการ จะทำอะไร
                             แจ้งว่า คนเรียน จะต้องถูก "ทดสอบ" ด้วย

                โดย ผู้นำ ลงมา "ติดตาม" เอง!
                ประวัติศาสตร์  ผู้นำ  ลงมา  "ติดตาม" เอง   งานจะเดินได้  "เร็วมาก" และ "สำเร็จ"  ชัวร์
 
คุณว่า Vision,Mission,Task ข้างต้น  ใช้เวลา "นานแค่ไหน" 10 นาทีหรือ 2 ชม.
- เวลา ส่วนใหญ่ ที่เสียไป คือ  ท้าวความ โน้มน้าว
       อนาคตของ RPG, เทคโนฯ, ... บลาๆๆ
       ผมเข้าใจว่า  เขาไม่อยากให้  ประวัตศาสตร์ "ซ้ำรอย" ที่ญี่ปุ่น  ใช้เวลา "นานมาก" และ ทีมงานส่วนใหญ่  ก็ยัง ทำไม่ได้   ที่เห็นผล  คือ ทีมงาน ส่วนน้อย ที่เป็น  คนรุ่นกลาง, รุ่นใหม่

ข้อมูลนี้   ผมมองว่า  เขาสื่อให้เห็น  สิ่งที่เขา  ได้ทำไปแล้ว
ที่ญี่ปุ่น   ซื้อ License,  ส่งไปเรียน,   สร้าง ผู้สอน ภายใน
              ให้โอกาส ทีมงาน RPG ปัจจุบัน  สร้างงานก่อน
              ถ้าไม่สามารถ  ก็ให้อีกทีม  ช่วยทำบางส่วน
              ... ผ่านไป 4 ปี  (นานไปมั๊ย 555)
Milestone      มีการสร้าง Web Site กลุ่มงาน   แสดงให้เห็น
                      - ใช้เวลาสร้าง  เร็วกว่า RPG 3-4 เท่า  สวยงามกว่า ยืดหยุ่นกว่า
                      - มีการสรุป Template ให้ เพื่อให้กลุ่มถัดไป  ทำงานได้เร็วขึ้น

กรอบการทำงาน  ที่ฟังมากๆ แล้ว ไม่รู่้จะต้องทำอะไร

- อยากให้  "คิด"  ลดปัญหาจากการใช้ RPG ที่สะสมมา ... "คิด" ในกรอบน๊ะ
- หยุด RPG -> iSeries -> DB2/400 (มันเรื่องเดียวกัน) ... แล้ว DB ให้ใช้อะไร ?
          (เลือกใช้ NoSQL ได้มั๊ย 555)
- Template ทางญี่ปุ่น  สรุปให้แล้ว ... ไทย ไม่ต้องเสียเวลา "คิด" (แค่นำไปใช้)
- ไม่สร้าง ระบบงานที่ซ้ำกับ  ทางญี่ปุ่น ทำไว้แล้ว ... ต้องเป็นระบบเฉพาะ ของประเทศนั้นๆ
- ถ้าคิด  งานไม่ออก  ให้นำงาน RPG กลับมาทำใหม่  ได้
- ทำได้ทุกอย่าง  (รายงาน, บันทึก, ...)
- Web Performa เป็น S/W เฉพาะของ Cannon Japan ... หาความรู้จาก internet แทบไม่ได้เลย
- S/W นี้สามารถเขียน code Java เป็น Core Business ได้  แต่...ถ้าเขียน จะทำให้ส่วนออกแบบ GUI ใช้ไม่ได้  (คล้ายกับ Dream Weaver หรือ Tool อื่นๆ)

ในหัวของผม ตอนนั้น  คือ
      ให้ใช้ Dream Weaver ที่ทำได้เฉพาะ  งานเฉพาะ  เท่านั้น
      เหมาะกับ  ทีมงาน RPG ที่   ไม่มีตัวเลือก หรือ หมดทางไป
      แต่ทีมงาน  ที่มีทางไป  กำลังถูก  "ปิดทาง"

เข้าใจตรงกัน ว่า  ถ้ามองเป็น "การบริหารจัดการ"  แบบ Centralize ก็ถูกต้องแล้ว

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

แน่นอนว่า  สภาพแวดล้อม ต่างกัน  แนวคิดนี้อาจจะสำเร็จก็ได้
แต่ผมว่า  ดูจาก KeyMan และ ขั้นตอนต่างๆ แล้ว เทียบกับ  การเปลี่ยนแปลงภายนอก
   เท่ากับว่า  เกือบจะเหมือน ในอดีต  ทุกประการ

ถ้าจะทำให้ได้  ต้องพร้อม  มากกว่านี้ ...

วันศุกร์ที่ 15 เมษายน พ.ศ. 2559

มุมมองหลัง Migration

มุมมองหลัง Migration

ในที่สุด  วันสุดท้ายของ Migration ก็มาถึง   (หลังจากเลื่อนไป 1 ครั้ง)
ภาพสรุปในความเห็นของผม  ก็คือ  "ผ่าน" ครับ

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

เนื่องจาก บริษัทฯต้องทำ Migration กับแผนกฯที่เหลือ อีก 2-3 รอบ
ต้องทำโดยไม่มี Vendor ช่วย      ดังนั้นการพัฒนาวิธี  เป็นสิ่งที่ควรทำ

วิเคราะห์ในสไตล์ของผม จะมีแนะนำแนวทางไว้ด้วย  (ไม่ใช่  ติ  อย่างเดียว)

สรุป

* มุมมองเกี่ยวกับ "คน"

  - Vendor เป็นมืออาชีพ  มีรูปแบบและ Step การทำงาน (1-2-3)
          เนื่องจาก การจ้างนับเป็น "วัน" ดังนั้น  ตารางเวลาจะ "แน่น"/"เร่ง" มาก

  - Leader  เป็นคนญี่ปุ่นทั้งหมด  
    ได้  "Training" = ลดแรงต้านจากการทำงานแบบไม่รู้เรื่อง - แน่นอนว่า  "ราคาแพง"
    มีจำนวนมากกว่า ผู้ตาม
    เป็นระดับอาวุโส เกือบทั้งหมด

    ส่วนใหญ่ที่เก่ง  จะเป็นแบบทำงาน  "คนเดียว"
    ได้เห็น การทำงานเป็น  "ทีม" น้อยมาก 
           ยังคงมีระบบอาวุโส = ฉันเป็นลูกน้อง แต่ฉันอาวุโสสูงกว่า ฉันไม่ทำที่สั่งก็ได้

  - ผู้ตาม เป็น  คนไทย  
     ไม่มีนโยบาย ส่งคนไทยไปเรียน - แป่ว
     ให้เรียนแบบ  Learning by Doing - ทำมากๆ ก็รู้เองแหล่ะ
     มีส่งไปเรียน  2 คน    คนเรียน บอกว่า ให้ไปนั่งที่บริษัท Vendor แล้วทำตามเอกสาร
     (เรียกว่า  เรียนได้เต็มปาก  มั๊ยเนี่ยะ)

  - User
        แต่ละแผนกฯ ต้องส่ง KeyMan มา ประชุม  แต่ ...
        ส่วนใหญ่ ไม่เคยมี "KeyMan" ในแผนกตั้งแต่แรก
                         ส่ง  คนทำงานที่ทำประจำ  แต่ตัดสินใจไม่ได้มา
                หรือ  ส่งหัวหน้าที่ไม่เคยใช้ IT เลย
                หรือ  ส่งมาทั้ง 2 คน  กว่าจะลงตัวได้  เทียบกับ ตารางเวลา "เลยไปไกลแล้ว" --- แป่ว

การให้ความรู้  กับ  ทุกคน  เป็นเรื่องพื้นฐานสำคัญ
การทำส่วนนี้ ไม่ครบ ทำให้ปัญหาต่างๆ เกิดขึ้นตามมามาก
บริษัทฯ ที่มีการเปลี่ยนแปลงใหญ่ แล้วมีผลกระทบน้อย - จะมีขั้นตอนให้ความรู้อยู่แผนการทำงานด้วย    
>> ความเห็น - ถ้าเป็น  การทำงานสไตล์ญี่ปุ่น 100%  แนวทางข้างต้นถือว่า  "ลงตัว"  (สั่งการ - ทำตาม)
        แต่เมื่อนำมาใช้กับงานลูกผสม(ไทย/ญี่ปุ่น)
        จะเห็นว่า  คนที่เกี่ยวข้อง  จะเกิดความรู้สึก  บริษัทฯให้ความสำคัญกับ "บางกลุ่ม"
        คนที่เหลือ  จะเหนื่อยทำ ทำไม - เป็นคนดี ที่อดทนต่อไป ?
            (แนวทาง เริ่มสร้าง  ระเบิดเวลา  หรือ  สะสมความคลางแคลงใจ เพิ่มขึ้นเรื่อยๆ)

      ทำงานสไตล์ฝรั่ง  ระดับ Leader ที่ผมเข้าใจ  คือ คุยกันแบบสร้างสรรค์,ทำทุกอย่างได้ด้วยตนเอง,กล้าเปลี่ยน  ต่างกับ  คนไทยที่เห็นหลายเรื่อง  คุยกันไร้สาระ, ทำอะไรต้องมีคนช่วย (เต็มไปหมด),ชอบทำแบบเดิมๆ   จะเห็นว่า  รูปแบบ  "ต่างกัน" เลย

>> ความเห็น - การเตรียม "คนให้พร้อม"  ก็เป็นหน้าที่  หนึ่ง  ที่ต้องทำ

* มุมมองเกี่ยวกับ  "วิธี"

    Vendor ทำงานแบบยุโรป  มาเจอะ User แบบไทย/ญี่ปุ่น  
    งานนี้ Vendor น่าจะ "เสียกระบวน" ไปพอสมควร

    วิธีแบบยุโรป - ต้องเขียน/อ่าน รายงาน, ทุกคน "รู้หน้าที่" ของตนเอง (ต้องทำอะไร)
          ดูเป็นวิธีที่   "มาตรฐานดี"
    วิธีแบบคนไทย - ไม่ชอบเขียน/อ่าน   ทำไปเรื่อยๆ  นึกอะไรออกก็ทำไป
          เหมาะกับทำงานคนเดียว
    วิธีแบบญี่ปุ่น - ทำตามคำสั่งอย่างเคร่งครัด  ระบบอาวุโส
          เหมาะกับ  มีผู้นำ คนเดียวที่เก่งมาก

ตย. ปัญหาเล็กน้อย สะสม
- Task List หลายคน  ดูไม่เป็น
   >> การอธิบาย ซ้ำๆ บ่อยๆ จะช่วยได้มาก
- เอกสารมีหลายเวอร์ชั่น, จำนวนมาก + แผนงานมีการเปลี่ยนเร็ว ทำให้เอกสารบางชุดสร้างไม่ทัน  
  = เพิ่มความยุ่งยากใน  คนที่กำลังปรับตัว
   >> ต้องมีเครื่องมือ มาช่วย จัดการ
- Leader หลายคน สั่งงาน  ไม่เหมือนกัน ซ้าย/ขวา
  ผู้ตาม  รับคำสั่ง 2 ทาง   จึงไม่รู้ว่า ต้องไปทิศทางไหน ?
  >> มีคนมาตรวจมั๊ยว่า  ตัว Leader มีปัญหา
- พูดปนกัน ไปมา  ปัญหาใหญ่/เล็ก
  อะไรสนุกปาก  ก็คุยกันจนเป็น เรื่องสำคัญได้
  >> ต้อง "ลดจำนวน" ปัญหาเล็ก ด้วยความเข้าใจ

ตย. การปรับตัว ที่ได้เห็น
- การคุยกับ User เป็นหน้าที่ของ  Vendor ที่ต้องสื่อสาร  (นัดประชุม, อธิบาย และ สรุป)
  >> Vendor เริ่มปรับตัว  ให้เห็น - โดยคุยมากขึ้น, ตั้งคำถามที่เข้าใจง่าย
  >> เปลี่ยนจาก "ภาษาอังกฤษ" เป็นคุยด้วย  "ภาษาไทย"

วันอาทิตย์ที่ 28 กุมภาพันธ์ พ.ศ. 2559

ระหว่างดำเนินการ

สำหรับ  คนไทย ส่วนใหญ่
การทำงาน  ตามแผน  ตามตารางเวลา  เป็นเรื่องที่  ไม่ถนัด
เราคุ้นเคยกับ  อะไร ง่ายๆ   ให้ทำอะไรก็ว่ามา  รีบทำจบๆไป   555

ทีมงานที่ติดตั้ง  (บริษัท ตัวแทน จาก SAP)
# แจ้ง ตารางเวลา  และให้ทุกคนปฏิบัติตาม
   - ในความเป็นจริง  มีคนที่เกี่ยวข้องมาก  ดังนั้นตารางเวลานี้  จึงเปลี่ยนได้เรื่อยๆ
# ทำ คู่มือ ประกอบการใช้งาน  ให้อ่านก่อน
# อธิบาย การใช้งาน และ ยืนยัน ว่า สามารถทำงานแทนได้
# อธิบาย การใช้งาน

เราต้องทำ  "ขั้นตอนตามลำดับ"
ขั้นตอน ดู "ครบถ้วน"

ตัวละคร ก็ทำตามบทของตนเอง
- Key Man ต้อง ปรับให้มี "ความรู้" ,"Life Style"  ที่ควรจะเป็น (ดูจาก คนที่มีคุณภาพ)
        รู้จริง     ถ้าไม่รู้  ก็เรียนรู้  เพิ่มเติม  ...  ก่อน/ทำพร้อมๆกัน
        Life Style    ที่สนับสนุน  "งานหลัก"  ... ต้องทำก็ทำ  ต้องให้เวลาก็ให้เวลา

- ทีมสนับสนุน  จะ  "ลด" ระดับความเข้มลงมา อาจจะลงมาที่ 50-70 %
- User   จะเน้น  สนใจเฉพาะ  งานที่ตนเองทำ
- ทีมผู้นำ  มีหน้าที่หนักกว่า  Key Man
       เพราะ ต้องสร้าง  Key Man และ ทีมสนับสนุน  เพิ่มขึ้นเรื่อยๆ
       การสร้าง "คน" ถ้าจะให้ได้ผล  ต้อง "ตั้งใจ" มาก

ส่วนที่ชอบ
- รูปแบบ คู่มือ  มีหลากหลาย  เอกสาร, มี demo (VDO), มี Practice
- มีการปรับ รูปแบบ/วิธีการ ที่รวดเร็ว

ส่วนที่ไม่ชอบ
- เอกสาร  มีมาก update กันบ่อยมาก   จนจัดการยาก (หาไม่พบ, อันไหน)

"ระหว่างดำเนินการ"

ดูเหมือน ตัวละคร จะผ่านเกณฑ์ได้  ไม่กี่คน
หลายคน  กลับไปใช้วิธี  "ดั้งเดิม" คือ   รอทำจริง  แล้วก็ค่อยดูผลกัน
     ผมเรียกว่า ซื้อเวลา่  และ  วัดดวง

อดีตเคยคิดว่า เสี่ยงสุดๆ
       ผมไม่ชอบ เสี่ยงกับ ผลที่ไม่ชัด ทั้งที่เรา  "กำหนดอนาคตได้"

แต่จากประสพการณ์  พบว่า "บางครั้ง"  จะเกิดสิ่งมหัศจรรย์เกิดขึ้น
      เช่น  มีทางเลือกใหม่ ที่ไม่ควรมีเพิ่มขึ้นมา  ,มี Hero แสดงตนออกมา  เป็นต้น
      สิ่งนี้  อาจทำให้  หลายคน  เลือก  "รอ"  แทนการ  ตั้งใจทำ(เปลี่ยน)

เอาละ แล้วสิ่งที่ผม  ต้องพยายามทำล่ะ  คือ
- ทำให้ คุ้นเคย ได้มากที่สุด - อ่านคู่มือ ให้มากที่สุด
- ต้องพยายาม  เข้าใจ  (ชนิด สอนต่อได้) -
- ทำให้  การเข้าใช้งาน  เป็นไปได้อย่างง่าย และ ราบรื่น
       (รู้กันว่า งาน IT ที่ control  จะเข้าใช้ยุ่งยากมาก)

ต้องมีวิน้ย - แบ่ง/เตรียม  เวลา ให้กับการเรียนรู้
เรียนรู้  - จนคล่อง (ไม่ใช่แค่  ได้เรียน  แล้วก็ตอบว่า  ไม่ได้อะไร)
ปรับ  คู่มือให้เหมาะ - ตอนนี้ชอบวิธี Single Page, InfoGraphic  คนอ่าน จะรู้สึกง่ายดี

เมื่อ Time Line เริ่มขยับผ่านไป   หลายสิ่ง ที่บางคนพูดอย่างแปลกใจ
      "อ๊ะ ทำไม เป็นอย่างนี้" "ไม่นึกว่าจะเป็นอย่างนั้น" ...
แต่ส่วนใหญ่  ยังอยู่ในแนวทางที่ "เคย" ประเมิน (พูด) ไว้
       ยืนยันว่า อนาคตหลายเรื่อง เรา ่ "ควบคุม"  ให้มัน   ดีขึ้น  ได้

วันอาทิตย์ที่ 26 เมษายน พ.ศ. 2558

เริ่มกันแล้ว...

เริ่มกันแล้ว

โครงการที่ใหญ่ และ ซับซ้อน  การทำงานจะทำตามแผน   ตามลำดับ

ทบทวนจุดยืนของระบบฯ
- เนื่อหา   "ครบถ้วน" ตาม "พื้นฐาน"  ... ระบบงานปัจจุบันจะดูขาดๆ เกินๆ
      บาง table มีจำนวน field มากถึง 700 field ... แค่จำความหมาย ก็ยากแล้ว
- มี ขั้นตอน  ที่เข้าใจง่าย  ... ระบบงานปัจจุบันจะดู วกวน
      ขั้นตอนทางธุรกิจ ที่เป็นที่ยอมรับทั่วไป   กับ   วิธีการคุ้นเคยในแต่ละองค์กรจะมีความเหมือนและต่างกันพอสมควร
-------------------------------------------------------------------------
"ต้องตัด" ความซับซ้อน สิ่งพิเศษ ที่เกิดจากการพัฒนากันเอง
-------------------------------------------------------------------------
ข้้นตอนทาง IT
- ตรวจ/เก็บกวาด  สถานะของ Info ปัจจุบัน
       ตัวที่หยุดใช้แล้ว, มีความหมายที่ไม่ตรงกับที่เห็น หรือไม่อย่างไร
- อธิบาย  นิยามของ Table ใหม่
- จับคู่ Mapping
- ทำขั้นตอน  โอนย้าย   โดยทดสอบ

(ความเห็น)
ขั้นตอนดังกล่าว  ดูธรรมดา มาก
แต่เมื่อทำงานจริง จะพบ  ปัญหาจุกจิก  เกิดขึ้นมาก  

        ให้หาว่า  file อะไร  น่าจะหยุดใช้งาน   ... 1000 file จะตรวจอย่างไร ?
         แต่ละ Field ใช้หรือไม่ ?

ต้องได้ความถูกต้อง  "สูง"
ถ้าทีมงาน  เริ่มรู้สึก  "เหนื่อย, ต่อต้าน" ผลลัพธ์ข้างต้นจะออกมาผิดพลาด "สูง"
>> ต้องทำเวลาทำ  ข้างต้น   "เร็ว" และ "ง่าย"
การปิด  "จุดอ่อน"  เล็กๆน้อย   โดยทำก่อน หรือ พัฒนาระหว่างทำจะช่วยได้มาก

ขั้นตอนทาง Biz
- หลังจาก กำหนดตัวแทนของ User แล้ว
  และ บริษัทที่ปรึกษาได้ ศึกษาระบบขั้นต้น
- จะมีการเชิญ  User  มาคุย
     เก็บรายละเอียด  เพิ่มเติม   มักจะเป็นคำศัพท์เฉพาะ, ขั้นตอนพิเศษ
     รวมทั้งถือโอกาส  แจ้ง  "จุดยืนของระบบฯ"

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

เป็นการยาก ที่จะบอก User  ว่า  หลังจากย้ายระบบฯ แล้ว
ขั้นตอนนั้น นี้ จะต้องหยุด หรือ ต้องทำหลายขั้นตอน แทนที่
     สิ่งที่  "บอก" ไว้  ยังเป็นตามนั้น ใช่หรือไม่ ?
 
(ความเห็น)
จุดนี้เป็น  "สิ่งสำคัญ" มาก
งานจะสำเร็จ หรือ ล้มเหลว  อยู่ที่การ "ยอมรับ"  การเปลี่ยนแปลง
      User จะรับรู้ว่า  จะได้  คุ้มกับ เสีย หรือไม่ ?
นอกจาก ระบบใหม่ ต้องพิสูจน์ตนเองได้ดีแล้ว
     Key Man ทุกคน ต้องเลือกคนที่เหมาะสมรอบด้าน
     ทั้งความรู้ "เฉพาะงาน"   "องค์รวม"   รวมทั้ง  เทคนิคการจัดการ

สิ่งที่ได้ยินมา
- หน่วยงาน มีการ  "สร้าง" ขั้นตอนการทำงาน ที่เหมาะกับ "วัฒนธรรม" การทำงาน
  แต่ดูไม่เป็น "มาตฐาน" เช่น   การจัดองค์กรแบบรวมศูนย์  ในขณะที่ทางกฏหมายแยกบริษัทกัน
วัฒนธรรม คือ ความไว้เนื้อเชื่อใจ   แต่ มาตฐานคือ แยกการจัดการ  เป็นต้น

วิธีการตามวัฒนธรรม การรวมกันทำให้เกิดความ รวดเร็ว ใช้คนน้อย  โดยผ่านคนที่ไว้เนื้อเชื่อใจได้
ในขณะที่ มาตรฐาน ทำให้แยกขั้นตอนได้ ชัดเจน  รองรับการเปลี่ยนกำลังคน
ไม่ว่า วิธีไหน ก็มีจุดเด่นในตัว - การเปลี่ยนต้องระวัง  ผลกระทบไว้มาก

วันศุกร์ที่ 25 กรกฎาคม พ.ศ. 2557

ร้องเพลง รอ

ร้องเพลงรอ

(Share ข้อเท็จจริง และ ความเห็นน๊ะครับ)
จนถึงวันนี้    ความคืบหน้าของการ "โอนย้าย" ไป SAP ยังคง  "รอ"

จากเรื่องที่  "เงียบ" (ไม่มีใครกล่าพูดอะไร)
เริ่มมี ข้อมูล ออกมา ... บางส่วน  หลายๆคน เริ่มคาดเดาได้แล้ว (จากประวัติศาสตร์)

ประโยคสั้นๆ "แค่ซื้อ SAP มาใช้  บริษัทฯ ก็จะแก้ปัญหาต่างๆได้ + พัฒนาขึ้นมาก"
>> ใช้กระตุ้น คนที่  ไม่รู้เรื่องและขี้เกี่ยจฟังรายละเอียด  ได้ดี

บริษัทฯที่ปรึกษาที่จ้างมาส่งรายงาน  +  feed back จากหน่วยงานที่เป็น "ต้นแบบ"  รวมทั้งคำแนะนำ "ปากต่อปาก" จากคนที่เกี่ยวข้อง    เริ่ม  "ชัดเจน"  ว่า  "ไม่ง่าย"  ตามประโยคสั้นๆนั้น

ผู้บริหารสูงสุด - ขอให้ทีมงานกลับไปหาข้อมูลเพิ่มเติม (ซ้ำ 2-3 ครั้งแล้ว)
A. หน่วยงานที่เคยซื้อ SAP มาใช้    
        ซื้อมาใช้แล้ว  "ดีจริง" หรือ "กลัวเสียหน้า แล้วบอกว่า  ดี คุ้มมาก"
        แนวโน้ม คำตอบที่ออกมา  คือ  SAP ที่ซื้อมาใช้ไม่คุ้ม   
B. บริษัทฯ ภายนอกอื่นๆ  ที่คล้ายกัน  ประสพความสำเร็จ  "ได้อย่างไร"
       บริษัทที่แนะนำการติดตั้ง SAP จะอธิบายไว้ในขั้นตอน  หน้าที่ของเรา คือ ถ้าดีต้องทำให้ได้  มากกว่า "ฉันพอใจ สิ่งที่มี  อย่ามาเปลี่ยนฉัน"

อุปสรรครายทาง
- ถ้าผู้รายงาน  เน้น  เฉพาะ  รายงาน A  เท่านั้น
- ถ้าคนฟังรายงาน  ไม่อยากยุ่งกับ  วัฒนธรรม "รักษาสภาพ"
- ถ้าทุกคนที่เกี่ยวข้อง ส่วนใหญ่  ไม่อยากเปลี่ยน  (มองเป็นเสียงส่วนใหญ่)
    ... โครงการนี้ "ต้องเลือนอย่างแน่นอน"

แนวทางที่รู้กัน แต่ไม่ทำกัน

จะทำ (พัฒนา) ได้ง่าย  เมื่อ  ทุกอย่างมี "ความพร้อม"  สูง
(มองแบบ TQM: เงิน,คน,เครื่องมือ,วิธีการ)

สิ่งแรก  คือ  Key Man ต้องมี "ความรู้ ความเข้าใจ"
    ใน (เรื่องใหม่) จริง, เรื่องเดียวกัน, มีรายละเอียดชัดเจน
    Q: Key Man = ?   ถูกคน ถูกงานหรือไม่ ?
         ประกาศให้ทุกคนเป็น Key Man ... 555
         พนักงานใหม่ เป็น Key Man ... ว๊าว
    Q: ทำให้ Key Man "รู้ และ เข้าใจ" แค่ไหน ?
         ไปคิดกันเอง
         แจ้งให้ทราบทุก 3 เดือน (เปลี่ยนรูปแบบ  ทุกเดือน)

ขำไม่ออก 1
   เพื่อให้เกิด  "ความรู้ ความเข้าใจ"  -> ส่งไป เรียน,สัมนา,ดูงาน,...
   ลองทายซิครับว่า  ใช้เวลานานแค่ไหน และ ได้ผลลัพธ์อย่างไร ?
          หลายคนคงเคยได้ยินว่า ไปทัวร์ดูงาน  กันบ่อย แต่ไม่ค่อยได้อะไรกลับมา  เห็นได้จากทั้งหน่วยงานรัฐ,เอกชน รวมไปถึงสถาบันศึกษา น๊ะครับ
          ผมเห็นด้วย กับ  "เน้น" ความรู้  แล้วสนุก   แต่ไม่เห็นด้วยกับ  "เน้น" ่สนุกแล้วได้ความรู้  (สัดส่วนมันกลับกันมาก)

          ธรรมเนียมปฏิบัติทั่วไป    ก่อนไป พูดหัวข้อ "เที่ยว" มากกว่าเนื่อหาซะอีก,  ไปเห็นก่อนแล้วจึงคิดคำถาม(มักคิดไม่ออก),   กลับมา ไม่ต้องสรุป เพราะทุกคนไปด้วยกัน
          ผมสนับสนุนให้  "ตั้งใจทำ" ตามเป้าหมาย  ก่อนไป:คิด/เตรียม, เมื่อไป(ได้คำตอบที่ต้องการ), หลังกลับมา(ต้องคุยสรุป)

          เรียงลำดับใหม่ ?  Key Man = ใคร ?  (ส่วนใหญ่ที่ไปดูงาน = Key Man หรือไม่?)
          แก้ที่ต้นเหตุ -> ตัดปัญหา ย่อย/ต่อเนื่อง  ไปได้มากครับ

จากนั้น Key Man จะ "สื่อสาร"  ตามกลุ่มเป้าหมาย
เช่น   ทีมงานหลัก, ทีมงานสนับสนุน, คนทั่วไป  
         ใคร,ต้องทำอะไร,ที่ไหน,เมื่อไหร่    อธิบายในเวลาที่เหมาะ  (ไม่จำเป็นต้องอธิบาย งานของ ผู้บริหารให้  คนทั่วไปฟังอย่างละเอียด  เป็นต้น)

Key Man  รวบรวม  "ปัญหา" จัดกลุ่ม -> หาต้นเหตุของปัญหา (ในทุกด้าน)
    -> กำหนดวิธีการแก้ปัญหา (ทำหลายวิธีพร้อมกันได้)

    TQM นิยมใช้  "ผังก้างปลา"  รวบรวมและแสดงให้ทุกคนเห็น (ไม่ใช่  คิดในใจ)

ตย. รายการด้านล่างเป็น  สรุปที่ต้องทำ

ด้านคน
       ผู้บริหาร  ต้องแสดง  ทิศทางที่จะไปให้ชัด  ...  (ประกาศ, ติดตามแผนต่อเนื่อง)
       ผู้นำ         งานระดับนี้  ต้องมี key man หลายคน ... (เลือก คน, สนับสนุน คนกลุ่มนี้ ให้เดินหน้า)
       ทีมงาน    หลัก (ุลุยเต็มที่) กับ ส่วนสนับสนุน  ... (
ด้านเครื่องมือ
       พัฒนา หรือ มีเครื่องมือ  ดี,ใหม่  อะไรที่ช่วย  "ลดเวลา", "ความยุ่งยาก ...
                   (ดูงาน, เรียนรู้, จัดซื้อ)
       พัฒนา เครื่องมือ ใกล้ต้ว
       [ ]  ระดมสมองด้วย Mind Map
       [ ]  แสดง งานในโครงการ  ด้วย Gannt Project, Project management
       [ ] เรียกดูผ่าน  แฟ้มกระดาษ, Share Folder, Web Portal
       [ ] ติดตามผลด้วย KPI, Digital Board
       [ ] บันทึกช่วยจำ ด้วย To Do List
       [ ] นัดประชุมได้เร็ว ด้วย Share Calendar
       [ ] เตือน ด้วย eMail
ด้านวิธีจัดการ
       การสื่อสาร  ที่มีประสิทธิภาพ  ชัดเจน,ใช้เวลาเหมาะสม
                บางบริษัทฯ เน้น Key Man ต้องไปอบรมวิธีการสื่อสาร กันก่อน

       "ค่อยเป็นค่อยไป"  กรณีที่  ยอมรับแต่ต้องใช้เวลา  (แผนงานใหญ่  มักจะให้เวลาจุดนี้มากพอ)
       [ ] ทำ Change Management

       "เผด็จการ"  กรณีคนที่ไม่ยอมรับการเปลี่ยน และต่อต้าน
               ทำเพื่อเป้าหมายองค์กร   ต่างกับ  ล้างแค้นส่วนบุคคล
               คนที่ต่อต้าน และ ดึงให้คนอื่นๆ ร่วมต่อต้านด้วย  เป็นกลุ่มที่ต้อง "จัดการก่อน"
               (เรื่องนี้ต้อง ทำอย่างรอบคอบ - ฝ่ายต่อต้าน ก็ใหญ่ไม่แพ้กัน   เห็นตย. ดังๆมาหลายเรื่องแล้วน๊ะครับ ระดับรัฐบาล. รัฐวิสาหกิจ, แผนกอื่นๆ)
       [ ] เชือดไก่ ให้ลิงดู

ขำไม่ออก 2
คุยเรื่องลักษณะนี้ทีไร  ทุกคนก็บอกว่า  "รู้อยู่แล้ว"(เถียงกันทีละจุด) และก็บอกว่า  "ไม่ทำ", "ทำไม่ได้", "ทำได้แค่บางส่วน"  (เน้น ความรู้สึก  ขาด รายละเอียด)
     "3 เดือน ผ่านไป ผมพยายามทำอันนี้แล้ว  ไม่สำเร็จ" ... Q: คุณได้  ทำอะไรไปบ้าง ?
     (บางคน อาจจะทำ 5 วันก็เสร็จแล้ว
                   ถ้าติดปัญหา ขั้นตอนนี้ ก็ share ให้คนอื่นทราบ เพื่อจะช่วยกันคิด)

>> ตย ข้างต้น บอกให้รุ้ว่า  "วิธีการ" เป็นสไตล์ "ตนเอง"
     พูดวกไป วนมา หาทางแก้ไขไม่ได้
     "วิธีการ" สื่อสาร   "ลำดับการคิดของ TQM"  ทำให้ "ทุกคน" เข้าใจได้
>> น่าจะเรียนรู้  TQM หรือ อะไรที่ทันสมัย  (หนึ่งในเรื่องที่ MBA ต้องรู้)

ถ้าเข้าใจ แล้วแต่  "ไม่ทำ" (คนที่ทำไม่เดือดร้อน ที่จะพัฒนา)
อันนี้  ตัวใครตัวมัน ช่วยไม่ได้จริงๆครับ  555

ยังมีต่อ ขั้นตอนต่างๆ ทำเพื่อให้  "ทุกคน" เข้าใจตรงกัน
เรื่องของ "คน" นั้นซับซ้อน

แนวทางตามหลักการ  "หลัก" ต้อง "ทำ" (เขาวิจัยและใช้มามาก  คนส่วนใหญ่ยอมรับ)
ในส่วนขยาย/ส่วนย่อย   ทำเมื่อเหมาะสม  เช่น ไม่สามารถรอทำ Survey 6 เดือน

-----------------------------------------มีคนสงสัยถามมา
ผมมีความเห็น  "ทัก" ไปทั่ว แล้วผมทำอะไรล่ะ

หมั่นทบทวน  "ความรู้ ความเข้าใจ"  (ตัวผมไม่ได้  รับโอกาส ที่ง่าย)
- (วาด) ภาพรวม - ภาพโดยละเอียด      ...ทำเอง ได้อ่านคู่มือ, รายละเอียด จนถึงชื่อ table/field
- ทางเลือก  สิ่งที่ต้องทำ + สุดท้ายจะเกิดอะไร (game theory)
       เช่น มีคนบอกว่า ถ้า ย้ายไป SAP สำเร็จ   ตัวระบบ ต้องการ ทีมงานเก่า บางส่วนเท่านั้น 
       เลือกเอง
               เราจะได้ทำต่อ  เพราะ เรามีคุณสมบัติ  เหมาะกับทำต่อ
       หรือ เราจะไป  เพราะ เรามีความพร้อมที่จะไป

       ไม่รอให้เขา เลือกเราออกเพราะคุณสมบัติ,  ไม่ตั้งแก๊งค์ ถ่วง/ล้มกระดาน,ไม่รอปฏิหารย์

            "เรา" คือ ทีมงาน ไม่ใช่ คนๆเดียว
            เมื่อเลื่อก แล้ว  เป็นงานที่  ต้องทำต่อเนื่อง และใช้เวลา

ในช่วงที่   ไม่มีคำสั่ง (ร้องเพลงรอ)
-เลือก ทำ  ที่ได้ประโยชน์ ทุกทั้งตัวเรา ทีมงาน และบริษัท

ด้านคน
       "ส่งเสริม" ทุกทางให้  มี "ความรุ้ ควมเข้าใจ"
       - หาวิชา,สถานที่, อธิบายให้ หัวหน้า คนอื่นเข้าใจ
       - พร้อม อธิบาย  เสมอ (ไม่รังเกียจ หรือ หลีกเลี่ยง)
       กระตุ้น ให้ ทีมงาน ที่ไม่พร้อม -> ให้ สนใจ (ด้วยตนเอง)

ด้านเครื่องมือ
       เริ่มใช้  เครื่องมือใหม่   จนคล่องระดับหนึ่ง  และนำมาใช้งานจริง (เป็น ตย.ว่า ทุกคนก็ทำได้)
       [ ]  ระดมสมองด้วย Mind Map
       [ ]  แสดง งานในโครงการ  ด้วย Gannt Project, Project management
       [ ] เรียกดูผ่าน  แฟ้มกระดาษ, Share Folder, Web Portal

       ปรับการใช้  เครื่่องมือปัจจุบัน
       [ ] บันทึกช่วยจำ ด้วย To Do List
       [ ] เตือน ด้วย eMail

       หมั่นกระตุ้น  ให้ทุกคนใช้
       [ ] นัดประชุมได้เร็ว ด้วย Share Calendar

       เตรียม สร้างเครื่องมือ  (อ่านเอง)  ที่ลดเวลา
       [ ] วิธีเชื่อมต่อ ระบบงานที่ต่างกันเข้าด้วยกัน  .Net กับ Lotus Note
       [ ] ติดตามผลด้วย KPI, Digital Board

       เรียนรู้การทำ ETL ใน  MS Sql Server (SSiS)
       หัดเขียน .net ในส่วนที่  บริษัทภายนอก ใช้งานกัน
       สร้าง tool  ที่แตกต่างจากคนทั่วไปอื่น (db:class, xml, EF,...)

ด้านวิธีจัดการ
       สื่อสาร  Update ข้อมูลทุกครั้ง ที่ทราบ  (ทั้ง mail, พูดด้วยวาจา ส่วนตัว, กลุ่ม)
       เตรียมเพื่อให้ พูด ในภาษาของ คุ่สนทนา
        - จะคุยกับ  ฝ่ายผลิต, QC,  Note, Java, Store, Network, ...  ต้องพูดด้วยภาษาของเขา
              อ่านเอง,เรียนรู้

       "ลงมือ" ทำในส่วนงาน ที่ขาดหายไป
       - สร้าง คน ต่างกลุ่ม/ทีม  ให้รู้ (และมีตัวเลือกทำงานที่มากพอ)
       - ผลักดันให้  เกิด "งาน" ในส่วนที่หายไป (ส่วนใหญ่ ไม่อยากทำ)
              ทำโดยไม่มี  การ request


วันเสาร์ที่ 8 กุมภาพันธ์ พ.ศ. 2557

แล้วก็เริ่ม cleansing

แล้วก็เริ่ม cleansing

ก่อนหน้านี้  ขั้นตอนต่างๆ  ก็ได้คืบคลาน(กระดื๊บๆ)  ต่อไป

บริษัทที่ปรึกษา หลังจากเรียนรู้ 
- ฟังก์ชั่น การทำงานในองค์กร    โดยเทียบกับ ฟังก์ชั่นพื้นฐาน การทำงานทั่วไป
- ความคุ้นเคย, วัฒนธรรม  ที่สร้าง  "กฏ", "นิยาม" เฉพาะขึ้นมา

คนประสานที่ 
- ทำงาน  ตามใจฉัน  มากกว่า มาตฐานที่ควรทำ ... ก็เปิดใจ
- ความรู้  ที่คืนวิชาอาจารย์ไปแล้ว  ก็รีบไปเอากลับมา  น๊ะครับ

Cleansing  เป็นหนึงในขั้นตอนทำงาน
โดยหลักการ เมื่อทำ Database Design ก็ไม่ควรมีข้อมูลขยะให้เห็น
แต่ในความเป็นจริง   เราไม่ได้ทำตามหลักการทั้งหมด  เช่น
- ไม่กำหนด Primary Key
- การตรวจสอบ อยู่ที่  แต่ละโปรแกรม (มีทั้งถูกต้อง, ช่องโหว่)
- ทีมงานมีหลายคน, หลากหลายสไตล์

ขยะในฐานข้อมูลจึงมีมากขึ้น

แล้ว Cleansing ต้องทำอย่างไร ?

ในงาน Data Warehouse  การทำ Cleansing คือการ ตรวจตาม นิยามของ Field, Table
- ตรวจ Primary Key  
- ตรวจ ลักษณะ data ในทุก Field เช่น  
      Field วันที่    ไม่ควรมีข้อมูลผิดปรกติ  (ช่องว่าง, วันที่ 9,  วันที่ล่วงหน้าเกิน 1 ปี,...)
      Field สถานะ   ต้องมี 3 สถานะ  Active, Hold, Close  (ตัวอื่นๆต้องไ่ม่มี)
      เป็นต้น
 - ตรวจ Field ใน Detail ต้องมี  Head หรือ Master  (Relation)

... ถ้าพบ  สิ่งผิดปรกติ  ให้แก้ไข  (โดยมีข้อตกลงร่วมกัน  เช่น  แต่ละตัวจะปรับเป็นอะไร หรือ จะลบทิ้ง)

โดยส่วนตัวแล้ว  ก็เป็นเรื่อง ที่ใช้เวลา และละเอียดอ่อน ครับ
การสื่อสารให้  "ชัดเจน" และเข้าใจ  ก็ยังเป็นสิ่งจำเป็น

ตย.เช่น  กำหนดให้ทำ  โดยบอกแต่  "หัวข้อ" (ที่เหลือไปคิดเอง  ว่าจะทำ/ไม่ทำอะไร) 
      แล้วทำให้เสร็จใน 10 วัน  (หัก  แปล,คิด และ วันหยุดแล้วเหลือทำงานแค่ 5 วัน)
     (ถ้าต้องจัดการกับ File มากกว่า 200 Files  ต้องทำ 4 Server  ทีมงาน 4 คน)
>> ทำเท่าที่ทำได้  และ ทำใจ  ....

วันศุกร์ที่ 20 กันยายน พ.ศ. 2556

จัดลำดับ ปัญหา

จัดลำดับปัญหา

สำหรับระบบงานที่ทำกันมา "นาน" คนทำงานนาน ย่อย  "จะรู้" ดี
ถ้าระบบไม่ได้มีการ "ปรับใหญ่" (บ่อยๆ)    เมื่อถูกถาม  มักจะนึก  "ปัญหา" ไม่ออก ... ทำไม ?

แบบว่า  แรกๆ ก็  "จำได้แม่น"  ดีหรอก
แต่ในเมื่อ พบปัญหา แล้ว  "แก้ไขอะไรไม่ได้" (ก็มันเรื่องใหญ่)

สุดท้าย  จะกลายเป็นว่า  "เรายอมรับสภาพนั้น"
ภาวะที่   ฝังในสมองแบบถาวร ... เป็นที่มาว่า  นั่นไม่ใช่ปัญหาแล้ว!
ถ้าใครพูดถึงมัน  ก็จะถูกปฏิเสธ  ในทันที  (คำว่า "ไม่ได้" จะได้ยินมาก่อน)
(ฟังแล้วคุ้นๆมั๊ยครับ)

สำหรับผู้ที่จะ  ย้ายระบบ, ปรับระบบ
หนึ่งใน Keyword สำคัญคือ   ได้ประโยชน์อะไร ? จากการย้าย หรือ ปรับระบบ
โชคดีหน่อย - ระบบที่คุณจะซื้อ  เขาก็จะเขียนแนะนำไว้ให้ (มีให้เลือกมากมาย)
แต่หน้าที่ของ ทีมงาน ที่ทำคือ  หา keyword "สำคัญ" นั้นให้พบ
แยกเป็น   สำหรับ User ทั่วไป กับ ฝ่ายเทคนิค
เช่น หลังจาก "ย้าย" หรือ "ปรับ"
   -User จะทำ  "xxx", "yyy" ได้ (จากไม่เคยมี) หรือ ทำได้เร็วขึ้น
   -ฝ่ายเทคนิค จะตรวจสอบ "aaa"  ได้เร็วขึ้น  (ซึ่ง User อาจไม่สนใจสิ่งนี้)

>> เราต้อง
- "เตรียม"  รวบรวมปัญหา  ให้ได้มากที่สุด
- จัดลำดับความสำคัญ   เวลาสั้น ก็พูดแต่  Keyword ที่โดน
(iPhone 5s  ใหม่  ได้เพิ่ม feature มากกว่า 200 รายการ
คนที่คุณสนิท  จะบอกคุณ  เฉพาะที่โดนใจจริงๆ อาจจะมีแค่ 5-10 รายการเท่านั้น  )  

เทคนิค  

รวบรวมปัญหา

1. ตั้งชื่อย่อ  ที่ใช้เตือน (ชื่่อที่เห็นปุ๊บ เรารู้ทันที)
2. เตือนตนเอง  "ต้องทำ" บ่อยๆ
        - แปะที่   โต๊ะทำงาน,  หน้าจอ คอมพ์, บอร์ดส่วนตัว
        - ข้อความเตือน   ต้องสั้น, เด่นชัด

Q: ปรกติ  คุณจัดวางแบบไหน ? 


3. เมื่อ  "นึกปัญหาได้"  ให้รีบเขียน
       - บน Post-it,  short note, note file จัดเก็บไว้ ในที่  "เรียกใช้ง่าย" ด้วย


จัดลำดับ ความสำคัญ


1. แยกกลุ่ม ปัญหา สำหรับ User กับ IT
    ทบทวน User ส่วนใหญ่  ไม่สนใจ,ไม่เข้าใจ "เทคนิค"   พูดไปเสียเวลาเปล่า

2. จัดกลุ่มย่อย ภายใน กลุ่มข้อ 1
    หลายเรื่อง  อาจเป็นเรื่องเดียวกัน  แต่เข้ารายละเอียดปลีกย่อยต่างกัน
    - ดูราคาขายได้
    - ดูต้นทุนได้
    - ดูกำไรได้
    >> ข้อมูลขาย  ควรเห็นทั้ง 3 ตัว

3. จัดความสัมพันธ์  เช่น
    - เสียเวลา  ออกแบบ Table นาน -> ให้ดี  -> ทำให้สร้างโปรแกรมใหม่  ให้ User ได้เร็ว
    - กำไร = ราคาขาย - ต้นทุน    แทนที่จะพูด 3 คำ  พูด "กำไร" คำเดียวพอ

4. ให้น้ำหนัก (ใช้ประสพการณ์ + ความเข้าใจในวัฒนธรรมด้วย)
    - User อยากได้   ต้นทุน ต่อหน่วย  แบบ Realtime  มากกว่า ...
    - IT อยากได้  ระบบที่ "ไม่มีการหยุดเครื่อง"  มากกว่า ...


ตย. ที่ผมได้รวบรวม
- ต้องการข้อมูล RealTime
       User: การคิด/ตัดสินใจ บนข้อมูลเดียวกัน  ระหว่างแผนก ข้ามประเทศ  ใช้เวลานาน
              เรื่อง ...  การปรับ Forecast ของ Sale กับ โรงงาน, โรงงานผู้สั่งซื้อ กับ โรงงานที่ผลิตขาย
              ฟังดูง่าย  แต่เมื่อ 2 ฝ่ายมี  "ศักดิ์ศรี" เท่ากัน + ความเชื่อมั่นในตนเองสูง 
              ส่วนใหญ่  จะไม่มีใครฟังใคร  มักจะกำหนดทางที่ "ตนเอง" สะดวกที่สุด (ไม่สนใจ อีกฝ่าย)
              >> S/W ใหม่ = "คนกลาง"  ที่ให้ทั้ง 2 ฝ่ายปรับเข้ามาหา 
 
       IT : บางเรื่องใช้เวลา  ส่งต่อกัน 3-5 วัน  (ข้ามประเทศ)  เรื่อง ...
       IT : การสร้าง/ปรับ  มีหลายขั้นตอน (ยาก จนไม่มีใครกล้าทำ)  เรื่อง ....
- อยาก ลดขั้นตอน ให้สั้น
       User: ขั้นตอนเดิม เหมาะกับ สภาพ 10 ปีที่แล้ว  วันนี้ด้วยวิธีเดิม ทำให้ "ช้า"  เรื่อง ...
       IT: ข้อมูลชุดเดียวกัน  แต่แยกกันทำ  (ซ้ำ)  เรื่อง ...

เพิ่มเติม

เมื่อคุณมาถึงจุดนี้  อย่าลืม  เตรียม "คำตอบ" สำหรับแรงต้านต่างๆ ต่อไปนี้ด้วยครับ
- ไม่  ย้าย/ปรับ    ได้มั๊ย!
       มันก็  น่าจะใช้งานได้  อีก 3-5 ปี นี่นา   อีก 3 ปีค่อยมาคิดกันใหม่ (ซื้อเวลาไปก่อน)
- ok มาทำกันก็ได้  แต่ทำบางส่วนได้หรือเปล่า  แบบว่า ทำทั้งหมด   มันเสี่ยง,มันหนักไป,...
       (รักษารูปแบบ  ให้คงเดิมไว้สุดชีวิต)

>> ถ้า ปัญหาที่คุณ  รวบรวมและจัดลำดับไว้ดี   คุณจะตอบคำถามข้างต้นได้ "ง่าย"

note  บริษัทฯ ที่รับ implement ระบบ SAP บอกให้ฟังว่า
ถ้าจะให้ดี  ต้องใช้เวลามากกว่า 3 เดือนเพื่อปรับวัฒนธรรม
โดย "ต้อง" ทำก่อนเริ่มลงมือในขั้นตอนหลัก

- คุ้นๆมั๊ยครับ   ประเทศที่ขอเป็นเจ้าภาพ โอลิมปิค, ฟุตบอลโลก, เข้า AEC, ควบรวมบริษัทฯ
   ต้อง "ทำ" และ "ใช้เวลา"  ปรับ "วัฒนธรรม" กันเต็มที่
>> ถ้าคุณสังเกต  คุณจะเห็นความพยายาม ของกลุ่มคนทำงานนั้นๆ

ตย. ญี่ปุ่น เสนอตัวเป็นเจ้าภาพโอลิมปิค  2020
เพื่อให้เข้าใกล้  "ความสำเร็จ"  
       ประเทศใดที่ "ลงมือทำมาก"  ย่อมมีโอกาสสูงกว่า
       การแสดงความ "ตั้งใจ" ทำจริง  ย่อมดีกว่า  "แค่ทำให้ผ่านๆไป"

ถ้ามีโอกาสลองไปดู  การวิเคราะห์จาก คุณอรรถ  บุนนาค
พิธีกรในรายการ Divas Café  ของ Voice TV 
   - การเลือก/เตรียม โฆษก  (เลือกคนใหม่  แทนที่การเลือก  จากคนเก่าที่เก่ง   แต่ไม่ "ดีเลิศ")
   - การจัดลำดับ  เหตุการณ์ ใครต้องพูดอะไร ? เมื่อไหร่ ? ใช้คำอะไร ? (ที่โดนใจ)
           การกำหนด ท่า/คำพูด  ที่พูดแล้ว  จะเกิด "กระแส" Fever ไปทั่วประเทศ
           การจัดคิว ให้ นายกฯ ต้องเป็นคนพูด (งานนี้ระดับชาติ) 
แล้วลองเทียบดูตัวเรา  ว่า เพื่อให้ได้เป้าหมาย  "ตัวเรา" ได้ทำไป  มาก/น้อย แค่ไหน
      ถ้าเป้าหมาย "สำคัญ" ก็ต้อง  "ทำ" ให้เหมาะสมกับมัน น๊ะครับ ...
      ของแบบนี้ต้องฝึกทำกันได้ครับ  มันไม่ได้มีมาตั้งแต่เกิด

ยาก หรือ ?

- กินข้าวพร้อมหน้าทั้งครอบครัว อาทิตย์ละครั้ง (ทำได้บ้าง ไม่ได้บ้าง)
  ยาก ? พ่อ กลับมาสอนภาษาอังกฤษให้ลูก ... คนนี้อายุ 4x ปี ไลฟ์สไตล์คนกรุงเทพ
      (รถติดกลับบ้านดึก, เหนื่อย   มีเวลาสั้นๆกับลุก) -> คะแนนสอบเต็มครับ
      ... ใครจะรู้ใจลูก  เท่า  พ่อ/แม่ ล่ะ

- กอด "พ่อ/แม่" เมื่อมีโอกาส (มักไม่ค่อยมี โอกาส)
  ยาก ? มีบางคน "ล้างเท้าให้แม่" ทุกวันแล้ว ... คนนี้อายุ 3x ปี และได้เริ่มทำทุกวันมา > 6 เดือนแล้ว

วันเสาร์ที่ 4 พฤษภาคม พ.ศ. 2556

ระวัง พลาดเรื่องง่ายๆ!

มีเรื่องมาให้ Share ประสพการณ์ครับ

ที่มา

        เริ่มจากมีการติดต่อ  ให้พัฒนาระบบพื้นฐาน  "ต้องการให้ ระบบ Legacy ข้อมูล ก่อนสั่งซื้อ (Purchase Requisition) ส่งข้อมูลแจ้งเตือนและอนุมัติ ไปยังผู้เกี่ยวข้อง (eMail,Work Flow)  แล้วบันทึกกลับมาที่ Legacy เพื่อทำใบสั่งซื้อ (Purchase Order)"
        หลายคนฟังแล้ว แทบจะบอกได้ทันทีว่า  "เด็กๆ สบายมาก"  แต่จากสภาพแวดล้อมด้านล่าง ผมสรุปว่า  "ทำได้" แต่จะออกมา "ดีหรือไม่" ขึ้นอยู่กับ "วิธี" มาดูรายละเอียดกันครับ ...

เงื่อนไข  "โครงการ"  (ทั่วไป)
- ใช้ งบฯ ต่ำ
- User ใช้งาน "ง่าย" (ไม่ต้องเรียนรู้ จดจำ, จำนวนครั้งที่กดน้อย)
- IT จัดการง่าย  (ใช้เวลาน้อย, ปรับเพิ่ม/เปลี่ยน funcion)

สภาพแวดล้อม

        สำหรับ  บริษัทขนาดใหญ่  ทั่วไป
  • ทีมงาน Legacy จะถูกจำกัดให้ใช้เทคโนโลยีเก่า (+เฉพาะ เช่น RPG) เพียงเรื่องเดียว  มีความเชี่ยวชาญ Busines Concept มาก  
  • ทีมงาน เครื่องมือใหม่ (+ เฉพาะ เช่น Lotus Note,Web)  จะเรียนรู้และใช้เครื่องมือใหม่ได้เร็ว  แต่มักจะไม่เข้าใจ Business Concept ลึกซึ้ง
  • ทีมงาน Admin เมื่อแยกตามเทคโนโลยีข้างต้น ก็ต้องมี 2 ทีม  
        "ที่มา" บอกให้รู้ว่า   ต้องการงานที่ผสมเทคโนโลยี  เก่า/ใหม่  เข้าด้วยกัน   ทีมงานข้างต้นต้องทำงาน "ด้วยกัน" 

        ลองทายซิว่า  ความสัมพันธ์ระหว่าง "ทีม" ข้างต้นเป็นอย่างไร ? ... เดาได้ไม่ยากน๊ะครับ  เหมือนคุยกันคนละภาษา (ทั้งที่อยู่ในฝ่าย IT เหมือนกัน)  อย่างดีหน่อยก็คุยขำๆ กันได้ แต่คุยจริงจังกันไม่ค่อยรู้เรื่อง (มันซับซ้อน  ฉันรู้ในเรื่องของฉัน  ไม่รู้เรื่องของคนอื่น)

          ลักษณะข้างต้น  มักจะเกิดจาก  องค์กรเติบโตแบบ "ตามมีตามเกิด"   ผู้นำ/ผู้ตาม เลือก "วิิธีที่ง่าย" ในการดำเนินชีวิตประจำวัน  ก็จะเกิดสภาพแวดล้อมข้างต้น

ตัวเลือก Solution ต่างๆ 

- ซื้อ/ จ้างทำ (สูตรสำเร็จ)
        ถ้าสำเร็จ    เรา​"เป็นคนเลือก"  
        ถ้าล้มเหลว  ก็โทษ Vendor  ซะ (แล้วจะหาเจ้าใหม่มาแก้ปัญหา)
        ... ขำๆ น๊ะครับ  (อืมส์  แต่ก็เห็น  หลายบริษัท  ยังใช้วิธีนี้กันอยู่) 
- ให้ทีมใดทีมหนึ่ง  เป็นหลัก   และทีมอื่นสนับสนุน
        ถ้า "ไม่" สื่อสารกัน   ก็จะเหมือน  ทำพลังของ"คนเดียว" ไม่ใช่ "ทีม" (แค่ทำได้  แต่ไม่ได้  สิ่งที่ดี)
ถนัดอะไร ก็ใช้สิ่งนั้น 
- ทำเหมือน  "โครงการ" ทั่วไป
         จัด/หา ผู้นำโครงการ  ที่ดี  แล้ว "สนับสนุน"  ให้เขาทำสำเร็จซะ

เหตุการณ์ 

- เมื่อแยกคุยกัน   ทุกทีม  ต่างตอบเหมือนกัน ว่า "ทำได้" 
- (เดา) อยากทำเลย  ไม่อยากเสียเวลา  ประชุม 
- (สนับสนุน) : นัดคุย  ทุกทีมที่เกี่ยวข้อง  "พร้อมกัน" เป็นทางการ
        ถ้าทุกคน ไม่อยากคุยกัน  ก็ต้องให้  "คนที่ตำแหน่งสูงกว่า" นัดครับ  ปล่อยให้นัดกันเองคงยาก
- (เดา) ปรกติ  ทุกคนจะไปคิด พร้อมๆ กันในห้องประชุม
        ก็ ระดมสมอง (Branstorm) ไงครับ 
- (สนับสนุน) : งานไม่ยาก  ก่อนประชุม  เตรียมเอกสาร - แผนภาพ 
        การพูดๆๆๆ ที่ เข้าใจคนเดียว  "ไม่ใช่"  การสื่อสารที่ดี
- (สนับสนุน) : หาข้อมูล  ลดข้อสงสัย
        ถ้า  ทำเฉพาะ ในทีมใด ทีมหนึ่ง  ยาก/ง่าย ?  ต้องทำอะไร ?
        - เตรียม  เอกสารเพื่อใช้อธิบายในส่วน Legacy  (มันยาก -> อย่างไร ?)  (ข้อมูลมาก-> อย่างไร ?) 

        ถ้า  ใช้ Legacy อ่านข้อมูลใน Lotus Note  ยาก/ง่าย ?  ต้องทำอะไร ?        
        ถ้า  ใช้ Lotus Note  อ่านข้อมูลใน Legacy  ยาก/ง่าย ?  ต้องทำอะไร ?
        - เข้าไปอ่าน "หนังสือ" หรือ "slide แนะนำ"  ศัพท์ ข้างต้น

        ถ้า  ใช้ Web อ่านข้อมูลใน Legacy,  Lotus Note  ยาก/ง่าย ?  ต้องทำอะไร ?

        เข้าไปคุย  กับตัวแทนแต่ละทีม  ถามหา idea ->  สงสัยในศัพท์อะไร -> ทำความเข้าใจ
        -  เคยพบมั๊ยครับ    แต่ละคนพูดเรื่องเดียวกัน = ฟังไม่เข้าใจ
           ทำไม่ได้,  ทำได้วิธีเดียว เท่านั้น , มีอีกวิธีแต่ ... , ... 

- (สนับสนุน) : สื่อสาร  ข้อมูลข้างต้น  เอกสารขั้นต้น (ย่อ เน้นภาพ) + อธิบายทางวาจา 
  (ดีกว่า ส่งให้อ่าน กันเอง หรือ อาจจะไม่ได้อ่าน) ... ผมอธิบายให้ทีม Legacy

- ก่อนประชุม  ทีม Legacy เข้าประชุม 1 คน  ทีมเครื่องมือใหม่เข้าประชุม 6 คน  ผู้จัดการ 1 คน
- (เดา) : ผู้จัดการ เลือกใช้วิธี "เชิงรับ" โดยให้ทีมงานจัดการกันเอง (คอยเติมส่วนที่ขาดเท่านั้น) 
  ... เป็นวิธีที่ไม่เหนื่อย 
- (เดา) : ทีมเครื่องมือใหม่  ใช้การประชุมเป็นการ share info กันภายในทีมด้วย

วิเคราะห์

(สนับสนุน) คือ สิ่งที่ขาดหายไป   ส่วนหนึ่งเกิดจาก "วัฒนธรรม" ที่ผิดปรกติ (ขาดหายไป)
คนไทยเก่งทำงานคนเดียว  แต่ล้มเหลว เมื่อทำงานเป็น "ทีม" (ไม่สามารถแสดงพลังของทีม
...น่าเสียดาย)

เหตุการณ์ข้างต้น  เหมือนกับที่ทำงานของแต่ละท่านมั๊ยครับ ?
ถ้าเหมือนกัน  อะไรที่  "แต่ละคน" ต้องทำ  เพื่อให้  "ทีมงาน" แสดงศักยภาพเต็มที่

ผู้นำ กับ ผู้ตาม  จะมีหน้าที่  "ต่างกัน" น๊ะครับ   เพียงแค่เข้าใจ และ "ลงมือทำ"
ข้อแนะนำ ที่ดี (ฟังมาอีกที)  คือ  พยายามทำงานประจำวัน  ให้ "ครบ" จนกลายเป็น "วัฒนธรรมที่ดี"
         โดย  ค่อยๆ เพิ่ม "สิ่งที่ต้องทำ" อาจจะหนักบ้าง,ลำบากบ้าง
         และหลีกเลี่ยง  การ "ขี้เกียจ" หรือ ทำงานแบบสบายๆ

งานนี้ผมไม่ได้ เข้าร่วมประชุม  แต่เป็นส่วนหนึ่งในการทำ (สนับสนุน)
บางเรื่องเป็นงานที่ "ถนัด" บางเรื่อง ก็เกินหน้าที่ไป
แน่นอนว่า  ต้องมีอุปสรรค
- อาจมีคน  มองการ(สนับสนุน) เป็นสิ่งที่เป็นอันตราย ต่อชีวิตประจำวัน ของเขา
           ทำเกินหน้าที่, แย่งชิงหน้าตา, ... 
- ผมต้องเผชิญ กับ การปฏิเสธ (การเปลี่ยนแปลง) ในทุกรูปแบบ
ไม่ต้องกลัว  ถ้าคุณยัง "คิดดี"  สิ่งเหล่านี้เป็น อุปสรรคขนาดเล็กๆ เท่านั้น
(ปัญหาใหญ่ อยู่ไม่นาน  คนหนักแน่น  อยู่ได้นานกว่า)

ความหวัง

           อยากเห็นการเปลี่ยนแปลง  ในทางที่ดี  "กล้าเปลี่ยน"
           คน IT  ต้อง "รู้หน้าที่" ตนเอง -> "รอบรู้"  (ยิ่งเป็นผู้นำ ก็ต้องรอบรู้กว้างมากขึ้น)  ,ทำงานได้หลากหลายฟังก์ชั่น  (ใช้คนน้อยลง  แต่ได้ประสิทธิภาพสูง)

วันเสาร์ที่ 16 มีนาคม พ.ศ. 2556

ได้เห็น ในสิ่งที่ คิด(ดังๆ)


ไม่ต้องแปลกใจกับหัวข้อครับ   ผมจะเล่าความคืบหน้าของการเปลี่ยน Legacy ไปเป็น ERP (ภาคต่อ)  ภาคนี้เห็นขั้นตอนการทำงานของบริษัทคนกลาง (ตัวละครใหม่) และ วัฒนธรรมในองค์กรต่อ (การเปลี่ยนแปลง)

การเคลื่อนไหวของผู้นำ

มีข่าววงในรายงานมาว่า  ทีมผู้บริหารไม่มั่นใจว่าเงินที่ต้องจ่ายในการเปลี่ยนระบบ ERP   จะได้ผลลัพธ์ตามต้องการ แค่ไหน  ?   จะกังวลไปทำไม  ซื้อของแพง=ของดี  ก็ลดความกังวลได้  หรือว่ามีคนมาแซวว่า  บริษัทที่เคยเลือกใช้ SAP จะรู้ว่าว่า  SAP ย่อมาจาก Sad After Purchase กระมังครับ

ถ้าใครยังไม่เข้าใจว่า  ลองนึกกลับไป  ตอนจะซื้อสินค้า “แบบดี,ราคาแพง”   

เช่น  จะเลือกซื้อมือถือ ราคา 3-6 พัน  หรือ  iPhone  ราคา 2 หมื่น ดี   จะอธิบายว่าใช้ “ของแพง=ของดี”  , ตัวไหนจะใช้งานได้ตรงตามเป้าหมายหลัก,  หรือ ถ้าคุณจำโฆษณาแม่น  ก็แค่พูดเหมือนโฆษณาในทีวีก็พอ  เช่น มือถือราคาแพงโทรคุยกับที่บ้านแบบเห็นหน้ากันได้   ส่วนเป้าหมาย “ในใจ”  (ส่วนเสริม  ก็ไม่ต้องพูด ก็มันสวย, มันเท่ห์ ตามแฟชั่น )   แน่นอนว่าเมื่อจ่ายเงินซื้อไปแล้ว  มักจะ”ทิ้ง”  เป้าหมายหลัก  แทบจะ “ทันที” !  ด้วยเหตุผลใหม่ๆ  (จริงๆ ส่วนใหญ่ ก็รู้ก่อน น๊ะแต่ทำเป็นไม่รู้ซะงั้น)   

คนกลุ่มนี้  มักจะคิดเข้าข้าง (หลอก) ตนเอง  ในเรื่องเล็กๆ ก่อน   แล้วถ้าทำซ้ำก็จะกลายเป็นความเคยชิน เป็นเรื่องปรกติ (ในที่นี้ต้องขอชมฝ่ายการตลาดที่สามารถ โน้มน้าวคนส่วนใหญ่ให้มองไปในด้านเดียวได้)    แน่นอนว่าเมื่อเป็นเรื่องปรกติ  ขอบเขตที่ใหญ่ขึ้นเรื่อยๆ ก็ต้องเป็นเรื่องปรกติไปหมด  (วัฒนธรรมแบบนี้ชักไปกันใหญ่)  
ออกนอกเรื่องไปซะไกล   กลับมาที่เดิม  ทีมผู้บริหารเริ่มสงสัยว่า  “เราจะเลือกซื้อ/จ่าย เงินแพงมาก  เพื่อซื้อสิ่งนี้  แล้วจะได้ตรงเป้าหมายหลักจริงๆ หรือ ?”    ขั้นตอนแรกเป็นการนำข้อมูลกลับไปทบทวนใหม่    ขั้นตอนต่อไปได้จ้างบริษัทคนกลาง  มาวิเคราะห์แล้วทำรายงานสรุปออกมา  

บริษัทคนกลาง

อ๊ะ!  “ก่อน” ตัดสินใจเริ่มโครงการ ในบริษัทก็จะต้องมีทีมงานทำรายงานนี้แล้วนี่นา   
ผู้เขียน  “เดา” ไว้ว่า
  รายงานสรุป  “ไม่สามารถสื่อ"  ให้เข้าใจได้ง่าย  หรือ  ทีมผู้บริหารไม่เข้าใจ  (ก็ 50% เป็นงานทางด้านเทคนิคเฉพาะ)  ต้องยอมรับกันว่าผุ้บริหารระดับสูง มักจะไม่ค่อยรู้เรื่องเท่าไหร่ และน่าจะใช้วิธี  “เชื่อใจ” แทน  แต่ ในยุคที่มีการเบี่ยงเบนผ่านสื่อมากการเชื่อใจคงทำลำบาก (นาย ก บอกว่าดี  นาย ข บอกว่าไม่ดี   แล้วจะเชื่อใครล่ะ แป่ว!)  

การเลือกบริษัทคนกลาง จึงเป็นการเพิ่มความ “เชื่อใจ” ที่ดี    แต่ก็สิ้นเปลือง งบประมาณและเวลาพอสมควร   ถ้าทีมงานในบริษัททำงานกันเต็มที่  รายงานที่ได้จะได้ผล(Fact)ออกมา “เหมือนกัน”  (เหมือนจ่ายฟรี)   แต่ถ้ารายงานออกมาตรงข้าม  คงเป็นเรื่องที่ปวดหัวเอาการ  ถ้าคุณเคยคุยกับบริษัทคนกลาง  เขาจะตอบว่า  เขาชอบไปแนะนำลูกค้า ที่ “ขาดหลายเรื่อง”  เพราะ  ลูกค้าจะรู้สึกคุ้มค่า   แต่ถ้าไปแนะนำลูกค้าที่ “รู้ทุกอย่าง”  แต่ไม่อยากเปลี่ยน   คำแนะนำหลักคือ  เปลี่ยนที่คนก่อน (คนฟังก็จะรับไม่ได้)  คำแนะนำอื่นๆ  มักจะไม่ได้รับความสนใจ (ก็รู้อยู่แล้ว) 

ส่วนที่ผู้เขียนได้ข้อมูลมา  บริษัทกลาง  มาทำขั้นตอน  Gather Information
ซึ่งเป็นส่วนถัดไป  หลังจากทราเป้าหมาย,ประกาศ(ว่าจะทำ)   ผู้ที่ทำโครงการมาจะคุ้นๆน๊ะครับ  โดยทาง IT จะเพิ่มรายละเอียดของข้อมูลลงไป
      
เป้าหมาย               เปรียบเทียบ  ผลจากการซื้อ S/W ใหม่(รวมขั้นตอน) หรือ ปรับสิ่งที่มี (ปรับอะไร)
ประกาศ                 เป็น “นโยบาย”  (ทุกคน  “ต้องมีเวลาว่าง”  มาทำ  ในแนวทางเดียวกัน)
พื้นฐาน                   บริษัทวิจัย ต้องมีความพร้อม  (ทีมงาน  ที่มีความรู้ ดีเยี่ยม  IT, S/W, การบริหารจัดการโรงงาน)
Gather Information - (ข้อเท็จจริง)
  • เลือก ทีมงาน / Key man
  • นัดคุย (ภาพรวม, ศัพท์)   นั่งอยู่ในพื้นที่จริง
  • ขั้นตอนการทำงาน ปัจจุบัน
  •  รับฟัง  ความคิดเห็น, ปัญหา 
  •  ให้คำแนะนำ ตามหลักการ (นำไปใช้ได้ทันที)
  • เปลี่ยน  ความรู้สึก  เป็น Fact  “สินค้ามีมาก” -> ( กี่รายการ  ใช้จริง (6 เดือนที่ผ่านมา) กี่รายกา
  • ทำไม่ได้  เพราะติด ... (แสดงรายละเอียดประกอบ)
  •  ...

ขั้นตอนข้างต้น  ดูเป็นทางการ + รูปธรรมชัดเจน  (คุยกันในห้องประชุม  มีการนัดหมายเป็นทางการ)
การทำงานร่วมกัน  หลายคน จะมีข้อกำหนด "ร่วมกัน"  ที่ต้องใส่ใจเล็กน้อย 
แต่ที่ผมพบเห็นส่วนใหญ่  คนของเรา "ไม่เข้าใจ"  (ขาดไป เช่น ไม่เข้าร่วมเลย  , เกินไป เช่น  นัดประชุมถี่  โดยไม่ได้เนื้องานอะไร เป็นต้น)   

ได้เห็น สิ่งที่เคย คิด(ดังๆ) และเคยเริ่มต้นทำ

     ติดตั้ง/ซื้อเครื่องมือ (มีฟรีให้เลือก), จ้าง Vendor,  ส่งไปเรียน (มีหลายที่เปิดสอนในราคาทีถูก)

ทั่งในส่วนของ ผู้นำ และ ผู้ตาม  คนอื่น  ที่ต้องสนับสนุน (ไม่ใช่  ถ่วง)  

ผมเชื่อว่าภายในบริษัทฯ คงมีคนดีศรีอโยธยาบ้าง   แบบว่าคงมีคนคุยกัน   คิด(ดังๆ)     ซึ่งแน่นอนว่ามีทั้ง  เริ่มทำ, ไม่ใส่ใจ, ไม่สนใจ


วันนี้ถ้าต้องทำตามสิ่งที่  บริษัทคนกลางแนะนำ  ตัวเรา  ก็ต้องยอมรับว่า  ผลจากการกระทำที่ผ่านมาเราลด “ศักยภาพ” ตนเอง   เมื่อเราเองก็รู้แต่ไม่ได้ลงมือทำ คนอื่นมาสั่ง จึงจะทำ     ให้นำบทเรียนนี้   มาพัฒนาตนเอง

ส่วนใหญ่  ก็รู้ว่า  การทำโครงการ   ต้องทำอย่างไร ?  ก็แค่เข้าใจ  ลงมือทำ  และทำให้เป็นเรื่องปรกติ
(ไม่ทำเรื่องเล็กให้เป็นเรื่องใหญ่    ไม่มองเรื่องใหญ่เป็นเรื่องเล็กน้อยจนไม่ทำ)
เมื่อทบทวนดู   เราอาจจะได้เคยเริ่มทำสิ่งนั้นไปแล้ว  หรือ เราได้ปฏิเสธการทำสิ่งนั้นไปโดยไม่รู้ตัว
  • มีความรู้พื้นฐาน  ต่องาน   วิชาชีพ,ความรู้ประกอบ, ใช้เครื่องมือช่วยให้คล่อง
  • Key man ต้องเพิ่มความสามารถในการสื่อสาร
  • ลดขั้นตอนที่มาก    เน้น  ความเข้าใจ  มากกว่าท่องจำ, วิธีมาตรฐานทั่วไป แทน วิธีเฉพาะ
  • ต้องมีเอกสารพื้นฐาน (อะไรบ้าง)
  • ..

 คุ้นๆมั๊ยครับ 



มีคนมาคุย/เสนอ idea ที่ดี   แต่คุณไม่มีเวลาแม้แต่ “รับฟัง” หรือ “ฟัง” แต่ไม่มีเวลาไปคิดต่อ
คิดและทำแล้ว  แต่ทำเองคนเดียว...  ก็งานส่วนตัว  คนอื่นก็ไม่สนใจ น๊ะครับ
ไม่อยากเสียเวลาทำเอกสาร  = ทำให้คนอื่นใช้ ตนเองก็ไม่ได้ใช้
การประชุมใช้เวลานานมาก  ทุกอย่างไป"เริ่มคิด" ในห้องประชุม  ทั้งๆที่บางเรื่องเตรียมไว้ก่อนได้
แค่รับทราบ  หรือ  ต้องการให้มีส่วนช่วย    นัดทุกคนไว้ก่อน แต่ที่จะคุยกันแค่ 3 คน 

ทราบจากการคุยกันว่า  บางบริษัทกำหนดเป็นแนวทางว่า  Key Man ต้องผ่านการเรียน/ปรับ พื้นฐานก่อน
(เมื่อผ่านแล้วจึงให้ไปเป็น  ผู้นำในโครงการได้)

FAQ คำถามที่ถามบ่อย


Q: โครงการใหญ่  มักยุ่งยาก และใช้เวลาน๊ะ
A: ก็ชื่อมันบอกแล้วครับ “งานใหญ่”  จะทำง่ายๆ เหมือนงานเล็กๆได้อย่างไร 
Q : เป้าหมาย        กำหนดอย่างไร ?
A: ผู้บริหาร ถ้าได้คุยกับ Vendor > 2 รายดูจุดขายของ S/W, ดู ตย. (ดูงาน) บริษัทฯอื่น  ก็จะรู้
Q: ประกาศ   ไม่ต้องทำก็ได้  (ดูงานจริงจริง, งานใหญ่ไป, เดี๋ยวหน้าแตก)
A: ไม่ประกาศ = งาน “เล็ก” ครับ (ประกาศอย่างเดียว ยังไม่พอเลย  ต้องสะกดจิตด้วย  555)
Q: เตรียมคนที่มีความรู้ดีเยี่ยม  อย่างไร ?
A: กำหนดหัวข้อให้ชัดเจน (ทำเอกสารแบบนี้ได้  -> ใช้อะไรทำ, ภาษาคอมพ์ -> Fix ภาษาอะไร หัวข้อต้องรู้)
Q: รอให้ ระบบเสร็จ  แล้วค่อยมาเรียนรู้ได้มั๊ย ?
A: ได้ครับ  ถ้าเริ่มต้นจากศูนย์    โละพนักงานเก่าออก 50แล้วจ้างพนักงานใหม่ มาทำแทน   ประหยัดเงิน และ ทำงานง่ายกว่าด้วยครับ (พนักงานเก่า  เงินเดือนสูง, เรื่องมาก เมื่อเทียบกับพนักงานใหม่  เงินเดือนต่ำกว่า และเชื่อฟัง)
Q: พนักงานปัจจุบัน ไม่กระตือรือล้น  ขัดขวางทุกวิธี 
A:  เริ่มสร้างวัฒนธรรม  ครับ  (การบริหารจัดการคน  เป็นหน้าที่ของ ผู้นำ  อยู่ๆมันไม่ได้เกิดขึ้นมาเอง)
Q: จะรู้ได้อย่างไรว่า  สิ่งที่มีดีอยู่แล้ว หรือ ขาดอะไร ?
A: ทดสอบโดย   ลองเทียบกับ S/W ที่วางขายในท้องตลาด, ขั้นตอนที่บริษัทอื่นทำ (ตอนไปดูงาน)  ก็จะรู้แล้วครับ

ถ้าผู้นำคนไหน   อ่าน  FAQ  มาถึงตรงนี้  แล้วไม่รู้คำตอบมาก่อน  อย่าเพิ่งทำโครงการครับ
กลับไปทบทวนบทบาท/หน้าที่ของ ตนเองก่อน
เพราะ  ปัญหาข้างต้นเป็นอุปสรรคพื้นฐานทั้งสิ้น 
ทุกครั้งที่ผู้นำทำงาน”จริง” ก็จะพบคำถามและทางออก  เมื่อทำงานชิ้นต่อไปก็มักจะเตรียมหลายๆเรื่อง “รอไว้ก่อน”    แนวคำถามข้างต้น  ผมมักจะเอาไว้ใช้อธิบายทีมงาน (ผู้ตาม) ที่สงสัยว่า  ทำไมต้องทำขั้นตอนมากมาย (ผู้ตาม มักคิดคนละมุมกับ ผุ้นำ  และผู้ตามจะคิดในมุมแคบๆ)

วันอาทิตย์ที่ 6 มกราคม พ.ศ. 2556

(ฟัง) กระแส

กระแส

เราได้พบเห็น  กระแสใน  Social Media กันมาแล้ว
เช่น จากเรื่องไม่เป็นเรื่อง  ก็กลายเป็นเรื่องใหญ่ได้,  เรื่องที่ไม่รุ้  ก็รู้กันทั่ว

ในด้านจิตวิทยา "คน" ประเมินได้ยาก  หลากหลายมาก  (เฉย, อยากรู้, ตื่นตัว, สับสน, ...)
ในด้านเศรษฐศาสตร์ เรื่อง Long Tail  
เรื่องที่ไม่น่าจะมีคนสนใจ  ก็ "ยังมี" คนสนใจ (ถึงแม้ว่าจำนวนน้อย)  
(การคาดการณ์ ที่สมบูรณ์  ต้องครอบคลุม "ทุกกรณี"  จะมองข้ามไม่ได้)

การประกาศ  เปลี่ยน Legacy (โปรแกรม IT พื้นฐาน) ไปสู่ SAP  ย่อมมีกระแสตามมา
- เฉย       อันนี้   ไม่รู้ว่าจะเกิดอะไร, รู้แต่คิดว่าทำอะไรไม่ได้,...
- อยากรู้  คนส่วนใหญ่ อยากรู้อยากเห็น
       ถ้าอยากรู้ตามแฟชั่น  คนอธิบายก็ไม่ต้องพูด เข้ารายละเอียดมากนัก
       ถ้าอยากรู้จริง  ก็ช่วยกันส่งเสริมกันน๊ะครับ
- สับสน  มักจะเกิดจาก "ได้รู้" (แต่ไม่ครบ) ทำให้  ไม่ได้ "คำตอบ"
       ฉันต้องทำอะไรล่ะ ? เมื่อไหร่ ? อนาคต ฉันจะเป็นอย่างไร ?
- ตื่นตัว (จริงๆ) ในที่นี้ คือ พร้อมที่จะทำๆๆๆ  เพื่อตอบโจทย์ต่างๆ
       สนับสนุนทุกทางเลยครับ

จะเห็นว่า  เมื่อ "สื่อ"  ข้อเท็จจริง  หลีกเลี่ยงพูดแบบสนุกปาก จะช่วยได้มาก

เราสามารถจับกระแส ได้จากการ "เมาท์" กันนอกงาน
ไม่ต้องคิด : ถ้าคุณเป็นผู้ตาม
น่าคิด : ถ้าคุณเป็น  "ผู้นำ" หรือ หนึ่งในทีมงาน  คุณจะทำอย่างไร ?

โครงการณ์ใหญ่ -> ถ้าโดนกระแสต่อต้าน,ขัดขา  โครงการณ์ก็พร้อมจะล้มพับได้
โครงการณ์ใหญ่  มักจะคาดเดาผลลัพธ์ ที่ชัดเจนได้หลายช่องทาง
- ล้มเหลว (ผู้นำการเปลี่ยนแปลง ต้องออก,  ทุกอย่างกลับสู่สภาพปรกติ)
- สำเร็จ 
     100% (ทำได้เฉพาะ คนในองค์กร พร้อมจริงๆ)
     75%   ผมคิดว่า ผุ้นำคงคิดว่า ต้องมาถึงจุดนี้ (จะเห็น  ความสำเร็จชัดเจน)
     50%   พบบ่อย  (งานลูกครึ่ง)  ทำงานหนักกว่าเดิม (ซ้ำซ้อน)
               ยื้อเวลาออกไปอีกระยะ ใครจะอึดกว่ากัน

ความเห็นของผม - "รีบ" รอบรู้ข้อเท็จจริง
+ คิด ทบทวน ทางหนีทีไล่ไว้  (ลองใช้แนวคิดนี้ช่วย Game Theory, MindMap)

เช่น  ก่อนทำ, ระหว่างทำ, หลังทำ

- โครงการต่างๆ เป็นการมอง "วิธีการ" ที่ลอกจากความสำเร็จในที่อื่น
   บนพื้นฐาน  "ความพร้อม"  (งบฯ,คน,เครื่องมือ,ขั้นตอน)
- ปัจจัยทั้ง 4 ข้างต้น   ส่วนที่ยุ่งยากที่สุด คือ "คน"

การเริ่มงาน ต้องการ "ทีมงานปัจจุบัน" ช่วยทำ
แต่เมื่อทำงานสำเร็จ เรายังต้องการ "ทีมงานปัจจุบัน" หรือไม่ ?
(คำพูดที่ดูดี  คือ  เมื่องานเสร็จ ทีมงานทุกคนต้อง "ปรับ" ตัวตามได้แน่นอน)

การจัดการ "คน" เป็นเรื่องยาก
แต่เราได้เห็น "สิ่งที่ยาก" เกิดขึ้นได้แล้ว  ... ส่วนหนึ่งเกิดจาก  การวางแผนรับมือที่ดี จากผุ้นำ
(การ "รอ" สิ่งมหัศจรรย์  มันเลื่อนลอยมาก)

(ฟัง) กระแส

คำถามยอดฮิต
Q: ERP ใหม่  ดีกว่า เก่า อย่างไร ?  (จะแก้ปัญหา ปัจจุบัน เรื่องอะไร ?)
Q: ERP ใหม่  จะเปลี่ยนวิถีการทำงานประจำวัน อย่างไร ?

วิถีการทำงานประจำวัน นี่แหละ "น่ากลัว"
นาย ก : ต้องทำเอกสาร a วันละ 4 ชม.  
    วิธีใหม่  ไม่ต้องทำ-  แล้วเวลาที่เหลือทำอะไร ?
    ...ไปคิดกันเอง หรือ เอาไว้ค่อยคิดกันเมื่อเสร็จโครงการ หรือ ผู้นำ จัดตรียมไว้ให้คือ ...
    (ก่อนเริ่มทำโครงการ  ผู้นำ  ตอบคำถามนี้อย่างไร ?)

2 ตัวเลือกแรก  สร้างกระแส "ลบ" แน่นอน

ตัวเลือกสุดท้าย  ดูดี  แต่ถ้าตอบว่า  ก็ย้ายไปทำงาน C ซิ (ซึ่งนาย ก ไม่พร้อมที่จะทำ)
คำตอบนี้  ดูเป็นการ "กดดัน" ทางอ้อมน๊ะ

ในมุมมอง  "คนเก่ง" อาจจะมองว่า  งานที่เตรียมให้ใหม่   "ไม่ยาก"
แต่ถ้า  ผู้นำ  บริหารให้  ทีมงาน "จม" อยู่กับความเคยชิน
นั่นคือ คุณเป็นคนสร้าง "ส่วนนี้" ให้เขา


วันอาทิตย์ที่ 30 กันยายน พ.ศ. 2555

จะเริ่มต้นอย่างไรดีล่ะ

จะเริ่มต้นกันอย่างไรดีล่ะ

เป็นคำถามยอดฮิต  เลยครับ
สำหรับ ผู้นำควรถามในใจมากกว่า จะพูดออกมา (จะดูเหมือนไม่มี กึ๋น ฮ่าๆๆๆ)

ผมเชื่อว่า ผู้นำทุกคนมีวิธีของตนเองอยู่แล้ว  และใช้งานได้หมด เช่น

เน้น "เร็ว" -> ให้เข้าใจได้เร็วที่สุด 
เน้น "ลดความซ้ำซ้อน" -> ยุ่งยากไปนิด  แต่ภาพรวมใช้เวลาสั้นที่สุด
     (ถ้าการเรียนรู้ 5 ครั้ง  ต้องเสียเวลา ฟัง/อ่าน  intro ซ้ำๆกัน คงไม่ดีแน่)
เน้น "ลงมือปฏิบัติ" -> ทำจริงย่อมจำได้แน่นอน
...

แต่...  สำหรับมืออาชีพ  คงต้องเลือกวิธีที่  "เหมาะที่สุด" ครับ
หลายคนเลือกวิธี  ที่ตนเอง ทำง่ายที่สุด  เปลี่ยน "ลำดับ" ความสำคัญไปดื้อๆ
จากผู้เรียน   ต้องได้รับประโยชน์สูงสุด
เป็นผู้นำ   ทำอะไรก็ได้  ที่สะดวกที่สุด  แป่ว! (จะไม่ลงแรงเลยหรือไง)

Idea ของผม

การเรียนรู้ระบบฯ ขนาดใหญ่  ที่มีนิยามมาก, ความสัมพันธ์มาก, ...
ก็ต้องหาวิธี "จำ"/"เข้าใจ" ให้ได้มากที่สุด
วิธีที่ใช้บ่อย คือ  ฟัง,พูด,อ่าน,เขียน  มากๆ

โครๆ ก็รู้  สุ,จิ,ปุ,ริ - แต่มันทำไม่ได้ ง่ายๆนี่นา (จริงมั๊ย)
- ต้องมีคนสอน  (จะหาได้ที่ไหน   ฟรี, สอนเก่ง, ใช้เวลาสั้น, ...)
- ต้องมีการพูดคุยกัน เป็น "งาน" ประจำวัน  (ก็ยังไม่เริ่ม แล้วใครจะมาคุยกันล่ะ)
- ต้องมีเอกสารที่อ่านง่าย  มีน้อย  น่าอ่าน  เป็นการ์ตูนได้จะยิ่งดี  (ตื่นๆ)-
- เขียนหรือ ?  หมดยุคการเขียนไปนานแล้ว (แป่ว)

ใครที่เป็น  คนรุ่นเก่า อย่างผม  ก็คงอึ้งไปเลย เมื่อเจอะเหตุผลต่างๆ
แต่ผมยอมรับน๊ะครับ  ว่ายุคนี้  เป็นแบบนี้
(ไม่แปลกใจที่  คนรุ่นใหม่ส่วนใหญ่  ทำงานต่อจากคนเก่าไม่ได้  
  ดูจะเหมาะกับ  ธุรกิจ หรือ บริษัทฯรูปแบบใหม่  เช่น ขายของทาง internet เป็นต้น)

กลับมาต่อ  (มีคนทักว่า  ผมขี้บ่น  ออกนอกเรื่องเรื่อย)
มาเปลี่ยน  Vision เป็น Mission แล้วก็เป็น Task  (แบบหลักการสมัยใหม่เลย)

ผู้นำ  ต้องเตรียม resource ทั้งหมดข้างต้นไว้  ถึงแม้ว่า จะ"ยุ่งยาก" แต่ก็ต้องทำครับ
เป็นหน้าที่ น๊ะครับ - ถ้าคุณไม่ทำ  คนอื่นก็จะไม่ทำเหมือนคุณ
ต้องทำให้  ดูง่ายด้วย  - ถ้าคุณแสดงให้เห็นว่า มันยาก  คนอื่นก็จะบอกว่าขนาดคุณยังทำยากเลย

มาเพิ่มกำลังใจให้ตนเอง
- ถ้าคุณคิดว่า เรื่องพวกนี้ "ยุ่งยาก"  แล้วกับลูก/หลาน ของคุณล่ะ 
  เขาก็มีลักษณะนิสัย เป็นแบบนี้ -  คุณต้องเริ่มเปลี่ยน "ความคิด" แล้วครับ
  จาก "ยุ่งยาก" (ที่คุณคิดไปเอง) เป็นเรื่องที่คุณต้องทำได้ "ปรกติ"

(ลองไปดู  พ่อ,แม่ที่เลี้ยงลูกที่เป็นออทิสติก ... คุณจะรู้ว่าเรื่องยาก "จริงๆ" มันเป็นอย่างไร?)

ถ้าบอกว่า ตัวคนเดียว ลูกผัวไม่มี --- (ก็ไม่ต้องเสียเวลาอ่านน๊ะครับ ...เซ็งเป็ด)


(สำหรับ คนเรียน  และ  สิ่งที่ต้องเตรียมไว้)

- ฟัง :
      จากการเรียน  class แนะนำ S/W, นัดให้ Vendor มา intro
      คัดเลือก VDO ใน YouTube (คนรุ่นใหม่ เก่ง ค้นหา  ก็แสดงฝีมือเลย)
- พูด :
     ใครอ่าน,ฟัง อะไรมา ดีๆ ก็มาสอนต่อกันไป (ทำให้เกิด อาสาสมัคร)
      กำหนด(บังคับให้ทำ) ทีม A ไปดูเรื่อง X   ทีม B ไปดูเรื่อง Y แล้วนำสอน
      Web Board สำหรับสนทนากัน
- อ่าน :
       อ่านทบทวน, เพิ่มเติม (รายละเอียดปลีกย่อย) จาก (เตรียม) หนังสือ, link, Web Board, Blog, ...
- เขียน
      ส่งเขียน สรุป "ย่อ" + "ความเห็น" (บังคับให้ทำ)

จะเห็นว่า ผมได้เพิ่ม วิธีใหม่ที่ร่วมสมัย เข้าไปด้วย
หลายเรื่อง เป็นหน้าที่ของผู้นำ ที่ต้องจัดเตรียมไว้ให้ 
- โดย  ตนเอง หรือ keyman  (ก็ทำได้เหมือนกัน)
- โดย  เตรียม เครื่องมือ (S/w, Tool)  ที่เหมาะสม (ใช้ง่าย,ราคาถูก,...)
- โดย  กำหนด วิธีการ (จัดเก็บแบบ File/Folder, Wiki, ...)

ความแตกต่าง
- เตรียมเอกสาร,file ให้อ่าน 30 ชุด (ไปอ่านกันเอง  แค่เห็นก็หมดกำลังใจแล้ว) 
  ต่างกับ  แนะนำให้อ่าน 8 ชุด (อีก 22 ชุด อ่านเพิ่มก็ดี)
- อ่านเอง 8 ชุด
  ต่างกับ  สอน/อธิบายให้ฟัง 8 ชุด (เห็นจุดที่เน้น/ไม่เน้น ของคนที่อ่านมาก่อน)
- มี คู่มือ แต่ไปหากันเอง
  ต่างกับ  รวมอยู่ใน Folder เดียว/ มี HomePage
- อ่านอะไรก็ได้
  ต่างกับ  จัดเป็นหมวดหมู่, เรียงลำดับ, search ได้ด้วย

สำหรับผู้นำ



ทำให้  การสอน/เรียน ได้สมบูรณ์
ก่อนอื่น คุณ หรือ keyman  ต้องทำนำไปก่อนน๊ะครับ (งานเข้าแล้ว) 
จากนั้น  จึงชี้ทิศทางให้ ทีมงานของคุณ เดินตาม

ผู้นำมักจะต้อง แสดงศักยภาพ  ที่สูงกว่า  ทีมงาน (เขาจะได้เชื่อถือ)
การที่จะทำอะไร เหมือน/พร้อมทีมงาน จึงดูผิดปรกติ (และดูช้า กว่าแน่นอน)

มาเร่ง Speed กันด้วย ลักษณะเฉพาะของ  ผู้นำ  ครับ
- อ่าน โบชัวร์ ได้เร็วกว่า
- ได้ฟัง สัมนา ระดับบริหาร (ใช้เวลาสั้น เน้น keyword)
- จับประเด็น  หลัก  ได้ดีกว่า
- เห็นภาพรวมที่  กว้างกว่า  (รู้ทั้ง H/W, S/W   ทิศทางของบริษัทฯ)


หมายเหตุ  วิธีนี้   มักขัดใจการทำงานของผู้นำหลายคน  เพราะจะรู้สึกว่า ตนเอง ต้องลงมือทำมาก และเสียเวลามากเกินไป   ผู้นำบางคนให้เหตุผลว่า  การโอ๋,สปอย ทีมงานมากเกินไป จะทำให้เสียคน(ทุกคนในทีม ต้องเก่งด้วยตัวเอง)   นั่น...คิดไปโน่น   ถ้าเก่งได้เอง คงเก่งไปนานแล้วล่ะ  ฮาๆๆ