แบกก็หนัก วางซะเถอะ

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

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

จะยุ่งไปไหน พักบริหารเวลาเดี๋ยวนึงสิ

 สวัสดีค่ะ

คราวนี้แอบเก็บ คำถามคำตอบของอดีตเพื่อนร่วมงาน และอดีตคุณครู ที่ถามตอบไปมาใน Facebook มาเล่าให้ฟัง

คุณเพื่อนถามว่า งานยุ้งยุ่ง ทำไงดี คนโน้นก็จะเอา คนนี้ก็จะเอา ไม่รู้จะเริ่มทำยังไงก่อน

คุณครูผู้อารี ตอบว่า ให้จัดลำดับความสำคัญของแต่ละงาน โดยดูจาก ผลกระทบที่เกิดขึ้น งานใดพบว่ามีผลกระทบมาก คือสำคัญมาก ให้เริ่มทำก่อน

เหมือนจะเป็นสถานการณ์ ที่ชาว IT โดยเฉพาะ สายสนับสนุน พบเจอกันประจำ คือ วันไหนอะไรจะเสีย ก็จะมาเสียพร้อมกัน ไม่ให้เราได้ตั้งตัว  ส่วนคำตอบก็เหมือนเป็นเรื่องที่เรารู้กันดี คือทำเรื่องสำคัญก่อน

ความยากอยู่ตรง ที่ว่าสำคัญหรือส่งผลกระทบมากเนี่ยวัดด้วยอะไร เช่น ถ้าเทียบงาน link ของสำนักงานสาขา ล่ม กับ ผู้บริหารระดับสูง ใช้งานระบบ e-mail ไม่ได้ เนี่ย  อะไรสำคัญ หรือส่งผลกระทบมากกว่ากัน

ถ้ามองว่าเกิดผลกระทบกับตัวเรา เราคงวิ่งไป support ผู้บริหารก่อน เพราะช้าไปอาจจะโดนด่าได้

ถ้ามองว่าเกิดผลกระทบกับผู้ใช้ เราคงวิ่งไปกู้ link สาขาก่อน เพราะ ผู้ใช้งานที่สาขา มีจำนวนมากกว่า

แล้วถ้ามองว่าผลกระทบต่อองค์กรล่ะ

ผู้ใช้งานที่สาขา อาจจะส่งรับเมล์ หรือ application online ไม่ได้ ทำงาน off line ได้ งานของสาขาคือ trancsaction process หรือ day to day operation

ในขณะที่ผู้บริหาร ทำงานตัดสินใจ บริหาร สั่งการ การรับส่ง e-mail ไม่ได้  ถือว่าช่องทางการสื่อสารในการตัดสินใจ บริหาร สั่งการ หายไป 1 ช่องทาง  และปัจจุบันก็ดูจะเป็นการสื่อสารช่องทางหลักในหลาย ๆ หน่วยงานไปแล้ว การใช้ e-mail ไม่ได้ ของผู้บริหาร อาจจะทำให้การสั่งการ หรือรับทราบข้อมูลสำคัญล่าช้า และส่งผลกระทบไปยังหน่วยงานภายใต้ของผู้บริหารท่านนั้นทั้งหมด


นอกจากการเรียงลำดับผลกระทบแล้ว หลักการบริหารเวลา มีอีกหลายเจ้า ที่เป็นที่รู้จักคือ Time Quadrant หรือ First thing first habit ของ Stephen Covey ที่แบ่งกิจกรรมเป็น 4 ประเภท คือ ด่วน และสำคัญ (Q1) , ไม่ด่วน แต่สำคัญ (Q2) , ไม่สำคัญแต่ด่วน (Q3) , ไม่ด่วนและไม่สำคัญ (Q4)


กิจกรรมใน Q2 ที่ไม่ด่วนแต่สำคัญนั้น หากละเลยไม่ดำเนินการ ไม่นานก็จะกลายเป็น Q1 ขึ้นมาให้เราร้อนตัวได้ ดังนั้น การพิจารณาผลกระทบ จึงอาจมองใน 3 ด้านคือ ความสำคัญ  ความเร่งด่วน และ การลุกลาม (seriousness, urgency and growth - SUG) ด้วย 

รายละเอียดเพิ่มเติมหาค้นหาจาก Key word : Covey's Time Management Quadrants  และ Kepner-Tregoe Situation Appraisal


ขอบคุณทุก ๆ สุนทรียสนทนาบน เครือข่าย

Determining Assets in IT Risk Assessment.

Original posted on 28 May 2010 13:41 by sripattra  

 

Today IT Risk is not only concerned with IT equipment but involves the  whole business operation. The IT system administrator should explore the whole organization to determine what the real IT Asset of the organization is.

The continuity of business operation should be considered for risk assessment and the IT administrator should analyze which systems require recovery within 15 minutes, 4 hours or 2 weeks for low impact systems.

The payroll system in a medical research institute is not an important part of the
business risk but it is a very critical system for a HR professional outsource company.

In a 200 seat restaurant the computer system which automatically sends the order from the waiter at the table to the kitchen can wait a few days for recovery, because the waiter can send the order manually. But in a food court that uses a cash card system, if the system breaks during the daily operation recovery must be within one hour because the cash card must be refunded to the customer.

Therefore, the first step of IT Risk assessment is identifying the IT asset to be able to appropriately manage the risk.
-------------------------------------------------------------------------------
Reference:
George Westerman & Richard Hunter , “IT Risk” , Harvard  business school press, 2007.
TIS 22300 , TIS 18000, www. tisi. go. th
--------------------------------------------------------------------------------
Thank you Aj. John for review and advise

ใช้กะปิ (KPI) อะไร ๆ ก็วัดได้หมด จริงดิ?

 

 นั่งเตรียมส่วนผสม ทำกะปิไปได้ครึ่งนึงแล้ว (KRA - Key Result Area) รู้แล้วว่าเป้าหมายของงานคืออะไร มาถึงตอนสำคัญ คือจะวัดด้วยอะไร จึงจะรู้ว่าได้ผลดีจริงอย่างที่โม้ไว้

ถ้าเป็นเรื่องที่เกี่ยวกับเงิน ๆ ทอง ๆ อย่างที่พวก ฝ่ายขายเค้าต้องทำยอดขายกัน อันนั้นง่ายมากแค่เอายอดขาย target มาใส่ scale ไล่ระดับกันไปก็จบ ส่วนของพวกเราชาว IT ถ้าไม่ได้อยู่ในส่วนที่สร้างรายได้ ก็มักจะถูกวัดด้วยการให้ลดค่าใช้จ่าย ก็ไม่ยากอีก เอาค่าใช้จ่ายที่ลดได้มาวัดก็น่าจะได้เช่นกัน เช่น โดนให้ตั้งเป้าลดค่าใช้จ่าย อย่างใดอย่างหนึ่ง โดยเมื่อพิจารณาแล้วไม่กระทบกับคุณภาพในการให้บริการ เช่น ลดค่าโทรศัพท์ ลดค่าถ่ายเอกสาร ให้ใช้้การส่ง e-mail หรือ ยกเิลิกการพิมพ์รายงานการประชุม ใช้ดูทางจอภาพแทนแบบนี้ง่ายมาก สิ้นรอบ ก็มาสรุปค่าใช้จ่ายเทียบกับปีก่อนว่าลดไปเท่าไหร่ก็เป็นอันเสร็จสิ้น


การลดค่าใช้จ่ายด้วยโครงการ IT  ในการทำโครงการ มักมีความคาดหวังอยู่แล้วว่าจะช่วยให้เกิดการประหยัดบางอย่างได้ เช่น  การนำระบบ RFID มาใช้ในการจัดการคลังสินค้า จะช่วยลดการใช้พนักงานในการตรวจนับจำนวนสินค้า คิดเป็นค่าจ้างรายชั่วโมงได้เท่ากับ xxx ก็ให้นำค่านี้มาใส่ที่ระดับ 3-Target หากทำได้มากกว่า ก็จะเป็นระดับที่มากขึ้นเป็นต้น

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

ดังนั้นส่วนที่จะทำการวัดในโครงการลักษณะแบบนี้ คือการวัดผลเชิงประสิทธิภาพ ซึ่ง ยังต้อง Measuable อยู่ เช่น เมื่อเราบอกว่าระบบจะช่วยให้ sales ตรวจสอบประวัติลูกค้าได้ละเอียดยิบย้อนหลังไปตั้งแต่เริ่มรู้จักกันได้อย่างง่ายดาย หมายถึง ระบบสามารถออกรายงานประวัติการติดต่อกับลูกค้าได้ครบถ้วน ทุกครั้งที่มีการเรียกดูรายงาน เราไม่สามารถวัด "ทุกครั้ง" ที่มีการเรียกดูรายงาน ได้ แต่ในทางตรงข้าม หากระบบไม่สามารถดูได้อย่างครบถ้วน และมีการแจ้งปัญหา ก็จะสามารถนับได้ ดังนั้น ตัววัดจึงน่าจะเป็น "จำนวนครั้งที่รายงานผิดพลาด ไม่ครบถ้วน หรือ เรียกดูไม่ได้" ซึ่งแน่นอนว่าค่าที่เป็นไปได้ ที่ดีที่สุดคือ 0 = ระดับ 5-ยอดเยี่ยม  และ จำนวนครั้งที่เพิ่มขึ้น หมายถึงประสิทธิภาพของระบบ ที่ลดลงนั่นเอง

ทำกะปิ (KPI) ให้ S.M.A.R.T กันเถอะ

หลายคนคงเคยผ่านหูผ่านตา หลักการตั้งเป้าหมาย ให้ S.M.A.R.T กันมาบ้างแล้ว และจะว่าไป KPI ก็เป็นการตั้งเป้าหมายอย่างหนึ่งการนำหลักการเดียวกันมาใช้น่าจะเป็นแนวทางในการทำ KPI ก็น่าจะได้เช่นกัน

S.M.A.R.T นั้นเป็นหลักในการตรวจสอบการตั้ง Objective ซึ่งหาก search ดูจะพบอยู่เพียบเลยค่ะ แม้จะใช้คำต่างกันบ้าง แต่ก็มีความหมายคล้าย ๆ กันนะคะ ถนัดใช้คำไหนก็เลือกจำตามสะดวกเลยค่ะ
ขอยกตัวอย่างจาก KPI ในครั้งที่แล้ว ที่เราจะวัดการให้บริการอย่างต่อเนื่องของระบบ ด้วยเวลา downtime สะสมภายใน 1 ปี
เมื่อนำ SMARTER มาตรวจสอบว่า KPI นี้ใช้ได้หรือไม่

S - Specific - การระบุให้ชัดเจน เข้าใจได้ตรงกันเป็นสิ่งเดียว ไม่คลุมเครือ

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

M - Measurable - สามารถวัดได้ ซึ่งให้ดีที่สุดคือออกมาเป็นตัวเลขได้ ในกรณีนี้สามารถนับเป็นตัวเลข (เวลาสะสม) ได้

A - Agreed - ความเห็นชอบจากผู้เกี่ยวข้อง คือการยอมรับเป้าหมายจากทุกฝ่าย ทั้งผู้ตั้งและผู้นำไปปฎิบัติ รวมทั้งผู้ที่ได้รับผลกระทบ หรือผู้มีส่วนได้ส่วนเสีย ทั้งตัว admin เอง ผู้ใช้งานระบบ และผู้บังคับบัญชา เห็นด้วยกับระดับคะแนนหรือไม่ ในการจัดทำ KPI จึงต้องมีการนำเสนอ ให้หน่วยงานอื่น ๆ ในองค์กรได้ทราบและลงความเห็นชอบเพื่อนำไปสู่การอนุมัติด้วย

R - Realistic - สามารถทำได้จริง โดยพิจารณาทั้งจาก ความเป็นไปได้ , ช่วงเวลา และ ทรัพยากร ที่จะจัดสรรให้ ซึ่งหากพบว่าปีที่ผ่านมามีค่าแตกต่างกันมาก เช่น Downtime สะสมเกินกว่า 2 สัปดาห์ การตั้งระดับคะแนนเป้าหมายที่ downtime ไม่เกิน 3 วันอาจเป็นไปไม่ได้

T - Time framed - มีการระบุกรอบของเวลาชัดเจน ในที่นี้ระบุว่าการนับเวลา downtime เป็นการนับเวลาสะสมภายใน 1 ปี

อีก 2 ข้อซึ่งแนะนำให้ตรวจสอบ เวลาตั้ง KPI คือ Evidence สามารถตรวจสอบผลลัพธ์ ได้ เช่นการมีบันทึก หรือรายงาน และ Review  คือมีการตรวจสอบสม่ำเสมอ รวมแล้วก็จะเป็น SMARTER (พอเรียงเป็นคำก็ช่วยให้จำง่ายขึ้น)

Evidence - ในการหยุดให้บริการแต่ละครั้งนั้นมีการบันทึกช่วงเวลาที่ใช้ในการกู้คืนระบบหรือไม่ ซึ่งในการทำงานอาจจะมีระบบ Helpdesk ที่ใช้บันทึกช่วงเวลาตั้งแต่ server down ไปจนถึงช่วงที่สามารถกลับมาใช้งานได้ แต่หากไม่มีการบันทึกมาก่อน อาจจะต้องเริ่มบันทึก เพื่อใช้เป็นหลักฐานในการประเมิน

Review - ในช่วงเวลา 1 ปี จัดให้มีการรายงานช่วงเวลา Downtime สะสมทุกๆ เดือน เพื่อให้ทราบสถานะ เช่นหากพบว่าแค่เดือน มกราคมเดือนเดียว ก็มี downtime สะสมกว่า 1 วันแล้ว ช่วงเวลาที่เหลืออีก 11 เดือน จะทำอย่างไรให้ ระบบสามารถใช้งานได้อย่างต่อเนื่อง ซึ่งน่าจะดีกว่า การรายงานครั้งเดียวเมื่อจะทำการประเมิน

แค่นี้การตั้งค่า KPI ก็ดูจะไม่ยากแล้วล่ะ คราวหน้าลองมาเจาะลึกตัว M - Measurable กันอีกนิด (หลาย ๆ คนคงเคยเจอว่ามีบางอย่างที่ไม่สามารถวัดเป็นตัวเลขได้ไปใช่ไม๊ )

ส่วนผสมของ KPI

 

ขั้นตอนต่อไปของการสร้าง KPI เมื่อรู้แนวทางว่า KPI ของเราจะมุ่งไปทางไหนโดยดูจาก KPI ของหน่วยงานระดับที่ใหญ่กว่าเรา หรือ ถ้าเป็นระดับองค์กรก็หันไปดู Mission Vision Goa etc... (ปล่อยให้เป็นหน้าที่ของผู้บริหารไปละกัน)
รูปแบบของ KPI ของแต่ละที่ไม่เคยเห็นจะเหมือนกันซักที่เดียว แล้วแต่การตีความ หรือแล้วแต่ต้นฉบับเป็นเจ้าไหน (ที่ปรึกษาให้อะไรมาก็อันนั้นแหละ) หลัก ๆ มักจะประกอบด้วย
- KRA - Key Result Area หรือ ผลที่เราต้องการ เช่นในระดับองค์กร มี KPI ด้านการปฎิบัติงานให้มีประสิทธิภาพ แผนก IT ก็ขานรับด้วยการอยากให้ Server ทำงานดี ๆ ไม่งอแง เรียกใช้เมื่อไหร่ก็ได้ใช้เมื่อนั้น  อาจจะเขียนว่า มีการดูแลระบบให้สามารถทำงานได้อย่างต่อเนื่อง ตอบสนองต่อการใช้งานขององค์กร เป็นต้น
 - KPI - Index หรือตัววัด ซึ่งต้องตั้งคำถามว่า สิ่งที่เราจะวัดนั้น สามารถบอกได้ถึงความสำเร็จ หรือผลลัพท์ที่เราต้องการจริงหรือไม่ จาก KRA ข้างต้น หากเราวัดด้วย จำนวนครั้งที่ Server ไม่สามารถใช้งานได้ อาจจะไม่สะท้อนความต่อเนื่อง ได้เท่ากับ ช่วงเวลาที่ Server ไม่สามารถใช้งานได้ (สมมติว่า Serve เปิดใช้งาน 24 ชม.)
คือ server อาจจะมีปัญหา 10 ครั้ง แต่ทุกครั้งสามารถแก้ไขได้ภายใน 5 นาที เทียบกับ การเกิดปัญหาครั้งเดียวแต่ไม่สามารถใช้งานได้ไป 3 วัน กรณีหลังนั้น ส่งผลกระทบรุนแรงกว่า
 
- KPI score หรือ ระดับคะแนน หรือเกรด ที่องค์กรตกลงกันซึ่งต้องเหมือนกันทั้งองค์กรคือ ถ้าใช้แบบ 5 ระดับ ทุกหน่วยงานก็ต้องทำเป็น 5 ระดับทั้งหมด ไม่งั้นจะเปรียบเทียบกันไม่ได้ โดยมากจะเป็นประมาณนี้

• ระดับ 0 คือไม่ได้คะแนน แย่สุด ๆ ไม่ได้ทำงานเลยมั้งเนี่ย เช่น ปล่อยให้ server down สะสมเกินกว่า 1 สัปดาห์ หรือ 7 วันทำการ
• ระดับ 1 ต้องปรับปรุง ยังพออภัย แต่คราวหน้าอย่าให้เห็นอีกนะ 
• ระดับ 2 หากเป็นสิ่งที่เคยทำแล้ว ระดับนี้จะเป็น Base line เช่น downtime สะสมปีก่อนทำได้ ที่ 5 วัน หรือถ้าไม่มีมาก่อน ก็ใช้การคำนวนกลับจากค่าความคาดหวังลดลงมา
• ระดับ 3 เป้าหมายที่คาดหวัง ซึ่งจะต้องท้าทายกว่า Baseline เช่นกรณี Downtime ไม่เกิน 1%  คิดต่อปีก็คือ  3.65 วัน
• ระดับ 4 เกินความคาดหวังมาหน่อยนึง ยอดไปเรย อาจจะเพิ่มขึ้นมาเป็น downtime สะสม ไม่เกิน .5%  ต่อปี ก็ประมาณ 1.5 วัน
• ระดับ 5 เทพมาก ๆ ไม่มี Downtime เลย เป็นต้น

หลาย ๆ กรณีที่ มักจะนำค่าความคาดหวัง หรือกระทั่ง Baseline ไปใส่ไว้ที่ระดับ 5 มันก็ง่ายดีอยู่ แต่จะทำให้ไม่มีความท้าทาย และไม่พัฒนา เว้นแต่ว่าปีก่อนก็ทำได้สุดยอดอยู่แล้ว นั่งเฝ้าไม่ให้ server down ซักวันเดียว ปีถัดไปจะคง scale เดิมไว้ก็ไม่เสียหาย เมื่อตกลงปลงใจได้แล้วก็เอามาใส่ตารางหน้าตาน่าจะออกมาคล้าย ๆ แบบนี้ (แต่ละองค์กรไม่เหมือนกันนะจ๊ะ ย้ำอีกที)



 ยกตัวอย่างการวัดผลซะยาว จะเห็นว่า KPI นั้นต้องเป็นสิ่งที่วัดได้เป็นตัวเลข เห็นกันจะจะ ไม่คลุมเครือ เมื่อมีการวัดผล ตัวเลขอันศักดิ์สิทธิ์นี้ก็จะทำให้ยอมรับกันทั้งผู้วัด และผู้ถูกวัด ดังนั้น การจะนำอะไรมาเป็นไม้บรรทัดวัด KPI นั้นจึงสำคัญมาก คราวหน้ามาต่อกันด้วย S. M. A. R. T.  หลักการเก่า ๆ ที่ใช้ได้เสมอ

KPI ของเราทำมาจากอะไร

 

 
Key Performance Indicator หรือ KPI ที่แม้จะผิดหลักการแปลงภาษาไปหน่อย แต่ขออ่านว่า กะปิ นะคะ

วันก่อนมีคนใกล้ตัว ที่เป็นชาว IT เหมือนกันบ่นให้ฟังว่าต้องทำ KPI อีกแล้ว ไม่รู้จะเขียนยังไง เขียนเป็น pseudo code ไม่รู้ฝ่ายบุคคลจะเก็ทไม๊ (มีแนวโน้มว่าไม่นะ ^_^''' )

ได้ฟังแบบนั้นเลยให้ไปถามลูกพี่ อีกทีว่าพี่มี KPI เป็นของตัวเองหรือยัง ถ้ามีแล้วช่วยแจกมาให้ด้วย ถ้าลูกพี่ไม่มี ก็ฝากลูกพี่ไปถามลูกพี่ของลูกพี่ก่อน แล้วค่อยมาคุยกันอีกที

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

หากหน่วยงานใด นั่งเทียนเขียน KPI เอง โดยไม่ดูเป้าหมายหลักขององค์กร อาจเกิดปรากฎการณ์ที่หน่วยงาน ประสพความสำเร็จ ทำงานทะลุเป้า แต่องค์กรไม่ทะลุ หรืออาจจะได้ผลตรงข้ามก็เป็นได้ เช่น หน่วยงานอยากพัฒนาบุคลากรให้ได้ cert มันครบทุก ภาษา ( Java , Phython , Ruby ...) แต่องค์กรรับพัฒนาระบบด้วย Java อย่างเดียว cert. อื่น ๆ ก็ไม่มีผล แม้หน่วยงานจะบรรลุ แต่องค์กรไม่ได้รับผลประโยชน์ไปด้วย หรืออาจจะเป็นการสิ้นเปลืองด้วยซ้ำ
อีกทางนึงของที่มาของ KPI ก็คือสิ่งที่ฟ้าประทาน หรือโครงการที่นายสั่งมา ซึ่งบางที่ก็อาจจะแยกเอาไปวัดผลต่างหาก แต่ถ้าไม่โดนบังคับให้แยก หรือไม่เคยเอาไปวัดผลที่ไหน ก็นำมาใส่ไว้เป็น KPI น่าจะได้ประโยชน์ดี 
เมื่อรู้อย่างนี้แล้ว การสร้าง KPI ของหน่วยงาน หรือของบุคคล ก็ไม่น่าจะยาก เพราะมี KPI ระดับสูงกว่า เป็นเป้าหมายหลักในการสร้าง KPI ที่นี้ก็ได้เวลาหาวัตถุดิบอีกเล็กน้อย มารวมกัน เพื่อทำให้ KPI เหมาะสม และ วัดได้จริง ติดไว้คราวหน้าละกันนะ

เปิด Blog

ขึ้นบ้านใหม่ แต่เนื้อหา ย้ายมา :)

ใครแวะผ่านมาก็อย่าลืมเ้ม้นทิ้งไว้บ้างนะ


ขอบคุณค่ะ

ศรีภัทรา