Rangwan.Com

ไหนๆ ก็ไหนๆ แล้ว ต่อด้วยเรื่อง spam mail ในบริษัทเลยก็แล้วกัน ซึ่งบริษัทที่มีสาขาทั่วโลก ใช้ Exchange server หรือ Lotus Notes เป็น email server หลัก รวมถึงความสามารถด้าน collaboration อื่นๆ เช่น calendar, address book ด้วย อาจจะเคยประสบปัญหาเช่นนี้ เนื่องจากการส่งเมล์หาทุกคนทั้งบริษัททำได้ง่ายมาก(เกินไป)

ตัวอย่างเช่น ณ กาลครั้งหนึ่งไม่ใกล้ไม่ไกลจากวันนี้เท่าไร มีพนักงานคนหนึ่งส่ง email ถึงคนทั้งบริษัท แล้วหลายๆ คนที่ได้รับแต่ไม่เกี่ยวข้องกับเรื่องใน email ก็ต่างพากันตอบกลับไปยังทุกคน (reply all) ว่า “ฉันไม่เกี่ยวกับเรื่องนี้ ช่วยเอาฉันออกไปจากรายชื่อใน email ด้วย” พอทำอย่างนี้หลายๆ คนเข้า พวกที่ตอนแรกอยากลบ email ทิ้งเงียบๆ ก็ทนไม่ไหวบ้าง หันมาส่งบ้างว่า “ไม่ต้อง reply all หรอกว่าไม่เกี่ยวข้อง ถ้าจะบอกก็บอกเจ้าของ email ฉบับแรกคนเดียวก็พอ” แล้วทีนี้ก็มีหลายๆ ความเห็นที่แตกต่างกันเล็กน้อย (แต่ reply all อีกเช่นเคย) ตามมาอีกเป็นระยะๆ เช่น “ขอให้ทุกคนสร้าง filter ที่ outlook client ของตัวเอง น่าจะช่วยแก้ปัญหาได้” ทำไปทำมา chip หายกันทั้งบริษัท ด้วย mailbox ก็เริ่มพอกพูนด้วยจดหมายขยะเหล่านี้ เดือดร้อนผู้ดูแลระบบ ต้องถูกตามตัวโดยด่วน เพื่อกรองเมล์บ้าๆ นี้ออกไปเสีย

เหตุการณ์นี้เข้าข่าย spam mail โดยไม่เจตนา  เพราะความผิดพลาดของเจ้าของ email ฉบับแรก บวกกับธรรมเนียมปฎิบัติ “reply all” เพราะอยากให้ทุกคนที่อยู่ในรายชื่อทราบข้อมูลเดียวกันแท้ๆ

ช่วงนี้มีเรื่องถกเถียงกับคุณลูกค้า เรื่อง pattern ในการตรวจรับระบบ คุณลูกค้าต้องการทำ load test แบบ black box ซึ่งที่จริงแล้วมันเป็น (performance test + stress test มากกว่า) แล้วคุณลูกค้าก็พยายามจะหา Load Generator มาใส่เข้าไปในระบบ ปรากฎว่าเจ้าตัว Load Generator ที่ว่า (หรือว่าผู้ใช้ก็ไม่ทราบ) มันไม่ฉลาดพอ ที่จะสร้าง load pattern ใ้ห้ออกมาเสมือน reality มากนัก ทำทดสอบทีไรก็เน่าทุกที ทั้งๆ ที่ผลทำ load test จาก lab มีมายืนยัน คุณลูกค้าแกก็ไม่รับ ต้องทำเองกับ environment ของแกจริงๆ

จะไม่ช่วยทำ ไม่ช่วยอธิบาย ให้แกเข้าใจกระจ่างก็ไม่ได้ เรื่องของเรื่อง คุณลูกค้าก็พาลจะไม่ตรวจรับระบบ ไม่ยอม go live น่ะสิ แล้วคุณเจ้านายก็จะเซ็งจิต เพราะว่าบริษัทเราก็จะไม่ได้เงิน (สงสัยว่า accountability จะมีที่มาจากเรื่องนี้แหล่ะ ปิดงานได้ ลงบัญชีได้ ก็มี accountability)

ดังนั้นเมื่อไปทางตรงๆ ไม่ได้ เราเลยต้องมาหาทางอ้อมๆ ไปแทน

ตอนแรกก็หา reference ที่น่าเชื่อถือก่อน เช่น IBM และ Sun ว่าเขามีสูตรคำนวณ Average Server Throughput กันอย่างไร แล้วเอาตัวแปรทั้ง 3 ที่ทราบ มาคำนวณหา Average Throughput แทน โดยไม่ต้องไปวัดกันจริงๆ ที่จำนวน load ขนาดนั้น

งานที่เหลือคือ ชี้แจงให้ลูกค้ายอมรับในสูตรคำนวณ หรือไม่ก็ยอมให้เราใช้ตัว Load Generator ของเราเองใช้ทดสอบ ช่วยเลือกเอาซักอย่างเหอะ เราจะได้ช่วยๆ กันปิดโปรเจคต์

เฮ่อ

บริษัทส่งไปอบรม Customer Loyalty ครึ่งวัน ผู้เข้าร่วมอบรมมีทั้ง Line Manager, Project Manager, Technical Architecture & Solution Engineer จะได้ผลเป็นอย่างไร จะสามารถทำให้ลูกค้ายึดมั่นกับแบรนด์ของเราหรือไม่ ช่างน่าระทึกในดวงหทัยเป็นยิ่งนัก

จับประเด็นมาได้ว่า สาเหตุที่พวกเรานั้นหนาต้องมาทำ workshop เรื่องนี้ร่วมกัน ก็เพราะบริษัทเห็นว่าอนาคตของวงการโทรคมนาคมนี้จะเน้นไปทาง service & solution มากกว่าจะขายกันที่ product อย่างเดียวเช่นในอดัตกาลนานโพ้นที่ผ่านมา และตัว Customer Loyalty Index (ต่อไปนี้จะเรียกว่า CLI) ก็เป็นตัวบ่งชี้ว่า เราสามารถครอบงำ เอ๊ย เราสามารถให้บริการลูกค้าได้ดีเพียงไร

ทั้งนี้เราก็ต้องมากำหนดเป้าหมายองค์กรร่วมกันและทำให้ฝัน (เอิ่ม เป้าหมายละกัน) ของพวกเราให้เป็นจริง แต่ก่อนจะทำได้นั้น เราต้องมารู้จักมาตรฐาน CLI กันก่อน ว่ามีการจัดลำดับคะแนนกันอย่างไรบ้าง

• Lost Customer คะแนน 0-4 ถ้าตกอยู่ในกลุ่มนี้แปลว่า เรากำลังจะสูญเสียลูกค้าแล้วล่ะ
• Disappointed คะแนน 4-6.5 กลุ่มนี้ลูกค้าก็ไม่ค่อยประทับใจในบริการของเราเท่าไหร่แล้ว ต้องปรับปรุงแก้ไขโดยด่วน
• Satisfied คะแนน 6.5-8.5 อ่า … ลูกค้าพอใจกับบริการเราแล้ว
• Delighted คะแนน 8.5-10 อันนี้ล่ะ แสดงว่าลูกค้ารู้สึกดี๊ดีกับบริการของเรามั่กๆ บริษัทห้างร้านไหนได้คะแนนระดับนี้ รับรองว่าลูกค้าตรึม

พอเข้าใจกันดีแล้วก็มาเข้าสู่วงจร (ขอเรียกว่าวงจรอำนาจ เพราะเราจะได้อำนาจในการทำให้เป็นจริง โอ้ว … มันยอดมาก) เพื่อหา action plan

• Plan
• Agree
• Execute
• Evaluate

ทั้งปีมี objective มากเหลือเกิน บาง objective ก็ขัดกันยังไงชอบกล เช่น CLI นี้ถ้าคิดแผนแต่ด้านนี้ด้านเดียวก็จะไปขัดกับ Cost Optimization/Revenue Increasing ได้

ปวดหัวชมัด