BzInsight

ดูเอาขำๆ นะครับ อย่าคิดมาก เนื้อหาก็โฆษณาเราดีๆ นี่เอง แต่ทำได้น่ารักดี โดยเฉพาะเสียงคุณผู้หญิงนี่ แปร๋นได้ใจดีจริงๆ Merry Christmas ครับ

ใกล้สิ้นปี 2008 มาดูกันดีกว่าว่าปีหน้า 2009 แนวทางของ BI จะเป็นยังไง ผมเอาคำทำนายพวกนี้มาจาก What’s in store for Business Intelligence in 2009

• Cloud computing will cause a shift in the BI balance of power from IT to business users
• Simplicity will be the driving mantra for both consumers and vendors of BI
• The continued drive for simplicity will cause a shift towards prebuilt analytic solutions with best practices built in, and away from generic toolsets
• Data interpretation will become a significant challenge for new BI users

ผมเห็นด้วยที่สุดเห็นจะเป็นข้อสองเรื่องของ simplicity แถมอีกอย่างด้วยคือ agility คือความเร็วและง่ายในการเพิ่มข้อมูล หรือรูปแบบการวิเคราะห์ใหม่ๆ ได้คุยกับ financial analysts เขาบ่นให้ฟังว่า สถานการณ์เศรษฐกิจเปลี่ยนแปลงไปรวดเร็วมาก ราคาน้ำมัน ราคาวัตถุดิบ อัตราแลกเปลี่ยน swing ไปมาเป็นช่วงกว้าง forcast ยากสุดๆ ความต้องการใหม่ๆ ด้านข้อมูลและการวิเคราะห์ผุดมาเรื่อย การทำระบบ BI แบบเดิมๆ ที่ต้องใช้เวลานานๆ ไม่ได้ผลอีกแล้ว ผู้ใช้ต้องการอะไรที่ง่ายๆ และเปลี่ยนได้เร็วๆ แต่ในขณะเดียวก็ยังคง maintain integrity ของข้อมูลไว้ด้วย

ส่วนเรื่อง pre-built analytics ผมยังไม่เห็นชัดมากนัก แต่ไม่คิดว่าจะเ็ป็นกระแสหลักมากนักในระดับ enterprise ถ้ามองในระดับ departmental อาจจะเป็นไปได้ที่มีการเลือกใช้ pre-buit analytics มากกว่า generic tool แต่ผมยังมองไม่ออกว่า เครื่องมือแบบบ pre-built ของ vendor รายใดรายหนึ่งจะเหมาะกับองค์กรใดองค์กรหนึ่งไปเสียทุกส่วน อย่าลืมนะครับว่า งาน enterprise ให้ความสำคัญกับเรื่อง integration มากเป็นพิเศษ ถ้าจะเืลือก pre-built ที่เหมาะกับงานส่วนใดส่วนหนึ่ง ก็อาจจะไม่เหมาะกับส่วนอีื่นก็ได้ สุดท้ายถ้าไม่เจอปัญหา integration ก็ไม่พ้นลงเลยที่ generic tool อยู่ดี

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

ใครที่สนใจข่าวคราวความเคลื่อนไหวเกี่ยวกับ BI และใช้ Twitter เหมือนผม คงสนใจรายชื่อ BI Industry twitter user (เป็น Google spreadsheet)

รายชื่อนี้รวบรวมโดย Shown Rogers (@shawnrog) ที่มา

ใครทราบแหล่งข้อมูลเกี่ยวกับ BI เป็นภาษาไทย ก็รบกวนแปะไว้ใน comment ด้วยนะครับ ถ้าใครสนใจ หรือทำงานด้านเดียวกัน และใช้ twitter ก็บอกด้วย (@p_warawit)  เราอาจมีมี BI twitter list ภาษาไทยบ้างก็ได้

เรื่อง MDM หรือ master data management กำลังเป็นคำยอดฮิตในหมู่คนที่มีส่วนเกี่ยวข้องกับงาน BI แต่ก็เหมือนกันกับ buzzword อื่นๆ ที่พอมีคนพูดถึงกันมากๆ vendor หรือคนไอทีหลายๆ คนก็เริ่มพยายามตั้งชื่อระบบ หรือสร้างงานที่มันมีคำว่า MDM อยู่ด้วย จะได้ไม่ตกยุค

ผมเองก็เป็นคนหนึ่งในจำพวกนั้น คือโดยหน้าที่รับผิดชอบ ต้องหาหรือสร้างความสามารถที่จะทำให้องค์กร ได้รับประโยชน์สูงสุดจากการลงทุนในงานด้าน Business Intelligence ซึ่งปฎิเสธไม่ได้เลยว่า คุณภาพของข้อมูลมีความสำคัญเป็นอย่างยิ่ง และเจาะให้ลึกลงไปอีก กว่าครึ่งของปัญหา data quality มีสาเหตุมาจากข้อมูลอ้างอิงหรือ master data นี่แหละ วิธีง่ายๆ ในการขายไอเดียให้ผู้ใหญ่ ก็คือ ก็เลือกใช้คำว่า MDM นี่แหละ ดูทันสมัยดี

โดยเนื้อหาแล้ว งานในส่วน MDM ก็คืองานที่ผสมกันระหว่าง data architecture กับ IT management นั่นแหละ คือต้องมองให้ออกว่า ข้อมูลอ้างอิงที่ต้องการ มันกระจายอยู่ในส่วนไหนขององค์กรบ้าง แล้วผลักดันให้เกิดระบบและกระบวนการทำงานที่มีประสิทธิภาพสูงสุด เกิดโอกาสผิดพลาดจากข้อมูลอ้างอิงน้อยที่สุด ซึ่งไม่ใช่เรื่องใหม่เลย เป็นสิ่งที่เมื่อ 10 ปีที่แล้ว ก็มีงานในลักษณะนี้ แต่ตอนนั้นมันไม่ได้เรียกกันว่า MDM เท่านั้นเอง

ผมมี white paper อยู่ฉบับหนึ่ง ซึ่งดาวน์โหลดมาจากไหนก็จำไม่ได้แล้ว แต่เคยเอาเนื้อหาในนั้นมาทำ presentation อธิบายลำดับขั้นความก้าวหน้าในการจัดการข้อมูลอ้างอิงภายในองค์กร เลยตัดเอาเฉพาะส่วนที่อธิบาย maturity level มาอัพขึ้น slideshare ข้างล่าง (อาจจะดูห้วนๆ ไปบ้างนะครับ เพราะความจริงแล้ว section นี้มันฝังอยู่ใน presentation ใหญ่เรื่องอื่ีนอีกที) ส่วนใครสนใจอยากอ่าน white paper ฉบับเต็ม ก็ดาวน์โหลดได้ที่นี่เลยครับ (pdf, Eng, 760kb)

ระหว่างมองหาผู้ให้บริการด้าน business intelligence ก็ผ่านไปเจอเข้ากับบริษัท yellowfin ซึ่งมี url เป็น http://www.yellowfin.bi ที่น่าสนใจก็คือ เขาใช้โดเมน .bi ซึ่งในที่นี่หมายถึง business intelligence ความจริงก็เคยได้ยินมาเมื่อเร็วๆ นี้ ที่มีการเปิดให้จดทะเบียน top-level domain name อื่นๆ นอกเหนือจาก .com .net .org และอื่นๆ ที่คุ้นเคยกันทั่วไป

เห็นอย่างนี้ผมก็นึกว่า ดีเลย ต่อไปคงมีเว็บไซต์เกี่ยวกับ Business Intelligence ที่เป็น .bi ขึ้นมาอีกเยอะแยะ น่าจะไปจองไว้บ้างเหมือนกัน แต่พอค้นไปค้นมา ปรากฎว่า .bi นี่มีเจ้าของอยู่แล้วนะครับ เป็นของประเทศ Burundi http://en.wikipedia.org/wiki/Burundi ซึ่งผมเองก็ไม่ทราบเหมือนกันว่าออกเสียงว่าอย่างไร อยู่ในทวีปแอฟริกา

ถึงแม้ว่า .bi http://en.wikipedia.org/wiki/.bi จะดูแลโดยหน่วยงานของประเทศ Burandi เอง แต่ก็เปิดให้มีการจดทะเบียนโดยใครก็ได้ เพียงแต่ขออย่าให้เป็นการนำไปใช้เพื่อให้เข้าใจผิด จะว่าไปแล้ว ก็ดูน่าเห็นใจอยู่เหมือนกัน เพราะคงไม่มีใครอยากให้ตัวย่อประเทศของตัวเอง มีความหมายกลายเป็นอย่างอื่น

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

คำสัญญาหรือประโยชน์หลักของ business intelligence ที่มีให้ต่อองค์กรธุรกิจ คือ ช่วยเพิ่มประสิทธิภาพในการตัดสินใจ ซึ่งประเด็นหลักอยู่ที่ การนำข้อมูลมาช่วยในการตัดสินใจ เราอาจจะเคยได้ยินวลีที่ว่า “Better informed decision” หรือ “Data-based decision making” แต่ถ้าภายในองค์กรของคุณ ขาดความสามารถในการบันทึกข้อมูลที่ละเอียด ครอบคลุมเพียงพอแล้วละก็ ลืม business intellligence ไปได้เลย เพราะไม่มีทางที่เป็นไปได้หากไม่ปรับเปลี่ยนกระบวนการทำงานพื้นฐานเสียก่อน

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

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

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

ถ้าคุณมีพนักงานขายสินค้าต่างจังหวัด ที่ส่งรายงานการขายเข้ามาที่บริษัทเดือนละหนึ่งครั้ง อย่าเชื่อโฆษณาที่ว่า BI สามารถทำให้คุณทราบข้อมูลการขายเป็นรายวันหรือรายสัปดาห์ได้เพียงแค่ซื้อซอฟต์แวร์บางอย่างเข้ามาใช้ นอกเสียจากว่า คุณจะยอมลงทุนปรับเปลี่ยนการทำงานของพนักงานขาย ให้ส่งยอดขายเข้ามาถี่มากขึ้น ซึ่งการลงทุนที่ว่านี้ อาจจะเป็น hidden cost ในการนำ BI เข้ามาใช้ในองค์กรได้

ในระหว่างการประชุมทำ project review เมื่อกลางสัปดาห์ที่ผ่านมา ทางโปรเจ็คสปอนเซอร์ ซึ่งเป็น sales director ก็รีวิวความคืบหน้าของโครงการ ทางทีมทำ solution เสนอรายงาน 5 แบบกับ OLAP cube อีกหนึ่ง พอท่านผู้ใหญ่เห็นรายงาน ก็เริ่มเอ่ยปากขอ เพิ่มคอลัมน์ตรงนี้ได้ไหม ตัวเลขยอดขายนี่ นอกจากเป็น absolute volume แล้วขอเป็น index vs year ago ด้วยเป็นต้น ซึ่งแน่นอน ว่าโดยทางเทคโนโลยีแล้ว เป็นเรื่องง่ายมาก

ก่อนที่ทาง technical team leader จะมีโอกาสอ้าปากตอบ ผมต้องรีบชี้แจงว่า รายงาน 5 แบบนี้ ได้มาจากการทำ focus group discussion กับกลุ่มผู้ใช้ ผ่านการทะเลาะถกเถียงกันมานาน เพื่อให้ได้รายงานเพียงแค่ 5 แบบ (แทนที่จะเป็น 30 แบบ เพราะแต่ละคนต่างก็มี “ความชอบ” แตกต่างกัน)   ความจริงแล้ว เทคโนโลยีไม่ใช่ประเด็นหลัก แต่เราอยากได้รายงาน 5 ฉบับที่ 95% ของผู้ใช้เรียกใช้งานทุกวัน ทุกสัปดาห์ มากกว่าจะมีรายงานมากมายถึง 30 แบบ แต่ว่าแต่ละแบบมีคนใช้อยู่ไม่กี่คน กระจัดกระจายกันไป

ผมชี้แจงปัญหาที่ผมเรียกเอาเองว่า report proliferation คือการที่รายงานต่างๆ มีจำนวนเพิ่มมากขึ้นเรื่อยๆ อย่างรวดเร็ว เพียงเพราะว่าเครื่องมือด้าน business intelligence หรือความสามารถของคนไอที ที่ “ทำอะไรก็ได้ แบบไหนก็ได้ ใครขออะไร ได้หมด” และโดยส่วนมากความต้องการที่แตกต่างกันในแต่ละรายการก็เป็นเพียงแค่ want หรือ preference มากกว่าจะเป็นความต้องการทางธุรกิจจริงๆ

ลองนึกภาพพนักงานเข้าใหม่ มาทำงานวันแรก เริ่มใช้รายงานเป็นครั้งแรก เปิดหน้า portal เข้ามาเจอรายงาน 30 ฉบับก็ตาเหลือกแล้ว ไหนจะต้องคอยมาจำอีกว่า ถ้าจะคุยกับคนนี้ต้องใช้รายงาน A จะคุยกับคนนั้นใช้รายงาน B ทั้งๆ ที่เนื้อหาในรายงานโดยเนื้อแท้แล้ว ก็มาจาก cube หรือมาจาก datamart อันเดียวกันนั่นเอง

เราสรุปกันได้ว่า คำขอของ sales director ท่านนั้นก็จะผ่านไปสู่กระบวนการของ change management board เหมือนคำขออื่นๆ แถมดูเหมือนท่านจะสนับสนุนแนวคิด less is more แบบนี้เสียด้วย

คนที่เคยใช้ windows มาก่อน พอมาใช้งานระบบตระกูล unix (รวมทั้ง Linux ด้วย) ก็มักจะค่อนข้างงงงันกับชื่อโฟลเดอร์ต่างๆ ที่สั้น และไม่ค่อยสื่อความหมายเอาเสียเลย ไม่รู้จะไปหาอะไรที่ไหน แถมยังจำยากเสียอีก  ส่วนหนึ่งก็แทบจะเป็นประเพณีหรือธรรมเนียมไปแล้ว เพราะชื่อไฟล์บางอย่างก็ถูกใช้มาตั้ง 30 ปี และแถมบางไฟล์บางกลุ่ม ยังมีความหมายและทำหน้าที่พิเศษบางอย่างเสียด้วย

ไฟล์ต่างๆ ในระบบ unix จะแบ่งเป็นชั้นๆ ส่วนบนสุดคือ / หรือที่มักจะเรียกกันว่า root directory ถ้าไปลอง ls ดูที่ root ก็มักจะเห็นไฟล์หรือโฟล์เดอร์เหล่านี้

/bin ย่อมาจาก binary เป็นหนึ่งในหลายแห่ง ที่เก็บโปรแกรมแอพลิเคชันและยูทิลิตี้ต่างๆ แต่โปรแกรมที่อยู่ใน /bin มักเป็นโปรแกรมสำคัญที่ใช้บ่อยในการทำงานของระบบ ตัวอย่างเช่น โปรแกรม shell หรือ โปรแกรมจัดการไฟล์อย่าง cp และ chmod เป็นต้น

/sbin นี่ก็ใช้เก็บโปรแกรมเหมือนกัน แต่ว่าจะเป็นเฉพาะโปรแกรมที่ถูกใช้โดย superuser เท่านั้น ซึ่งก็เป็นที่มาของชื่อด้วย คือ superuser-bin

/dev ย่อมาจาก device เป็นที่เก็บไฟล์ที่เกี่ยวข้องกับฮาร์ดแวร์ของระบบ เช่น จอภาพ, คีย์บอร์ด ฮาร์ดดิสก์ หรือ usbport รวมถึงพอร์ทต่างๆ ด้วย

/etc เอาไว้เก็บพวกไฟล์ที่เป็น system configuration ทั้งหลาย

/home เป็นที่เก็บโฮมไดเร็กทอรีของผู้ใช้ทั้งหลาย โดยจะมีการแบ่งย่อยลงไปอีกตามชื่อ login เช่น ผู้ใช้ที่มีชื่อล็อกอินเป็น joe จะมีโฮมไดเร็กทอรีเป็น /home/joe

/lib ย่อมาจาก library ซึ่งเอาไว้เก็บไฟล์ system library สำคัญๆ ทั้งหลาย ในระบบ Unix พวกไลบรารีเหล่านี้จะแชร์กันระหว่างโปรแกรม โดยไม่ได้รวมไว้ในไฟล์ binary แต่จะถูกโหลดมาใช้เมื่อต้องการเท่านั้น ดังนั้นการลบหรือย้ายที่ไฟล์ใน /lib แม้เพียงไฟล์เดียว อาจส่งผลให้โปรแกรมเป็นจำนวนมากไม่สามารถใช้งานได้

/mnt ย่อมาจาก mount เป็นไดเร็กทอรีมาตรฐานในการพ่วงอุปกรณ์เก็บข้อมูลอย่างฮาร์ดดิสก์ ถ้าต้องการดูว่ามีอุปกรณ์เก็บข้อมูลอะไรพ่วงอยู่บ้าง สามารถเรียกใช้คำสั่ง mount ได้

/tmp ย่อมาจาก temporary เป็นที่เก็บไฟล์ชั่วคราวของระบบ อะไรที่อยู่ในนี้ ถือว่าสามารถลบทิ้งได้ถ้าเสร็จงานแล้ว

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

/var ย่อมาจาก variable เป็นที่เก็บของไฟล์ต่างๆ ที่มักจะเพิ่มจำนวนขึ้นเรื่อยๆ ตามเวลา เช่น เมล์ log file และไฟล์ฐานข้อมูล เป็นต้น

ที่มา : Ramble around the UNIX file system

ในปีนี้ ทั้ง Cloud Computing กับ SaaS (software as a service) ต่างก็เป็นศัพท์ใหม่มาแรงที่ใครๆ ก็ใช้กันทั้งนั้น ไม่เว้นแม้แต่ในแวดวงอุตสาหกรรม Business Intelligence ถึงกับคาดว่า แนวโน้มสำคัญในปี 2008 ประการหนึ่งคือ การที่ BI จะเข้าร่วมขบวน cloud computing ด้วย

แล้วก็มีคนคุยกันถึงเรื่องนิยามของ cloud กับ SaaS ผ่านทาง twitter โดยเสนอว่า

• Cloud Computing = infrastructure (processing power + storage) available over the Web
• SaaS = apps and services built on/in the Cloud

ได้รับเสียงตอบรับพอประมาณ ไปอ่านความคิดเห็นต่อข้อเสนอนี้ได้ที่นี่

ผมค่อนข้างเห็นด้วยกับนิยามข้างต้นโดยภาพกว้าง แต่ก็มีความเห็นส่วนตัวเพิ่มเติมคือ

• Could เป็นความพยายามที่จะเพิ่ม scalability ของระบบ โดยซ่อนความยุ่งยากของการจัดการระบบไว้หลังกลุ่มเมฆ
• Could ไม่จำเป็นต้องเป็น 3rd party เสมอไป คุณสามารถสร้าง could computing ใช้ในองค์กรได้เอง ถ้าบริษัทใหญ่และมีเงินมากพอจะทำ
• ข้อดีของ cloud สำหรับผู้พัฒนาคือ คุณไม่ต้องวุ่นวายกับการ scale เลย ไม่ต้องมาคิดเรื่อง load balancing หรือ distributed computing/database มีคนจัดการให้คุณแล้ว
• SaaS น่าจะเป็นโมเดลทางธุรกิจ ที่พยายามเปลี่ยนรูปแบบการสร้างรายได้จากซอฟต์แวร์ จากที่เดิมเป็นการขาย license กับ support/maintenance มาเป็นการขาย “บริการ” น่าจะไม่ต่างจากแนวคิด ASP (Application Service Provider) เมื่อหลายปีก่อน
• รูปแบบรายได้ของ SaaS ที่คาดว่าน่าจะดึงดูดกลุ่มผู้ใช้ ควรจะเป็น pay per use คือใช้เท่าไหร่ก็จ่ายเท่านั้น ไม่ต้องลงทุนแพงๆ ในช่วงต้น เห็นว่าดีก็ใช้บริการต่อ ไม่พอใจก็หยุดใช้
• ในอดีต ก่อนที่ cloud computing จะมาดัง ASP หรือผู้ให้บริการ SaaS ต้องเตรียมโครงสร้างพื้นฐานเอาเอง ซึ่งต้องลงทุนสูง
• Cloud computing ทำให้ผู้ประกอบการเริ่มให้บริการ SaaS ได้ง่ายยิ่งขึ้น

ใครเห็นด้วย หรือเห็นแตกต่างกันอย่างไรบ้างครับ?