Took Lae Dee (ถูกและดี)

ชีวิตผมจะผูกพันกับฟู๊ดแลนด์ (www.foodland.co.th) ค่อนข้างมาก เอาเป็นว่าไม่ค่อยอยากเดินที่ซุปเปอร์มาร์เก็ต ที่อื่นแล้วกัน

วันนี้ก็อีกวันหนึ่งที่ต้องฝากท้องที่ฟู๊ดแลนด์ ถูกและดี (http://foodland.co.th/restaurant.htm) ชื่อร้านก็ธรรมดา เข้าใจง่าย ร้านอาหารส่วนมากจะซ่อนครัวไว้หลังร้าน แต่ที่ฟู๊ดแลนด์ไม่ เค้าเอามาให้ดูเลยว่าเตรียมกันอย่างไร วุ่นวายขนาดไหน

ผมไม่รู้ว่าวัตถุดิบมาจากที่ใดได้ แต่ขอเดาว่า น่าจะมาจาก ฟู๊ดแลนด์ซุปเปอร์มาเก็ต นี่แหละ เป็นเปิดร้านอาหารที่มีแหล่งที่มาใกล้ ๆ ดี

ว่าง ๆ ลองไปชิมดูนะครับ

Service Level Agreement

ปัจจุบันนี้การซื้อสินค้าจะมีบริการหลังการขายให้มาด้วย เช่น เมื่อเราซื้อ Apple Mac Book แล้ว ก็จะมีการรับประกันสินค้าและบริการให้ภายใน 1 ปี พอหลังจากนั้นทางลูกค้าก็สามารถเลือกได้ว่าจะซื้อบริการหลังการขายต่อได้ เช่น Apple Care

ปัจจัยอะไรที่ทำให้ลูกค้าตัดสินใจในการซื้อบริการเหล่านี้บ้าง

1. ราคาค่าบริการ
2. การบริการที่ได้รับ

ซึ่งก็ต้องมองว่าความคุ้มค่าต่อการซื้อบริการหรือไม่

พอมามองถึงการซื้อซอฟต์แวร์ ก็จะมีลักษณะคล้าย ๆ กัน โดยทั่วไปแล้วจะมีการคิดค่าบริการอยู่ที่ 10-15% ของราคาขาย

Software as Service หละ เค้าคิดกันอย่างไร?

เนื่องจากการใช้งาน Sofware ในลักษณะนี้เป็นการซื้อบริการตั่งแต่แรก ดังนั้นจึงไม่มีการซื้อสินค้าเลย แล้วจะคิดราคาอย่างไร

เมื่อก่อนเราบอกลูกค้าว่าต้องจ่าย 10-15%  แต่เดี่ยวนี้อาจต้องบอกว่า ลูกค้าจะจ่ายเท่าไหร่ แล้วทางผู้บริการก็บริการเท่าที่ทำได้ แต่เนื่องจากต้องมีหลักให้ทางลูกค้าพิจารณาเริ่มต้นก่อน ดังนั้นจึงแยกออกมาเป็น 3 ระดับง่าย ๆ ก่อน เช่น

1. Platinum Service
2. Silver Service
3. Bronze Service

โดยแต่ละระดับก็ให้บริการที่ต่าง กัน เช่น

Services	Bronze Service	Silver Service	Platinum Service
Response Time	1 hr	30 m	15 m
Resolved Time	3 hr	2 hr	1 hr
Service Engineer	N/A	1	2
Business Application Engineer	N/A	N/A	1
Phone support	2 hr/week	3 hr/week	5 hr/week
Email Support	5 email/week	10 email/week	Unlimit
Time of Service	Mon-Fri 8:00-17:00	Mon-Fri 8:00-17:00	All Time

สุดท้ายก็ดูที่ราคาที่ผู้ให้บริการสามารถยอมรับได้

ความยากก็ตกอยู่ที่ผู้ให้บริการแทน เพราะว่าต้องคอยทำให้ได้ตามที่ตกลงกันไว้นั่นเอง

กดของความพอดีของ Python

ผมเป็นพวกสาวก Python เพราะว่าเขียน Java แบบโครงการได้แค่ Hello World แต่เขียน Python ได้ถึงระดับ บังครับ IE ทำงานเป็น Robot

เอาเป็นว่ามาดูความง่ายของ Python กัน

The Zen of Python

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Decision Support System ในด้านอื่นมากกว่า Finance

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

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

ปัจจัยที่ระบบ DSS ส่วนใหญ่ยังคงอยู่กับระบบการเงินนั้น มีเหตุผลดังนี้

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

ยกตัวอย่างระบบที่เค้าเรียกว่าต้นน้ำกัน

• ระบบวิเคราะห์การจัดส่งจดหมายหรือสื่อสิ่งพิมพ์ ให้กับลูกค้าที่มีความสนใจในผลิตภัณฑ์ เช่น งานวิเคราะห์ Questionnaire งานการลงทะเบียน
• การวิเคราะห์หาสาเหตุของการเปลี่ยนอะไหล่รถยนต์ในแต่ละพื้นที่
• การหาช่วงเวลาของการเปิดสัญญาณไฟ ตามแยกต่าง ๆ ตามเวลา ที่เหมาะสม

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

มาดู WorkFlow ที่เค้าทำกัน

• ปัญหาที่เกิด
  เมื่อมีลูกจ้างในหน่วยงานด้าน Healthcare จะรู้ได้อย่างไรว่า ใบอนุญาติหมดอายุเมื่อใด วิธีการจัดการมี 2 แบบ คือมอบหมายให้ตัวแทนการจัดหาลูกจ้างคอยจัดหาลูกจ้างที่ใบอนุญาติยังไม่หมดอายุเข้ามาทำงานเท่านั้น หรือ หาทางป้องกันไม่ให้ลูกจ้างที่ใบอนุญาติหมดอายุทำงานที่เสี่ยงจนกว่าจทำการต่อใบอนุญาติ 
• จุดมุ่งหมายของธุรกิจ
  ต้องการเพิ่มความปลอดภัยของผู้ป่วย โดยการลดจำนวนของลูกจ้างที่ใบอนุญาติหมดอายุ ลดค่าใช้จ่ายของตัวแทนที่ต้องจัดหาลูกค้าที่จะหมดอายุ
• ขบวนการในปัจจุบัน
  ให้แต่ละผู้จัดการในส่วนต่าง ๆ ตรวจสอบวันหมดอายุของลูกค้าในส่วนที่เกี่ยวข้อง
• วิธีการตอบปัญหา
  ทำตารางเวลาของรายงานจากฐานข้อมูลส่วนกลาง แต่ละแผนกโดยมีรายละเอียดของลูกจ้าง และวันหมดอายุของใบอนุญาติส่งให้ผู้ที่เกี่ยวข้อง

Simple Cube Store

มาดูกันว่า หลังจากได้ Dimension แล้ว คราวนี้ เราจะมาสร้าง Cube อย่างไร

การมอง Cube คือการมองที่ตาราง Fact นั่นเอง โดยมี Foreign key ไปยังแต่ละ Dimension ที่สร้าง

จะมีสิ่งที่ดูแล้วใหม่นิดหนึ่งคือตรง Dimension "Store Type" เพราะว่าเป็นการ Degenerate Dimension เพราะว่าเนื่องจากว่า Store Type นั้นมีสมาชิกไม่กี่ตัว การทำตารางออกมาอีกต่างหากเพื่อ Dimension นั้นดูแล้วจะทำให้การ Query ต้องทำงานมากขึ้น

Join Table ใน Dimension

ปกติแล้วเราจะมีแค่ Table เดียวใน Dimension ซึ่งเรียกว่า Star schema แต่ก็มีบางครั้งที่ ใน Dimension นั้นมีการ Join กันของตารางที่มากกว่า 1 ตาราง เรียกว่า "Snowflake schema" หลักการของการเขียน Dimension ก็แบบนี้ (ดูแล้วคล้าย ๆ กับ Table join กันนั้นแหละ)

พอเรา Join กันแล้ว ตรง Level เราก็สามารถอ้างอิงถึง สมาชิกของแต่ละตารางได้

Time Dimension

Time Dimension เป็นลักษณะการสร้าง Hierarchy ของเวลา โดยรูปแบบมักจะเป็นดังนี้

• Year
• Quarter
• Month
• Week
• Day in month

อันนี้ก็แล้วแต่ความต้องการจะวิเคราะห์

เหตุที่มี Hierarchy 2 อันนั้นถ้าดูจากฐานข้อมูลแล้วจะพบว่า ข้อมูลนั้นอยู่บนตารางเดียวกัน ซึ่งในบางครั้งเราสามารถงานต่างกันได้

มาเรียนรู้ FoodMart กันเถอะ

คราวนี้หลังจากทำการติดตั้ง Pentaho เรียบร้อยแล้ว ก็ถึงเวลามาเจอะการใช้งานเป็นส่วนๆ ไป ส่วนแรกในวันนี้เราจะพูดถึง "ทำความเข้าใจกับ Mondrian จาก FoodMart"

Foodmart เป็น Sample Data ที่ติดมากับ Mondrian การติดตั้ง FoodMart นั้นต้องกลับไปดูบทความก่อน ๆ นะครับ

Dimension แรกที่เราจะพูดถึงคือ Store มีโครงสร้างดังนี้

ผมชอบ XML ตรงที่ โครงสร้างอธิบายความหมายด้วยนี่แหละ เพราะว่า ไม่ต้องเสียเวลาอธิบาย ลงไปใน Code

จาก Dimension นี้เราจะได้ Dimension Store ที่บอกถึงคุณลักษณะของ Store เราได้อย่างครบถ้วน  ที่ชอบมาก็เห็นจะเป็น ขนาดต่าง ๆ ใน Dimension นี้นี่แหละ

Store Sqft = ขนาดพื้นที่ทั้งหมดของร้าน มีหน่วยเป็นตารางฟุ๊ต
Grocery Sqft = ขนาดพื้นที่ที่สามารถขายสินค้าได้ มีหน่วยเป็นตารางฟุ๊ต
Frozen Sqft = ขนาดพื้นที่แช่แข็ง
Meat Sqft = ขนาดพื้นที่ของอาหารประเภทเนื้อ
Has coffee bar = ร้านนี้มีชั้นขายเครื่องดื่มกาแฟหรือไม่ (คิดได้ไงเนี่ย)


จะเห็นว่า Dimension นี้มีไว้สำหรับการวิเคราะประเภทร้านได้ดีทีเดียว

แล้วตรง Property มีไว้ทำไม?
Property มีไว้สำหรับการเข้าถึง Member โดยใช้ชื่อของ Property ดังตัวอย่างนี้