ร้องเพลง รอ

ร้องเพลงรอ

(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