你正在看一個由企業內使用者所發表的BLOG!所以我想可以談一下企業內部如何用BLOG來增進與客戶的溝通!
以下內容是自"
運用 Microsoft® SharePoint® 產品與技術的 Blog 和 Wiki 功能提供企業優勢"白皮書.
Blog 和 Wiki 的商業應用
如同電子郵件，Blog 和 Wiki 的企業使用者也分為各種類型。不論是在需要用到會議、電子郵件、合作備忘錄或討論的場合，Blog 或 Wiki 都可以派上用場；因此可以想像這兩種平台可以應用在多麼廣泛的地方。在評估組織中可能的使用者時，必須先找出這兩種選項最適合的用途，因為 Wiki 是一種合作式的網站，而 Blog 則是用來發行個人的想法，非共用文件。Blog 鼓勵透過分享想法來進行合作，但卻不提供單一文件的共用存取權；Blog 中的所有對話都會按照時間順序排列。
企業使用的 Blog
企業使用的 Blog 必須採行嚴苛的監督和管理，如同其他的企業典範：安全性、支援功能與回復能力。一般使用者在使用網際網路上的 Blog 網站時，幾乎不知道有這些管理功能的存在。大型的 Blog 網站則提供管理型的主機解決方案，且不需要刊登服務廣告。
然而，企業部署 Blog 網站的主要原因並不是客戶服務的提供及維護能力，而是提供客戶在選擇產品時的真實評析。如同所有的企業解決方案，首先最需要找出來的就是企業的問題。Blog 是一種溝通的方法，因此最需要觀察的就是溝通議題，不論是內部的或是與外部夥伴或客戶的溝通。
內部 Blog
Blog 提供了迅速、即興且簡單的想法抒發管道，讓使用者可以發行文章供其他人閱讀。但與即時訊息 (IM) 不同的是，這些想法存在於固定的位置上，不限存取的人數，而且所有人都可以加入自己的想法予以回應。張貼文章不似 IM 或電子郵件般的具有干擾性，因為閱讀者可以自行找時間來閱讀 Blog。Blog 也使得寄送大量電子郵件的需求不復存在。
Blog 網站會以相反的時間順序來顯示內容，讓使用者可以利用比電子郵件更輕鬆且明確的方式來檢視討論串。
公司的 Blog 可以依主題分類，如同組織良好的收件匣一般。貢獻者和閱讀者可以自己選取感興趣的主題，並跳過不相關的主題。Blog 網站可以建立在團隊、部門、分公司或組織層級，數量和種類則由網站與張貼文章的作者依想像來決定。就各方面來說，這樣可以自我規範。如果某個網站內容貧乏或不適當，參與討論的人數就會銳減。當網站作者發現閱讀人數屈指可數時，他們也會自己停止貢獻。
外部 Blog
在將少量資訊傳達給客戶或夥伴時，外部 Blog 是一種特別有效的方式。網路上的 Blog 通常都提供有自動說明網站，當中張貼有條不紊的提示、小技巧與解決方案。這就好比是傳統式的線上社群，只是張貼文章更輕鬆且幾乎不需要管理。
但 Blog 的其中一個問題是，因為它們需要自我規範，所以閱讀者無法確定張貼文章是否正確。對企業來說，他們不只需要確定任何傳達給客戶的內容在技術上是正確的，更要確保它們符合公司的發行準則與標準。即使您可以透過公司政策來管理公司內部的貢獻者，但對於外部貢獻者的張貼卻仍是束手無策。
熱騰騰的新書出爐囉!由屠立剛老師與吳翠鳳老師所編寫的Microsoft Office SharePoint Server 2007 新一代網頁資訊設計與應用第3集終於推出了.這一系列書籍不論從質感,內容編排,以及使用者親和力來說,都是上上之選.第一集主要針對基本架設以及協同合作功能應用做了詳盡的解書,第二集則是針對比較進階的表單,文件庫功.而這一集,則是提供了我之前一直在鼓吹的"No-Code 不用寫程式,也能客製化" 的功能作了比較深入的探討.其內容重點節錄如下:
| ■ |
如何客製化MOSS 2007或是WSS 3.0的網站環境，讓設計者可以設計出完全屬於自訂風格的資訊網站環境。 |
| ■ |
詳述文件轉換功能，將Word文件、InfoPath文件自動轉換成網頁，提供更具彈性的頁面。 |
| ■ |
建置與管理具有多國語系的發佈型網站環境。 |
| ■ |
探討在MOSS 2007與WSS 3.0中的主版頁面架構，以及需應用於其中的各項控制項，包括網站動作、導覽、使用者控制項…等，都是許多技術文件或其他相關書籍都沒有談到的內容。 |
| ■ |
透過MSPD (Microsoft SharePoint Designer 2007) 設計更具應用性的頁面。 |
| ■ |
建立不同驗證提供者來進行使用者驗證的處理。 |
| ■ |
如何利用〔我的網站〕建置使用者個人得心應手的入口網站環境。 |
跟著這一波新書出版,我也希望能夠在接下來的時間,多一點討論如何以SharePoint Designer進行客製化.
歡迎讀者提供意見.
http://wondersoftheworld.idvsolutions.com/default.aspx是一個線上地圖網站,使用者可以點選右側的圖層去選擇你想觀看的著名景點,你也可以進行放大,縮小,平移等動作.
與以往線上地圖網站不同的是,這個網站裡充分地展現了Software + Services的真諦,他是在MOSS的網站上崁入兩個執行Flash的Web Part,然後再透過Flash的Script去呼叫Virtual Earth Web Services以及MOSS開放出來的Web Service API存取景點資訊(POI, Point of Interest)進行MashUp展示(圖層套疊),所以底圖的部分是來自於Virtual Earth的衛星影像,而景點資料則可以存在於MOSS的清單中,可以很方便地進行維護.
我在多年前便是靠寫這種地圖伺服器維生的,想當初要替客戶建一個這樣的網站,需要購買圖資(向量圖,衛星影像或空照圖),蒐集景點資料並且予以數化,建置地圖伺服器(自行開發或買商業用地圖伺服器軟體如ArcGIS, MapXtreme, MapGuide等),建置資料庫等作業零零總總下來,沒有個幾百萬大概是做不起來的.可是在S+S的世界中,程式開發人員可以藉由存取如微軟Virtual Earth所提供的免費地圖服務,便能夠輕鬆地建置出一個專屬的地圖網站,費用會是多少呢?我想大個不需要到超過幾個人月的工,便能夠輕鬆達成.
上述由IDV所開發出之範例網站,充分地顯示出Software + Service的價值,在企業的網站上(Software)能夠輕易地擴充其服務(只要走開放的Web Services架構),此範例中我們看到了地圖來自於Virtual Earch(Service),景點資料來自於MOSS的清單,我們未嘗不可改變一下他的做法,把地圖和企業的CRM資料(透過BDC去連結)進行套疊以分析客戶分布?Software + Service可以帶來的想像空間是無限的,重點是,以前需要耗費許多資源才能做的事情,現在可能一個人變能輕鬆寫意的完成,這便是資訊科技的價值!
MOSS 2007同時支援在32 bit與64 bit環境的安裝,可是如果能夠在64 bit環境中安裝,所得到的效能可以大幅提升,一方面是可以使用的RAM較多,另一方面在記憶體存取時速度也會較佳,這個在WFE(Web Front End)角色上特別明顯.如果你必須使用32 bit環境安裝MOSS 2007,產品部門提供了以下的建議:
If you must run 32-bit Web servers, follow these recommendations:
-
Do not use the /3gb switch for 32-bit systems. If you are running 32-bit Web servers, we recommend that you do not use the /3gb switch in Windows Server 2003 to change the 2 gigabytes (GB) of virtual address space to 3 GB for all user mode processes. We recommend against using the /3gb switch because most SharePoint site traffic involves sending large amounts of data through the operating system. Therefore, leaving only 1 GB of address space for the operating system can destabilize the computer. For more information, see the following article in the Microsoft Knowledge Base: The Windows Server 2003 /3GB switch is not supported in Windows SharePoint Services 2.0 or in later versions or in SharePoint Portal Server 2003 SP2 or in later versions (http://go.microsoft.com/fwlink/?LinkId=105919&clcid=0x409).
-
Mixing 32-bit and 64-bit servers can affect load balancing. You can run an environment that has some Web servers running the 32-bit version of Office SharePoint Server 2007 and others running the 64-bit version. However, there is a risk that the 32-bit Web servers may become overloaded if your network load balancer is configured to use a less-intelligent model as such round robin. We recommend that you configure your load balancer to manage distribution based on load.
MOSS 2007 中同時使用了 ASP.NET 2.0 caching 以及Office 產品部門專門設計出來的新Caching機制,因此使用者藉由SharePoint 中的 caching 機制大幅提升存取的效能.
不管是從Web Part,導覽控制項,頁面,多媒體檔案等都可以得到大幅的效能提升.以下為針對三種不同使用情況所提供的Caching機制說明.
| Use this type of caching… |
At the… |
Notes |
|
Output Caching and Cache Profiles |
Individual page level |
Includes extending caching using VaryByCustomString |
|
Object Caching |
Individual Web Part control, field control, and content level |
Includes cross-list query caching and navigation caching |
|
Disk-based Caching for Binary Large Objects |
Individual binary large object (BLOB) level and caches images, sound, movies, and code |
Supports .gif, .jpg, .js, .css, and other image, sound, and code files that are stored as binary large objects |
在Office SharePoint Server 2007當中一個非常重要的功能,便是協同合作與Social Computing.這是在Web 2.0當中一個非常重要的觀念,簡單來說,你可以藉由你所認識的朋友或同事去認識/接觸到他們的其他朋友或同事,如此一來,知識與資訊的分享與取得便不限於冰冷冷的書面資料,而有可能是一種由內隱式的呈現變成了人與人的互動交流.知識的分享,即使在科技發達的現代世界中,人與人的互動還是最直接以及有效的方式.
知名的公眾網站如:MySpace, Facebook都是重要的Social Network(可以說是Social Computing的一塊)網站,至於在企業內部呢?SharePoint Server便能夠成為企業內部的Social Network網站.藉由SharePoint Server所提供的MySite功能,其他使用者可以了解到某位同事以及這位同事的部門還有哪些同事,他曾經和誰參與過同樣的專案,進而有可能可以建立起一個人際關係.
如果你還不清楚Social Network是甚麼,以下的Video以一個輕鬆有趣的方式讓你清楚了解甚麼是Social Network
從Silverlight推出以來,不斷地有人問到這個技術與SharePoint的整合應用為何?先前都有看到一些零星的實驗性計畫把SilverLight和SharePoint整合在一起,不過在應用方面總是缺乏一個完整的說法.現在除了產品在SP1中加強對於SilverLight的支援外,產品部門也終於發表了一些範例的程式以及開發準則.
MSDN對於這些範例的描述(http://msdn2.microsoft.com/en-us/sharepoint/cc303301.aspx)
直接下載位置(http://www.ssblueprints.net/sharepoint/)
裡面比較精彩的是SilverLight圖片檢視器,SilverLight控制項,還有SilverLight線上學習三個WebPart.
除此之外,各位也可以到http://www.wssdemo.com/pages/silverlight.aspx去參考一下一個用SilverLight + MOSS技術做的圖片瀏覽工具.
從此以後,SharePoint的人生變成彩色的了:)
從下個月起,我們會談一下以SharePoint作為企業內部企業文件管理平台(Enterpris Content Management)的議題.作為一個集中的文件管理平台,SharePoint當然提供了很多管理層面以及使用者使用經驗上的好處,可是企業內部最常用的網路芳鄰(檔案伺服器)管理方式要何去何從?以下節錄於SharePoint Team Blog中的一篇BLOG: Is the File Server Dead?
"Collaborative file shares can be replaced with SharePoint deployments. Product distribution and database storage will continue to persist as valid scenarios. End users will need training to understand where to save their files. With most file sharing scenarios for the most common file sizes SharePoint lists will be the Microsoft recommended way of sending files inside the corporation and with collaborative SharePoint site extranet deployments, it’s the way to share with partners. Most non technical end users scenarios such as the most common HR, Sales, and Marketing teams can say goodbye to using file shares for file sharing. Some groups and divisions like IT SMS/Product Distribution, Data Warehousing (SQL), Media, and Development groups won't be saying good bye to file servers in Windows 2003 and in code name “Longhorn” with key scenarios leveraging cheap NTFS file storage.
Analyzing your current file servers by server or share or folder may allow you to group them by purpose. Here are some examples of common classifications: Collaborative File Sharing, Historical Archive, Media Server, Dump/Desktop Backup, Source Control Servers/Databases, Personal Storage, Product Distribution, and Application Servers."
簡單來說,對於一般企業內的使用者(例如人事,財務,行銷,銷售),網路芳鄰在導入SharePoint之後將徹底被取代,SharePoint能夠支援這些人員所有對於文件儲存與協同合作的需求.但是對IT人員以及工程設計人員(如需要進行CAD設計的人員),網路芳鄰仍然可以扮演良好的資料儲存空間,此時仍應當考慮以檔案伺服器作為以下一類型作業的最佳選擇:
*Product Distribution (Product packages like Office) - 產品安裝檔案
*SMS distribution point (desktop patches and hot fixes) - 軟體安裝與修正檔案派送所需要的檔案
*NT Backups, Backup Servers and Desktop Backups (backups) - 系統資料備份
*Database Storage - (.mdb, .ldf, ndf, .pst, .ost) - 資料庫
*Large Audio/Video and Streaming Media and other large archive read only media such as DVDs, CDs storage (.iso, .wmv, .ram, .vhd) - 大型串流影音檔案與需要大儲存空間的檔案
*Developer Source Control - 程式碼的管控
*Batch, Command Scripts, Executables (.exe, .vbs, .cmd, .bat) - 可執行檔
*Application Server... Client Application Storage Linked Files and File Dependencies - 檔案連結與與系統相關,需要直接存取內容之檔案
*Archives and Dumps (.arj, .rar, .zip, .dmp, .bak) - 歷史資料備份
以下為簡要功能比較表:
|
Windows 2003 R2 File Share (網路芳鄰) |
SharePoint Server Document Center |
|
基於ACL的方式管理權限,設定較困難(僅支援AD) |
能夠支援多種目錄服務(AD, LDAP, and .NET Pluggable providers)作為帳號管控的來源,並且支援細至單一檔案的權限設定
權限不足時能以電子郵件要求存取 |
|
Windows Auditing |
完整的稽核報表,能夠進行各類型事件的篩選 |
|
以Shadow Copy作為備份機制
(預設有開啟) |
具有垃圾回收桶,網站管理者可以輕易救回已刪除檔案的 |
|
以DFS(Distributed File System)進行檔案的異地複製 |
預設即具有可單向發布檔案(同時存至異地)的功能,可以迅速將檔案複製到另一個SITE |
|
支援內寄電子郵件(將電子郵件是為企業文件的一部分) |
|
具備取出/存回機制並可以強制於編輯時檔案取出以免版本衝突 |
| Snapshotted versions (not change based versions) |
可設定檔案的主次要版本 |
|
檔案階層的權限管理 |
可繼承父類別(文件庫,網站)的整合式資訊管理原則,亦支援單一檔案的權限設定 |
|
可於一個文件庫中建立不同類別文件的檢視與篩選,支援單一文件庫中存取不同檔案性質與類別,內建工作流程 |
|
File Service Resource Manager for Quotas or 3rd party |
可以設定Site Collection 的儲存容量, 內建容量管理報表與管理介面 |
|
NTFS Compression, EFS and My Documents Redirection (client dependencies) |
Database Encryption with Third Party, Backup Compression with Third Party |
|
Non Transactional. No Rollback without Shadow Copies |
SQL Server Transaction Logs |
延伸閱讀:
File Servers and SharePoint Doc Libraries... Tough Questions
What Not to Store in SharePoint
ROI from File Shares to SharePoint
大部分企業內的員工如果要和客戶或協力廠商分享資訊,通常是用電子郵件或者FTP的方式進行,可是以電子郵件來進行大檔案的分享卻會受到信箱大小的限制,而以FTP的方式分享資訊除了需要麻煩MIS人員設定目錄與帳號之外,如果權限沒有謹慎設定好又將產生機密檔案外洩的疑慮.
有鑑於上述的限制,有些公司的員工便採用公司資訊架構以外的管道進行外部協同合作,例如使用MSN傳檔或把檔案放在Windows Live SkyDrive這樣的公眾網路平台上.這種作法固然便利,但在安全性上完全無法監督,潛在的問題可能遠大於這種方式所能提供的便利性!
SharePoint除了是企業內部廣泛被採用的協同合作平台,更可以把企業內部的協同合作方式擴大到企業外部的協同合作,藉由延伸SharePoint的設計架構至外部網路之外,藉由快速的外部帳號設定,以及良好的安全性控管,不但能夠快速地與外部人員分享檔案,更能夠確保資料的機密性與安全性!而IT人員也能夠藉由SharePoint內建的稽核功能去管控與防止資訊平台遭到濫用.這個解決方案的細部作法以及一些方便的管理工具可以在SharePoint產品部門最新發表的External Collaboration Toolkit for SharePoint中取得.
家裡用SAP的人有福了,在MOSS 2007的BDC功能推出之後,不斷地有人問我BDC如何與SAP界接,以下的網址中有精彩的範例說明!
http://code.msdn.microsoft.com/obasapsak
BizTalk® Adapter Pack Office Developer Program 提供了一個可以在SharePoint, 2007 Office等平台上快速連結到商務系統(SAP, Siebel, Oracle)的方式.透過這一個計畫,程式開發人員可以透過.NET輕易地連結到這些商務系統中進行必要的存取.
Visit the BizTalk ® Adapter website at: http://www.microsoft.com/biztalk/evaluation/adapter/default.mspx
· Download information about the BizTalk® Adapter Pack Office Developer Program: http://www.microsoft.com/biztalk/evaluation/adapter/default.mspx
· Learn more about developing adapters using the Microsoft Windows Communication Foundation (WCF) Line-of-Business (LOB) Adapter SDK at: http://msdn2.microsoft.com/en-us/biztalk/bb905478.aspx
這是中國的SharePoint專家所提供的網路文章,值得參考
[SharePoint Designer技巧-1]使用DataView与Form Web Part实现列表的关键字查询
http://blog.joycode.com/ipark/archive/2007/11/01/109898.aspx
[SharePoint Designer-2]DataForm Web Part解析
http://blog.joycode.com/ipark/archive/2007/12/09/112446.aspx
[SharePoint Designer -3]DataForm Web Part中的数据操作
http://blog.joycode.com/ipark/archive/2008/01/13/113708.aspx
看到了一篇關於Enterprise 2.0與Social Computing的報導,裡面指出,有多數的企業將考慮在內部導入Social Computing的工具.
http://www.eweek.com/c/a/Messaging-and-Collaboration/Businesses-Start-Revving-Your-Enterprise-20-Engines/
報導中特別指出,對於既有廣大的SharePoint客戶來說,可以藉由SharePoint所提供的Social Comuting功能,輕鬆擁有Enterprise 2.0的能力!(摘錄如下)
Coke and Pepsi. Crest and Colgate. It's hard to unseat an entrenched incumbent in any market and Young said Microsoft's SharePoint "will continue to steamroll the market."
He said that while challengers will be quick to denigrate the quality of SharePoint's wiki, blog and social networking functionality, Microsoft will still get a lot of traction with its collaboration suite in 2008. Another thing: Because so many knowledge workers already use SharePoint, it is likely smaller Web 2.0 vendors will look to partner with Microsoft.
SharePoint的定位為何?
在第一次接觸到SharePoint時,個人對於這個產品的屬性有極度的迷惘.這到底是給MIS使用的工具(在微軟內部定義為IT Pro產品,簡單來說,就是TechNet上面所涵蓋的議題)?還是一個給開發者的開發平台(微軟內部定義為MSDN上所涵蓋的範圍)?以IT Pro的產品定位來說..系統的設定以及架構的設計是最重要的,因此在對外的訓練課程中強調了安裝設定與規劃等議題...以Developer來說,則是如何能夠撰寫WebPart或者如何呼叫SharePoint所開放出來的Web Services,這也是一個很大的議題.在訂定產品走向時,這個問題往往讓我陷入無窮迴圈!
最近公司內部針對MOSS的部落格應該放在哪個平台上都有了一點小小的爭執.產品部門原本的BLOG在(http://blogs.msdn.com/sharepoint/),也就是MSDN的平台上....不過有人認為IT Pro也應該要有一個專屬的BLOG在Technet平台上...因此就有位在英國的老兄自行註冊了(http://blogs.technet.com/sharepoint).這樣一來...馬上就吵起來了....
最後的結論..SharePoint是一個兼具IT Pro與Developer特性的產品,但大部分的產品技術資訊應該對於兩個社群都有所幫助..因此...產品部門決定把http://blogs.msdn.com/sharepoint/以及http://blogs.technet.com/sharepoint都指向同一個部落格,而這個部落格中也會持續提供與IT Pro和Developer相關的內容..茶壺內的小風暴就此有了圓滿的結局!
