(此條目之間交叉張貼 http://paulgalvin.spaces.live.com/blog/ 和 http://blogs.conchango.com)
在本網站上的張貼是我自己並不一定代表 Conchango 的立場, 戰略或意見.
概述:
此條目描述一個大一些背景資訊 (3,000 使用者) Microsoft Office SharePoint 伺服器 (苔蘚) 鋪設和我們做了什麼使計畫得以推展方式用戶端是快樂和堅定地走上的道路，以全面通過 MOSS 功能集的結束. 條目的寫作, 我們有約 50% 完成該專案的第一階段. 隨著事情的進展, 我就會更新此條目和/或寫入新的條目.
在這個具體案例, 該公司已經安裝 SharePoint 門戶伺服器 2003. IT 組安裝中的"讓我們看看是否誰會關心一種產品" 時尚. 它迅速通過了許多企業用戶，並且成為了在大型企業中很受歡迎. 你可以想像, 這不是最好的產品推出戰略 (其中，用戶端也承認) 當 MOSS 抵達現場, 在用戶端解決"權做它" 和雇傭我們去説明他們.
當我們開始實施這一專案時我們面臨的中心問題之一是: 我們如何向此用戶端介紹 MOSS? 給出了用戶端已經與 SharePoint 的經驗, 我們想知道 — 我們需要做"差別嗎" 培訓或做我們從最基礎開始了? 後與關鍵使用者一起工作, 我們決定，將此視為更有意義的綠色的外地專案.
這一決定提供了一個起點，但仍然給我們留下的找出一個好的策略，為向企業推出苔蘚主要要求. 青苔是這樣大的動物 … 它包括內容管理, 文件管理, 搜索, 安全, 訪問群體設定, 專案管理, "神話般四十" 範本, 工作流, 業務資料連線器, 等. 這結合的事實，它是一個大的組織， 可以 真正能讓幾乎每個主要的 MOSS 的使用功能和你具有與企業的覆蓋範圍和發生的許多好事情的偉大工程。.
我們一次又一次面臨的這個問題 … 青苔已到達它的企業的功能集與企業, 甚至有些複雜用戶端尚未很難精神上吸收的那些功能, 讓獨自將可觀的一部分納入日常生活.
我沒有魔法解決問題. 我轉而處理只是第一步，我們一直採取與客戶他們沿著小路走向成功的長期通過.
範圍:
正如我一樣想讓團隊制定的專案計劃，包括這種里程碑作為"PoepleSoft 集成通過 BDC 完成", "新跨部門產品啟動工作流完成" 和"行政管理 KPI 接受", 只好用東西少. 這並不是說那"少" 是壞. 事實上, "越少" 我們決定為初始部署了他們在那裡在我們開始之前遙遙領先. 在我們的案例, "越少" 變成了:
- 使用文件庫的簡單文件管理, 版本控制和內容類型.
- 有效的搜索基於內容類型和自訂高級搜索 (通過託管屬性, XSLT 來產生漂亮的結果, 等).
除了上述的企業級功能 (意思他們要向所有部門和使用者推出), 我們添加了以下單身人士範圍內迷你-專案:
- BDC 一體化概念證明.
- 通過 SPD 創建的多步和多分支的工作流過程.
- 複雜的 InfoPath 表單.
- 堆焊 KPI 的一些業務流程 (大概 HR 人才獲取在我們的案例, 雖然這可能會改變).
這裡的範圍不是 100% 準確但代表我們的方法，足以達到我的目的, 這是為了解釋我認為是一種"有效" 將設置為滿青苔通過堅定地向金路徑下的用戶端的青苔的介紹.
我不會寫更多關於單身人士在此條目. 我想指出，這些是我們首要的戰略的一部分. 這樣做是為了實現核心文件管理和搜索功能對所有使用者尚未提供高度功能, 其他的核心莫斯特點，基本上是超越了大多數使用者能夠在這個早期階段吸收高可見和極具代表性的例子. 不過, 他們將"在外面" 而我希望其他業務單位將知道或瞭解他們和自己想要的那些功能, 導致更大的通過. 這些單身人士的成功案例也有助於提供我們的銷售團隊"彈藥" 為成功地贏得第二, 第三次和 n 階段專案.
我們做了介紹什麼和為什麼?
看上的文件管理和搜索並作為比較基準的企業範圍要求, 我們需要開始收集詳細資訊. 作為一個實際問題, 這被圍繞著理解他們的文檔和最終映射到理解的內容類型.
我發現很難解釋無視覺助手的內容類型. 更多的技術民間可以走出淺談內容類型時 CT 的介紹了在資料庫術語中. "CT 是類似于資料庫表, 它有的列和資料類型定義的列, 但 CT 的資料類型包括更多簡單的整數日期, 但也"選擇" 和"查找" 及類似品。" 我們可以談論"擴展" 內容類型, 就像一個可以功能類從基類繼承在物件導向的語言. 然而這顯然不利於運輸部管理員有的人沒有技術背景. 即, 幾乎每個人在 MOSS 部署中的事項.
使用白板是玄乎. 我所介紹的內容類型和繪製的輝煌的想法 (所以他們看起來或) 內容類型和他們為你做的搜索和如何可以擴展他們的圖片, 等. 在結束, 感覺像一些燈泡已經打開了, 但由此產生的白板圖片是一團糟.
這導致了我們我們當前和迄今最為有效的著陸點: 一個配置為顯示這些功能的青苔沙箱網站.
使用沙箱網站, 我們證明:
- 內容類型:
- 創建具有多個資料類型的 CT (文本, 日期, 選擇, 布林值, 查找, 等).
- 通過創建基於父新 CT 延長 CT.
- 搜索文檔使用 CT 中繼資料.
- 文件庫:
- 將單個的 CT 與庫相關聯.
- 當我們向那圖書館上載文檔時，會發生什麼?
- 將與文件庫關聯多個 CT.
- 當我們向那圖書館上載文檔時，會發生什麼?
- 篩選和排序通過 doc lib 中的列標題.
- 文件庫視圖:
- 排序
- 分組
- "快速進入" (資料工作表視圖)
- "未加標籤的資料" (協助與遷移到 MOSS 其他內容來源; 下面對此進行更多).
沙箱網站:
我們設計我們的沙箱網站是一個永久的特徵，在開發環境中，用於培訓目的長後我們完成這個專案，包含幾個工件所述:
內容類型:
我們定義以下內容類型: 發票, 採購訂單, 服務發票.
我們所選發票和採購訂單，因為他們更或較不普遍下
站在的實體. 在業務的每個人都明白，發票是支付給需求 客戶 為 金額 發佈關於某一 日期 根據一些支付 付款條件. 這將導致一個自然的定義一個 ct，我們稱之為"培訓發票" (以區別于其他任何種類的發票). 同樣輕鬆定義採購訂單. 我們還創建了一個"培訓服務發票" 通過創建基於"培訓發票新 CT" CT 和添加一列, "提供服務".
與上述情況, 我們現在可以證明 CT 的一些關鍵的特徵又不陷入試圖先解釋一個抽象的概念; 每個人都已經明白我們所說的"發票" 和"採購訂單" 而是能夠專注于 CT 的力學本身.
自訂清單:
CT 與類型"查找的列" 指向自訂清單或文件庫. 我們使用此廣泛和為沙箱, 我們創建了一個支援自訂的清單，其中包含客戶. 我們挑選客戶，因為它是一個簡單的概念需要理解和容易證明. 發票 CT 有一列, "客戶" 這被定義的類型"查找" 這點在此清單中.
我們創建了一個類似的自訂清單管理"供應商" 為"採購訂單" CT.
文件庫:
我們創建了兩個文件庫: "發票" 和"混合文檔".
我們配置了發票文件庫來管理唯一類型的文檔的 CT"發票".
我們配置了"混合文檔" 庫來管理所有三個 CT.
創建顯示排序的若干意見, 過濾, 工作表資料和分組.
搜索:
我們定義兩個新的託管的屬性，並將他們映射到發票編號和客戶.
我們創建了一個新的自訂的預先搜索網站和修改，以使使用者能夠搜索"發票" 使用這兩個映射的屬性.
修改 XSLT 這樣的發票和客戶號碼, 當存在, 顯示在 HTML 表中明亮的顏色. 這裡的目的是證明這種格式是可能.
放到一起:
我們安排關鍵使用者參與一個演示.
我們按照這個簡單的腳本:
- 描述的意義和用途的 CT, 作為示例使用的發票和採購訂單.
- 顯示發票 CT 定義時同時向他們保證他們不需要使用這些螢幕本身, 只是接概念.
- 轉到發票文件庫.
- 上傳文檔.
- 顯示下拉客戶真的來自自訂清單.
- 在客戶清單中添加一個新的客戶，然後使用新創建的客戶更新最近上載的發票的中繼資料.
- 切換到"混合文檔" 圖書館和上載文檔. 解釋如何系統提示為文件類型.
- 回過頭去發票文件庫和顯示如何按一下列名稱更改排序次序.
- 顯示列級過濾.
- 顯示不同的意見，表明多層次排序, 篩選和分組.
- 顯示資料工作表視圖.
- 解釋"未加標籤的文檔的目的" 視圖.
- 切換到自訂高級搜索.
- 現在, 最近已上載的文檔應已爬網和索引, 所以執行演示能力來定位該發票通過映射屬性的搜索.
- 我們演示搜索通過映射的屬性 vs 之間的差異. 只是文本搜索.
在這一點, 我們或多或少都與演示. 它似乎採取關於 30 自 45 分鐘, 根據多少問題人們問.
我們然後把他們送回辦公桌前帶"家庭作業". 這包括一個簡單的 excel 試算表在哪裡我們問他們如何定義對我們來說他們認為他們需要在 CT 的, 在高一級 (只是名稱和商業用途) 以及列和資料類型的他們要將存儲在列. 我們不要求他們在苔蘚條款中定義的列資料類型, 但業務術語.
在摘要:
我們已經創建一個沙箱環境，我們可以用來演示其上訴是整個企業一些核心苔蘚功能.
我們已經建模易於理解和共同的業務實體，以便使用者可以專注于苔蘚和不拘泥的實體 / 自己的例子.
企業用戶步行從"作業與論文會話" 他們現在主管填寫並用於設計他們自己第一次剪切的內容類型的 excel 檔的形式.
最後, 因為隨著時間的推移，我們執行的演示, 用戶端的團隊成員自己變得更能發揚, 做演示的自己和一般釋放了剩下的我們工作上更複雜的問題, 如全球分類學, 複雜的工作流, BDC 和類似.