ซึ่งสิ่งนึงที่เริ่มคิดมาได้พักใหญ่ๆ รวมถึงตอนมาประชุมครั้งนี้ ก็คือ “อะไรคือ bread & butter ของการศึกษา” นะ มันคือ QA process management & improvement หรือเปล่า? ซึ่งจะบอกว่าสิ่งเหล่านี้ไม่มีประโยชน์ ก็คงไม่ใช่ แต่ถ้าของที่อยู่ในห้องเรียน (หรือของที่อยู่ตรงหน้าคนเรียน ตอนที่เขาจะเรียน) มันถูกเน้นจะดีไหม

ถ้าเราพยายามจะแบ่ง QA related processes เป็น 2 กลุ่มจะดีไหม 1. processes for compliance to the regulations เอากันให้ตายเลยนะ ใครผิดจับปิดสถาบันเลยละกัน แต่ถ้า ok แล้วก็จบ 2. support processes อันนี้ต้องคิดใหม่นะ โจทย์คือ ทำอย่างไรที่จะให้ bread & butter ของการศึกษามันไปในทิศทางที่ควรไปจริงๆ ชื่อก็บอก กรุณา support นะ คนที่พยายามทำดีๆ ต้อง excel คนห่วยๆ ต้องมีทางพัฒนา

มันจะดีกว่าไหมนะ…..

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

ผบห ถ้าสามารถทำอะไรให้องค์กรมันดีขึ้นได้มันก็ดี ซึ่งงานหลักก็ควรผลักให้ bread & butter ของการศึกษามันดีขึ้น ซึ่งสิ่งนี้น่าจะเป็นสิ่งที่แยก ผบห ดีๆ กับที่มันห่วยๆ ออกจากกันได้เนอะ

Can they (we) make any difference?

เมื่อก่อนที่เรามี maturity ต่ำกว่านี้ #ตอนนี้ก็ไม่ได้บอกว่ามีเยอะแล้วนะ เราก็จะสามารถโทษนั่นโน่นนี่ได้ ทำไมคนนั้น ทำไมหน่วยงานนี้ ทำไมทีมโน้น ทำไมกระบวนการที่เกี่ยวข้อง มันเป็นแบบนี้นะ ทำไมมันแย่ ทำไมมันไม่แคร์นักศึกษา ทำไมมันสนใจว่าน้ำจะท่วม ทำไมมันช้าไม่ทันใจ #พอละอินเนอร์เริ่มมา อย่างไรก็ตามพอทำงานมาระยะหนึ่ง ก็พบว่า “เรา” เหล่านี้ อาจจะต้องการการ blame อะไรบางอย่างเท่านั้นหรือไม่ ในที่สุดเราก็จะสบายใจว่าที่สิ่งที่ควรจะเป็น มันไม่เป็นอย่างที่ควร ก็เป็นเพราะสิ่งรอบตัวหรือไม่ blame เสร็จจักรพงศ์ก็จะสบายใจ แถมหล่อๆ อีกต่างหาก

การที่เดี๋ยวนี้เริ่ม blame สิ่งรอบตัวไม่ค่อยได้ ก็เลยอยากจะเขียนเตือนตัวเองไว้ ว่าเอาจริงๆ ถ้ายังอยากจะทำงานประเภทนี้ต่อ ก็ควรลืมให้ได้หนึ่งอย่าง และจำให้ได้หนึ่งอย่างนะจ๊ะ #หนึ่งลืมหนึ่งจำทำเท่ไปงั้นอย่าหาสาระ #จริงๆเมื่อก่อนตอนนั้นก็ดีนะ

“ลืมซะว่าขอบเขต Scope งานเราคืออะไร และจำให้ได้ว่าถ้าทำงานแล้วมันไม่สำเร็จก็ incapability ความไม่ได้เรื่องของเราเองนั่นแล่ะ”

ประเด็นแรกขอบเขตงาน เราคิดงานบางงาน อาจจะแลดูมีขอบเขตที่ชัดเจน จ้างมาทำบัญชี จ้างมาเขียนแบบ จ้างมาดูแลคน จ้างมาบริหารงาน จ้างมาทำให้ไม่ขาดทุน จ้างมาทำพันธกิจของประเทศ #ถึงตรงนี้อยากเขียนเรื่องอาชีพที่เงินลอยมาจากฟ้าจัง แต่ยิ่งทำงานไปเรื่อยๆ #เหลืออีกยี่สิบปีก็หมดแล้ว ก็เริ่มมาคิดว่า งานที่มีขอบเขตชัดเจน มันมีในโลกไหมนะ จ้างมาเป็นนักวิเคราะห์ต้องทำให้ลูกค้า เออ ช่วยทำ model คำนวณในองค์กรให้หน่อย งานลูกค้าเหรอ เออ ก็ทำต่อแล่ะ จ้างเป็น dev .net ทำๆ ไป เออ คนทำ front-end ไม่พอ รู้นะว่าทำเป็น ช่วยพี่ด้วย ช่วยน้องหน่อย ช่วยกันหน่อยสิ นะนะนะ

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

แต่ถ้าทำแล้วมันไม่สบายใจ ได้ผู้บริหารห่วยๆ มาคนนึง เสียอาจารย์แย่ๆ ไปคนนึงไหม ฮาฮา #ก็ไม่แย่กว่าเดิมมากนะ แทนที่จะบ่นว่าทำไมระบบมันห่วย สิ่งรอบข้างมันห่วย เราก็ควรจะพยายาม “ลืมซะว่าขอบเขต Scope งานเราคืออะไร” ให้ได้ดีกว่าไหม ทำไปซะ จัด priority ให้ได้ หา resource ต่างๆให้ได้ ทำมันให้ได้

แต่ถ้าไม่ไหวจริงๆ ลืมไม่ได้จริงๆ ไม่ต้องบ่นหรอก ออกมาจากจุดนั้นเลยดีกว่าไหม #คนจริงไม่บ่น #คนจริงออกเลย อาจจะดีกับองค์กร ดีกับตัวเองและครอบครัวก็ได้ครับ

จบตรงนี้ก่อนนะ หลังงานใหญ่อาทิตย์นี้ เราจะมาเขียนต่อด้วยประเด็นถัดมา “ถ้าทำงานแล้วมันไม่สำเร็จก็ incapability ความไม่ได้เรื่องของเราเองนั่นแล่ะ” ซึ่งเราว่ามันเกี่ยวข้องกัน (นะจ๊ะ)

คำถาม 4.2b(1) มีอยู่ว่า How do you verify and ensure the quality of organizational data and information? HOW do you manage electronic and other data and information to ensure their accuracy and validity, integrity and reliability, and currency? (ตัวหนาคือเกณฑ์ Overall ตัวปกติคือเกณฑ์ Multiple criteria นะครับ)

เนื่องจากมันอยู่ในหมวด Knowledge Management, Information, and Information Technology องค์กรส่วนนึงก็ต้องโยนไปให้แผนก IT ก่อนเลย เอ้า น้องๆ IT และ Developer ทั้งหลาย องค์กรของเราทำ data & information quality ยังไงนะ ถ้าน้องๆ IT งง ก็ไปได้หลายทาง เช่น อ๋อ เรา back up เป็นประจำครับพี่ #ใช่เหรอ หรือ เราทำ unit test ครับพี่ #ไม่ค่อยแน่ใจนะ

ซึ่งถ้าลองคิดใหม่ อะไรคือ data & information quality? ย้อนไปที่หลักการก่อนเลยละกัน ใน ISO9000:2015 นิยามไว้ดังนี้ Data quality can be defined as the degree to which a set of characteristics of data that fulfills requirements ดังนั้น องค์กรควรจะตีความให้ได้ว่าข้อมูลนั้น Requirements ที่จะ “ต้อง” มีคืออะไร และถ้าย้อนไปอีก ถามว่าทำไมเกณฑ์ถึงถามเรื่องนี้ เหตุผลหนึ่งคือ หนึ่งใน Core values ของเกณฑ์คือ Management by fact ครับ ลองดูคำอธิบาย

“Management by fact requires you to measure and analyze your organization’s performance, both inside the organization and in your competitive environment. Measurements should derive from business needs and strategy, and they should provide critical data and information about key processes, outputs, results, outcomes, and competitor and industry performance.”

ชัดเจนว่า Requirements มาจากฝั่ง Business แน่ๆ เราต้องมีระบบ IT เพราะ Business ที่เราทำอยู่ มันจำเป็นต้องมีระบบ IT เราต้องมี data & information เหล่านั้น เพราะ Business ที่เราทำอยู่ มันจำเป็นต้องมีข้อมูลและสารสนเทศเหล่านั้น

พอองค์กรเอาข้อมูลไปใช้เยอะๆ แน่นอน องค์กรก็มีโอกาสจะดีขึ้นด้วย Management by fact และด้วย Maturity ขององค์กร (ในระดับนี้) เราจะเริ่มมองต่อเองว่าตกลงไอ้ข้อมูลที่เราเอามาใช้ Manage มันคือ Fact หรือเปล่า และในที่สุดเราก็จะเริ่มพูดถึง Data & information quality เอง (มั้ง)

<<แม้ว่าองค์กรควรจะเคลียร์กันเองให้ได้ก่อนว่าข้อมูลที่สำคัญขององค์กรคืออะไรบ้าง แล้วค่อยมาพิจารณา Data quality แต่ Post นี้สมมุติว่าองค์กรเค้ารู้แล้วว่าข้อมูลที่สำคัญขององค์กรอยู่ไหนละกันเนอะ>>

กลับมาที่หลักการของ Data quality ต่อละกัน ใน ISO9000:2015 มีมิติที่อาจเป็นตัวอย่างในการพิจารณาได้ คือ Completeness, Validity, Accuracy, Consistency, Availability และ Timeliness ลองค่อยๆ ไปทีละตัวตามความเข้าใจของผมละกันครับ

Completeness ถามง่ายที่สุด เรารู้ได้อย่างไรว่าข้อมูลนี้สมบูรณ์แล้ว ถ้าคิดว่ากระบวนการ CRM ทางโทรศัพท์สำคัญ เราจะรู้ได้อย่างไรว่าเบอร์โทรของลูกค้าครบถ้วนทุกดิจิต ไม่ยากใช่ไหมครับ ถ้าคิดถึงระบบงบประมาณล่ะ ทำไมไตรมาสนี้เงินหายไป 5 ล้านกว่าบาท (เหตุการณ์สมมุติ ฮาาา) จะรู้ได้ยังไงว่าเงินบางอย่างมันมาช้า ทำให้ข้อมูลที่กำลังจะรายงานมันไม่สมบูรณ์

Accuracy กับ Validity ข้อมูลที่เก็บแม่นยำเป็นไปตามตรรกะแค่ไหน องค์กรที่มีประเด็นสิ่งแวดล้อมก็อาจจะดูว่า Sensor ต่างๆ ทำงานเป็นอย่างไร ส่งข้อมูลมาถูกไหม รู้ได้อย่างไร ส่วนตรรกะของข้อมูลนึกถึงพวก Range Check ง่ายสุด กรอกปีเกิดของนักเรียนป.ตรี 1965? กรอกเงินเดือนของพนักงานทำความสะอาด 30,000 บาท จะรู้ได้ยังไงว่ามันเป็นช่วงที่ดูสมเหตุสมผล

Consistency บางองค์กร อาจมีปฏิทินหลายชุด ข้อมูลบางชุดใช้รายปีงบประมาณ บางชุดใช้ปีปฏิทิน จะทำอย่างไรในการจัดการ

Availability ตอนที่ต้องการข้อมูล ข้อมูลมีไหม และมาตรงเวลา และตามเวลาที่ควรมาไหม — Timeliness

ถ้าลองคิดดีๆ มันไม่ใช่เรื่องของฝั่ง IT ทั้งหมด Senior Leaders มีหน้าที่ออกแบบกระบวนการที่เกี่ยวข้องกับข้อมูล คิดให้ดี คิดให้จบ เอาเฉพาะข้อมูลหลักๆ (ที่จำเป็นกับความเป็นความตายขององค์กร — ชอบจังคำนี้) ก่อนก็ได้ แล้ว IT จะมาสนับสนุนได้เอง ลองคิดถึงองค์กรในฝันที่อาจเป็นลูกผสมระหว่าง electronic data และ traditional data (paper-based) วันนึงก็อยากจะตอบคำถามของเกณฑ์ให้ได้แบบนี้จัง #สักวันนะ #สู้ต่อไป

From the data governing in the 4.1a(1) section, there are two kinds of important data and information for FoE, i.e. strategic key result (SKR) and key process performance result (KPPR). All SKRs are collected, stored, and processed by IT systems. The accuracy, validity, and completeness of such results can be ensured by such semi-automated processes (automatically check, manually correct) in the IT systems e.g. range checks or sampling to find errors are enforced end-to-end (from the collection points to usage points) when the related processes are designed. For the KPPRs, the data usually are collected, processed, and utilized by employees, then the data are inputted into the IT system for the process performance review yearly (as mentioned in 4.1b). Thus, the accuracy, completeness, consistency and validity of the data are ensured by sampling check-sheets for all key processes (e.g. Figure x). For the timeliness, the process specification as explained in 6.1a(1) can help ensuring the issue.

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

และแล้วเมื่อวานก็มีคนมาแซะในคำถามเดิมๆ ว่า “ทำไมผมและทีมไม่ตอบคำถามของ Framework เอง ไปให้ Leader ของทีมอื่นในองค์กรตอบทำไม”

……. *ฟังแล้วก็ขอหายใจเข้าและออกให้ใจสงบก่อนนะ* ……

ก็คงต้องตอบประโยคเดิมไปว่า “ประเด็นมันไม่ได้อยู่ที่การตอบคำถามออกมาเป็นรายงานไงครับ” ประเด็นมันอยู่ที่การกระตุ้นต่อมให้ท่านผู้ซึ่ง “มีส่วนรับผิดชอบต่อความเป็นความตายขององค์กร” มาคิดซักนิด ปีละครั้งก็ยังดี ว่าสิ่งที่เราทำ ทำไมเราต้องทำมัน เราทำอย่างไร เรารู้ได้อย่างไรว่ามันดีพอหรือยัง ซึ่งถ้าเราคิดไม่ออก ตอบไม่ค่อยอยู่กับร่องกับรอย อาจแสดงว่า…..​ ตอนทำไม่ได้คิดนี่หว่า แล้วสิ่งที่คุณทำมันจะดีไหม และองค์กรมันจะเดินหน้าไปในทางที่คุณเองอยากให้ไปได้ยังไง?

แล้วก็เลยมาคิดถึงหนึ่งในประโยควรรคทองหนึ่งของ อ.ป้า สมัยที่ไปเรียน “Writing is a very important intellectual tool, if you can’t think [clearly], you can’t write [and vice versa]” จำได้ว่าโดนแกสวดยกใหญ่ด้วยหัวข้อนี้ในช่วงแรกๆ ของการเรียน เพราะมนุษย์วิศวะจ้องแต่จะ Code มันอย่างเดียว ฮาฮาฮา ผ่านมา…. 10 ปี (ไวจัง) ชีวิตเริ่มได้ลองทำโน่นทำนี่มากขึ้น ก็ซึ้งกับประโยคนี้มากขึ้นเรื่อยๆ

เขียน-อ่าน-คิด-เขียน-อ่าน-คิด วนไปนะ เราน่าจะค่อยๆ รู้เองว่าไอ้ที่เขียนตามจริง มันตอบคำถาม what why how ได้ดีแค่ไหน ผมเชื่อว่ามันน่าจะกระตุ้นต่อม “what if” เองในที่สุด ไม่ว่าจะเป็นเรื่องทำงาน เรื่องวิจัย การเรียน มันน่าจะเป็น universal tool ในระดับนึงครับ ในส่วนของ *** ทำท่ายืนพริตตี้ *** การทำงานของตัวเองในปัจจุบัน ก็คงจะต้องพยายามใจเย็นๆ ตะล่อมคนให้เห็นดีเห็นงามตามนี้ไปเรื่อยๆ ซักวันก็น่าจะดีขึ้น ทั้งองค์กร และทั้งความใจเย็นปล่อยวางได้ของตัวเอง จึงอยากบันทึกเตือนตัวเองไว้ ณ ที่นี้

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

เลยลองมาคิดใหม่ (ยังไม่ค่อยตกผลึกนะ) อีก 10–20 ปีข้างหน้า มันน่าจะเป็นช่วงสุดท้ายในการทำงานของเรา “เราอยากให้คนพูดถึงเราแบบไหน เราก็ (พยายาม) tailor made ชีวิตเรา แบบนั้น” ดีไหม ไม่งั้นมันก็จะเป็น lost years เหมือนเดิม

ดังนั้น เพื่อให้ concrete กับตัวเองอีกนิด ลองสรุปแบบนี้

1. จะพยายามเลิกบ่นเรื่องงานบริหาร เรา “เลือก” เข้ามาทำเอง ต้องพยายามคิดไว้ มันมีเวลาจำกัด เราอาจจะไม่มีโอกาสได้ลองทำสิ่งนี้อีกแล้วก็ได้ ดังนั้น เลิกบ่น
2. งานที่มีอยู่เดิม จัดลำดับดีๆ เอาความสำคัญเข้ามาผสมกับ deadline บ้าง
3. งานใหม่ที่จะรับ ถามตัวเองดีๆ ว่าอยากทำไหม ทำได้ไหม และ Outcome คืออะไร เราคือคนที่เหมาะจะทำไหม เรา deliver สิ่งนั้นได้หรือไม่ (พอคิดแบบนี้ งานนึงที่โดนจิกให้ทำอยู่ เราก็ไม่อยากทำ เราก็ไม่คิดว่าเราจะ deliver ได้ เลิกทำ โทรไปขอโทษขอโพยเค้าว่าคิดนาน ลากยาวไปหน่อย จบ ตัดไปงาน สบายใจ)
4. พยายามยิ้มให้มากขึ้น at the end of the day ครอบครัว ตัวเอง สำคัญที่สุด เราอาจจะใช้ชีวิตมาเกินครึ่งแล้วก็ได้นะ ที่เหลือก็มีความสุขกันหน่อยเนอะ

เมื่อวานนั่งคุยกับ อ.Ishihara จาก Kyoto U
พอประชุมสรุปเรื่อง นศ.ฝึกงานเสร็จ (ซะที ดีใจจังเลยยยย) ก็เริ่มสัปเพเหระกัน

แกเล่าให้ฟังว่า ม.แก กำลังจะปรับโครงสร้างอีกรอบให้มีระบบ Faculty

เดิมทีม.เค้าปรับมาทีละ แยก Grad School ออกจาก School (Faculty เดิม) เพราะแนวคิดไม่เหมือนกัน
Grad School เน้นวิจัย + หลักสูตร Post Grad
คนรักการสอนแบบสอนลูกไก่ก็ไปสังกัด School
ดังนั้น Grad School กับ School มี Dean คนละคนกัน แนวคิด เป้าประสงค์คนละชุด
เวลาคนทำงานก็ใช้ระบบ Double Appointment ไป หนึ่งคนสังกัดที่เดียว แต่สอนสองที่
อย่างตัว อ. Ishihara สังกัด Grad School แต่ก็ไปสอนใน School ด้วย
เวลาประเมินก็เอาของที่ Double Appointment ไป มาว่ากัน
ซึ่ง % ของการทำงานแต่ละส่วนก็ปรับเปลี่ยนได้ แต่สนง. ตรงกลางคุม Port ขอให้ทุกส่วนทำงานของตัวเองได้

รอบนี้ Kyoto จะเอาระบบ Faculty เหมือนของ……ไม่รู้ที่ไหน (เคยเห็นใน UK/Australia) มาใช้
โจทย์คือบาง School หรือ Grad School เล็กเกินไปที่จะดูแล HR&Infrastructure
เค้าก็เอาคน (สาย Support) และของต่างๆ มารวมกัน เพื่อให้ได้ Economy of Scale
โดยเป้าคือ ทำยังไงให้สาย Academic มีเวลาทำการสอนให้ดีขึ้น มีเวลาทำวิจัยให้งานมันดีขึ้น

ผมว่าน่าสนใจนะครับ

ส่วนตัว”เชื่อ”อยู่แล้วว่าโลกการศึกษายุคใหม่ (post post modern world ;))
ม.ที่มี cluster ภายในเล็กๆ มีกลุ่มคนที่คุยกันรู้เรื่องในแง่วิชาการ จะบริหารจัดการวิชาการได้ดีกว่าอยู่แล้ว
แต่พอมาทำงานบริหาร ก็พอนึกออกว่า scale ที่เล็กไป มันจะตายเอา เงิน ของ คน น้อยไปหมด (ไม่นับปัญหาคนบ่น….เพื่อที่จะไม่ทำอะไร)

อ.แกบอกว่ากว่าจะปรับเสร็จ คง 2–3 ปีแล่ะ แต่ก็ต้องทำ ไม่งั้นแข่งขันไม่ได้
จะว่าไปมันเป็นโจทย์ที่ยากนะครับ ฟังจากที่แกเล่า
มันไม่ใช่ trade-off สองขาแบบ… ยอมเสียเวลาถอยหนึ่งก้าวเพื่อเดินหน้าสองก้าว
แต่มันต้องเป็น ไม่ยอมถอยแม้แต่ก้าวเดียว แค่ (บางคน) เดินช้าลงนิดนึง (ไอ่คนเดินได้ก็เดินต่อ) เพื่อจะเดินหน้าสองก้าวต่างหาก

งานบริหารนี่…นั่งมองสนุกดีนะครับ แต่ตอนทำเองนี่….ก็สนุกไปอีกแบบ ฮาาาา

ว่าแล้วก็ปั่นเอกสารประชุม edpex & ถอดแผน ต่อดีกว่า ^^

วันก่อนคุยกับนาย ได้ analogue คำนี้มา เข้าใจง่ายดี

หลายๆ ครั้ง มีคนอธิบายว่ายุทธศาสตร์ต้องไปทางไหนอย่างไร สิ่งที่มักจะถูกยกขึ้นมาคุยกันคือ เป้าไปไหน จะสำเร็จเมื่อไหร่ ถอดออกมาเป็น Action Plan เป็นยังไง เป้า Casecade ยังไงจากบนสู่ล่าง จากล่างสู่บน ค่าฐานเป็นยังไง Gap อยู่ตรงไหน Key change ที่จำเป็นอยู่ไหน

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

ประเด็น ไม่มุ่งทางเดียวกัน (ขาด engagement) ไม่เข้าใจ มันน่าจะบรรเทาได้ด้วย การสื่อสาร ต้องทำให้เห็นภาพ จัด information (ที่ insightful) เข้าไป ทำให้เห็น reasoning เดียวกันให้ได้ ทำให้เห็นจุดพัก จุดเช็คทั้งหลายในการเดินเรือ เตรียมเวลาเรือเข้า pit stop (แผนไม่ตามเป้าทั้งเป้าบนสุดและเป้าล่างสุด) ไว้ ว่าจะทำยังไง ถ้าคนเห็นจุดเล็กๆ เหล่านี้เหมือนกัน น่าจะมีโอกาสสำเร็จมากขึ้นนะครับ เหมือนเราจะออกเรือไปด้วยกัน แล้วรู้หมดว่าจะเกิดอะไรขึ้นในแต่ละจุด จะต้องทำอะไรในแต่ละจุด เหมือนเราเห็น course ทั้งหมดในการร่วมลงเรือไปด้วยกัน

ยังไงซะ ก็โคตรโดนใจกับคำพูดของ TQA Coach “2.2 สำคัญกว่า 2.1” แหะๆ แปลได้ว่า แผนปฏิบัติการของยุทธศาสตร์ สำคัญกว่าการได้มาซึ่งยุทธศาสตร์ เพราะส่วนใหญ่ ยุทธศาสตร์ซึ่งเป็นคำใหญ่ๆ มันดีแล่ะ ถ้าทำได้จริง

สู้ต่อไป ทำเพื่อประเทศชาติ make a difference!