安裝Mediawiki

 一開始想要把BizAgi Process Modeler 描繪好的流程圖與資料直接上傳至MediaWiki上，但是後來發現Process Modeler目前1.5.1.5版本只能上傳流程圖與資料到MediaWiki 1.14的版本。若上傳流程資料至MediaWiki1.15以上的版本，則會因為權限介面的關係而出現錯誤。

• Apache Http Server 4.2.2
• PHP 5.3.3
• MySQL 5.2.2

所以就嘗試安裝MediaWiki 1.14的版本，安裝時搭配上方所列的套件與版本，在安裝的過程當中沒有出現問題，反到是在撰寫頁面後要修改的時候會出現下列的問題，一直找不出此問題的解決方案。

error: 1048 column 'old_text' cannot be null

另外所有程式均安裝在Windows XP上，結果PHP在Windows作業系統中上傳具中文檔名的檔案會有問題，最後選擇放棄在Windows XP上安裝系統，同時捨棄從Process Modeler上傳流程圖資料至MediaWiki的方式，改選則在Linux上安裝所有應用套件，且選擇安裝MediaWiki 1.16的版本以排除所有的問題。

不過BizAgi在其官方網站上已經宣布將於2011年初釋出最新版的Process Modeler，希望到時候能夠解決上傳流程資料至MediaWiki1.16的問題，這樣就能畢其功於一役。

作業系統與套件安裝過程請參考下列網站：

• 安裝Linux
• 安裝Apache Http Server
• 安裝PHP
• 安裝MySQL

安裝完上述套件後將MediaWiki的壓縮檔解壓縮，將mediawiki目錄解壓縮到 /var/www/html/的目錄下， /var/www/html是Apache Http Server預設的根目錄，並且設定 mediawiki目錄的擁有者、群組都是Apache。

shell> chown apache.apache /var/www/html/mediawiki -R

 同時設定 mediawiki/config 的權限開放是可寫入，除了在Command視窗下下指令 之外

shell>chmod a+w /var/www/html/mediawiki/config

...待續

MediaWiki上流程的目錄結構

因為在Wiki上，所有的資料都是以頁標題(page title)為依據，而頁標題的組成方式基本如下：

namespace:pagename/subpagename


例如 Help:Pagename 中 Help就是Namespace，事先定義好Namesapce將有助於先區分同頁名(Pagename)的不同頁標籤，例如：Main:基隆-->是在介紹基隆的網頁；Talk:基隆->是在討論基隆的網頁。MediaWiki定義了基本的15個Namespace分別是：

• Media
• Special
• main
• Talk
• User
• User talk
• Meta
• Meta talk 
• File
• File talk 
• MediaWiki
• MediaWiki talk 
• Template
• Template talk 
• Help
• Help talk 
• Category
• Category talk

在分析資料上我希望能夠過透過Namespace將可能會出現相同名稱的頁標題區分出來所以，未來每家公司的流程名稱、工作名稱...等可能會有重複的地方，為了保留其名稱的可重複性，流程Wiki上以公司別增加Namespace，例如：

• PEWC
• APWC
• SCC
• EPAN
• ...

另外針對SAP設定增加幾個Namespace，例如：

• Client100
• Client300
• Client600
• CrossClient

在頁面名稱上(Pagename)，須再冠上下列名稱以方便區別

• ValueChain
• Process
• Task
• Form
• Organization
• Role
• TCode
• IMG
• ABAP
• Basis

依據上述規則，命名範例如下：

• PEWC:Process:採購作業流程  (在說明太電進行之採購作業流程之頁標題)
• SCC:Task:ProcessPurchaseOrder (在說明新馬如何完成處理採購單工作之頁標題)
• Client100:TCode:FD32 (在說明如何在Client100上操作T-Code FD32之頁標題)

而流程相關名稱的部份，基本上維持台灣使用繁體中文；中國使用簡體中文；其他地區使用英文的模式。

最後在條目底下加上[Category:分類名稱]，便可將條目加以分類，一個條目可以被歸納至多個分類中。

而流程相關資料其分類結構規劃如下：

• Company(公司)
• ValueChain(價值鏈)
• Event(事件)
• Process(流程)
• Task(工作項目)
• Form(表單)
• Organization(組織)
• Role(角色)

整合SAP ERP系統的時候，SAP相關資料在wiki上的分類結構如下：

• SAP
• T-Code
• IMG
• ABAP
• Basis

分析價值鏈

企業流程分析(Enterprise Processes Analysis)方法論的第一步是對分析企業的價值鏈，價值鏈是由管理大師 麥克‧波特(Michael Poter)在1985年，於《競爭優勢》一書中提出的。 波特指出企業要發展獨特的競爭優勢，要為其商品及服務創造更高附加價值，商業策略是解構企業的經營模式（流程），成為一系列的增值過程，而此一連串的增值流程，就是「價值鏈」。
 
一般企業的價值鏈主要分為:

1. 主要活動（Primary Activities），包括 企業的核心生產與銷售程序:
   • 進貨物流（Inbound Logistics），即來料儲運，締屬資源市場
   • 製造營運（Operations），即加工生產，締屬製造商市場
   • 出貨物流（Outbound Logistics），即成品儲運，締屬中間商市場
   • 市場行銷（Marketing and Sales），即市場營銷（4P），締屬消費者市場
   • 售後服務（After sales service）
   • 以上為產生價值的環節。
2. 支援活動（Support Activities），包括 支援核心營運活動的其他活動，又稱 共同運作環節:
   • 企業基礎建設（The infrastructure of the firm），即企業基礎建設和組織建設
   • 人力資源管理（Human resources management）
   • 技術發展（Technology development），即技術研發（R&D）
   • 採購（Procurement），即採購管理
   • 以上活動利於資產評估，為輔助性增值環節。

◎以上資料轉貼自維基百科

所以在分析一家企業的價值鏈時要先了解這家企業的核心活動是什麼？這和這家企業從事的產業與獲利核心有著密切的關係，若是以製造為主的企業，接單、設計、生產、出貨可能是其主要的核心活動；若是以服務為主的企業，則與客戶接觸、詢問、提供服務、滿意度調查可能是其主要的核心活動。

換句話說，核心活動就是讓企業能夠獲利的主要活動，所以在分析時主要是從公司會提供哪些產品或服務給客戶開始思考，想一下企業是如何產出產品或提供服務的？有哪些活動是過程中必須進行且對產品或服務本身具有增加其價值的，例如：組裝活動是將原本分散的零件組裝成有用的模組，這對於產品本身便具有加值的能力，所以企業賣模組的價格會比所有零件+工資來得高。

找出核心活動之後，再思考有哪些提供核心活動能夠正常穩定運行的支援性的活動，例如採購、人事相關的活動。或許有人會想說，這些活動也很重要啊！為什麼它們不是核心活動？最重要的原因是它們對於產品或服務本身並沒有加值的效果。以採購為例，雖然所購買的零件對於產品來說很重要，但是零件若採購回來並沒有組裝時，零件的價值與購買時的價值是相同的，假設沒有用到要賣出時，其價值可能比購買時更低，所以採購活動對於產品本身並沒有加值的效果，所以屬於支援性的活動

然而為什麼分析流程要用到價值鏈呢？這樣不是把流程切成一段一段的呢？企業流程分析時先分析價值鏈的原因有下列幾點：

•  可先區分流程群組的重要性：

因為價值鏈有分為核心與支援性的活動，一般而言核心活動較支援活動重要，那當然是因為核心活動是引響企業獲利與否最重要的關鍵。

•  價值鏈具有邏輯切分的效果：

因為價值鍊已經將企業整個流程以具邏輯性的方式劃分，但因為是以加值邏輯切分，一般來說這一刀多半可以清楚地切割，例如：生產與出貨，從字面上很容易了解其分界點，這將有助於將龐大的流程有系統地切分成幾個大塊的模組。

•  可促使流程分析時的聚焦：

除了可以大塊切分企業整個流程之外，日後在分析流程的時候也容易聚焦在單一價值鏈中，例如：生產與出貨，在談生產流程的時候就只談生產；在談出貨的時候就只談出貨，便可以避免流程分析人員想過多的情形發生。

•  易於分工與整合：

價值鏈切分後，每個價值鍊都有一定的規模且範圍清楚，所以有助於分工與整合。

事件分析進階

在分析事件的時候，會遇到概念上很接近的事件種類，例如：在接收訂單時，有時會收訂金，有時候不會收訂金，倒底收訂金與不收訂金的事件是要算同一項事件(接收訂單)，還是要分開看待為兩個不同的事件呢？我相信這樣的問題在分析事件的過程中一定會常常出現的，有沒有什麼規則與方法來分辨與判斷呢？以下是我的心得：

• 基本上兩個事件若本質相同，且處理事件的流程大同小異 ，則這兩個事件可以合併成一個事件種類。(例如：收不收訂金的訂單處理流程只有在收取訂金這一部份有差別，那就不要區分收取訂金與否的事件，統一看成是接收到訂單的事件)
• 若不是那麼容易分辨的時候，建議先將兩個事件的處理流程都描繪出來，然後再去比較是否要合併或獨立。
• 另外提供一個比較簡略的方法，就是了解實際的處理流程，假如事件收到某張表單，而事件差異之處只是表單上某個選項，此時比較可能是屬於同一事件。
• 無論是要分列還是整合事件，分析事件的主要目的在釐清組織有哪些流程會被觸發，所以重點應該要避免有遺漏的事件，所以在分析初期會建議先不要合併，先分開表列，並分析該事件的處理流程，待整體分析後，確定後續處理流程大同小異後，才決定合併成單一事件種類 。

分析事件並整理事件清單

今天分析各價值鏈的事件，同仁們已經越來越了解事件的概念了，我整理一下對於事件的描述，

• 開始事件會有到一個觸發的機制；例如：通知單、時間、滿足某個條件...等。
• 當開始事件的觸發機制被啟動後，會串連一整個流程的運行。

所以在分析開始事件的時候可以從下列幾個方向進行思考：

• 開始事件後面一定會啟動流程，所以要先思考當公司或單位接收了什麼資訊後會觸發流程，例如：接收到訂單、接收到工單資訊、接收到請購單...。這就屬於訊息(Message)類的開始事件。
• 接下來思考有沒有一些屬於時間有關的開始事件，例如：固定頻率(每年、每月、每周)、固定時間(過了10天之後)或是不定期。
• 再來思考有沒有滿足特定條件後會啟動流程的開始事件，例如：當原料庫存低於安全存量時、當支票到期時...等。
• 以上三大類型的開始事件大致已經涵蓋了大部分的開始事件了，再注意一些主檔資料維護的事件並在分析流程的時候再去思考有沒有要再加強的部分應該就可以找出大部分的事件了。

最後針對事件進行排序，針對開始事件的「重要程度」與「頻率程度」進行評估，重要程度以1~5來評分，1表示最重要；頻率程度也是以1~5來評分，1表示發生頻率最高的。如此的目地在排列要描繪之流程的優先順序，越重要且頻率越高的事件優先描繪，重要性較低則發生頻率也低的則最晚被描述，並掌握80-20法則，便能夠較快速地聚焦。

在整理與描述事件時可參考下列Excel的範例：

事件清單(範例)

如此將有助於分析事件。

尋找MediaWiki專家

透過仁山的介紹目前正和一位名叫planetoid的人聯絡，希望其能夠協助我們妥善地規劃MediaWiki的架構與使用方式。

planetoid聯絡方式：planetoid@gmail.com

接下來要搞清楚的重點

能和一群人一起弄企業流程，實在讓我感到興奮，一股動力驅使著我一直往前走，這是很難得的機會與經驗，除了確實能夠看出成果之外，也希望能夠趁這次的機會，把一些想法與經驗整理出來，轉換成教材或書籍。今天腦袋裡思考的重點有：

MediaWiki的部分 ：

• MediaWiki安裝在Window7上後，是否能夠支援上傳中文檔名的檔案
• 確定專案資料的條目要如何設定
• 啟用與測試MediaWiki其他的擴充元件
• 規劃不同資料類型模板

流程圖的部分：

• 將事件彙整起來
• 需要密集工作(可能一個禮拜要3~5天)，將Level2的流程串連起來(11月底之前)
• 希望12月底完成Level3 的流程圖；1月開始撰寫內容。

在Wiki上價值鏈的表示方式

上圖是以專案為題的價值鏈，也是軟體品質管理系統或是CMMI所說的專案手冊所描述最上層的圖，此圖的目的在說明專案各個階段，所應該遵循的程序為何。

我們在描繪企業流程的時候也是如此，應該要先描繪整個企業的價值鏈，也等於後敘流程歸屬的第一層架構。

在價值鏈流程圖基本上應該不會有互斥型匝道的存在，也不會事件存在，描繪完上述的流程之後，將其公佈至Wiki平台上，將其順序調整之後，便會得到下列的目錄。這將有助於釐清企業價值鏈之間的關係，也等於整個企業文件的索引頭。

將BizAgi Process Modelor畫好的流程圖資料匯出至MediaWiki

在使用BizAgi免費流程圖軟體(Process Modelor)時發現，它在匯出的方式上可以選擇匯出至Wiki，這讓我產生好奇，於是上網搜尋Wiki，找到了免費的Wiki平台--MediaWiki，於是將其下載，並試著安裝。

在安裝的同時發現下列幾點問題：

• BizAgi Process Modelor 1.5.1.5目前只支援MediaWiki 1.14版本，而目前MediaWiki已經出到1.16版，顯然這部份BizAgi 更新的速度有點慢。
• MediaWiki所需要的環境：Apache Http Server 2.2、PHP 5.2、MySQL 4.1，若安裝順利應該不會有太大的問題。(安裝步驟另外說明)
• 安裝完MediaWiki之後，因為MediaWiki預設是不能上傳檔案的，所以須要先開啟上傳檔案的設定，在LocalSetting.php中，設定$wgDisableUpload=false;
• MediaWiki若安裝在作業系統是Windows XP上時，因為XP在檔案管理上沒有支援Unicode，以致於無法上傳是中文檔名的檔案，這會影響後續與Process Modelor整合的效果，所以建議作業系統最好選擇可以支援Unicode的。

安裝好之後，便可以連結至MediaWiki上，例如：我的MediaWiki。

• 接著用Process Modelor開啟繪製好的流程圖，例如：可下載BizAgi中的 Personal Loans Request。

• 然後在Process Modelor中選擇功能列 Export/Import，然後選擇Publish Wiki

• 然後挑選要匯出的流程圖與元件，建議元件依據流程圖由左上至右下的順序排列

• 最後選擇要匯出並發佈至哪台Wiki伺服器上，這邊注意Server欄位要輸入MediaWiki的網址例如：http://www.example.com/mediawiki/index.php，然後選擇「Finish」按鈕。

此時BizAgi Process Modelor便會將流程圖的結果上傳至MediaWiki平台上，如上傳結果，且每張流程圖都會有一個Wiki名稱，透過名稱可以從MediaWiki中查詢到流程的細節。範例

接下來流程設計人員便可以開始在MediaWiki上編輯流程的細節。

不過目前不確定當Process Modelor修改流程圖之後，再次Publish的時候，是否能夠順利修改MediaWiki上的資料，這點有待後續再確認。