2011年8月4日 星期四

流程之間銜接的問題

在描繪企業整體的流程時，在流程之間的銜接上有下列幾點問題有待更清楚地釐清：
  1. 流程圖的範圍應該要描述多少東西才算適當？
    2. 描述的範圍太大，則會使得流程圖看起來過於複雜；但若描述的範圍太小，又會使得流程之間的連接關係斷裂而無法清楚得知流程之間是如何銜接的。
  2. 流程之間介接的方式與時機為何?
    3. 流程之間介接的方式有三種，分別是：
    • 在流程中將另一個流程視為是子流程；
    • 透過呼叫的方式啟動另一個流程；
    • 兩個流程或許有順序關係，但並非於前一流程結束後，「立即」啟動後續的流程。 
    往往很容易混用或誤用這些銜接方式，使得流程在行進的過程當中產生出混淆。
要如何適當地表現出流程的內容？並且很清楚地知道哪些流程與其銜接？又有哪些流程是接續於它？

...待續
張貼者： 於 沒有留言:
標籤： ,

2011年7月26日 星期二

流程分析心得(上)

在分析事件與分析事件進階的文章中已經談到要如何分析開始事件，有了開始事件清單之後，便要開始分析「回應」該事件的流程。例如：當採購部收到一張請購單時(此為訊息類型的開始事件)，則採購部後續便會以採購作業流程來回應此開始事件。

而分析流程的步驟如下：
1.
  1. 先確定所要分析流程的主題與範圍 
  2. 尋找第一個開始事件 
  3. 描繪一條最理想的流程(沒有分岔) 
  4. 由流程前端開始尋找分岔點， 
  5. 自分岔點開始描繪流程，直到結束 
  6. 持續上述4~5兩個步驟直到80%情況均以考量進去 
  7. 尋找下一個開始事件，並重複上述3~6步驟，直到80%的開始事件均已走完 
  8. 最後才用子流程或水道分類來切割流程
=====================================================================
1.確定所要分析流程的主題與範圍

由於在分析流程的過程中，分析人員往往會因為參與的人員過多，或是討論的時間冗長，導致分析時失去焦點或是掌握不到重點，使得最後分析出來的流程，要不是沒有正面回應到開始事件，否則就是流程內容涵蓋過多的東西，使得閱讀流程的人無法很輕易地看懂流程的內容，這些都是導致流程分析不良的原因之一。
所以在開始分析流程之前，最好能夠清楚確定所要分析的主題與清楚界定流程的範圍。要如何掌握主題與範圍呢？簡單地說，
  • 主題的部份當然是流程要能夠正面且精確地回覆「開始事件」，若流程的內容與開始事件相關性不高時，則不應該將這部份納入到流程當中。例如：當談採購作業流程的內容的時候，主題就盡量放在「採購」上，不要將與採購相關性較低的製造、出貨的部份納入流程的內容中；
  • 而範圍的部份則可以參考價值鏈所界定出來的範圍，畢竟價值鏈已具有邏輯上的切割，所以流程的內容盡量不要超出所設定的價值鏈的範圍。例如：當談採購作業流程的內容，就不要再去談匯款、應付帳款的細節，而用子流程或流程介接的模式銜接不同價值鏈的流程。
====================================================================
2.尋找第一個開始事件 

在確定分析的主題與範圍後，則先挑選一個發生頻率與重要性較高的開始事件開始進行分析。你若已經很熟悉事件導向來分析流程，當然可以一次分析多個相關性高的開始事件；但是如果你還不熟悉如何分析流程，建議開始的時候先選擇一個開始事件進行分析，這樣將可大幅度降低分析的複雜度。
====================================================================
3.描繪一條最理想的流程(沒有分岔)

一開始分析流程的時候，先分析一條「最理想的流程」來回應所選擇的開始事件，所謂「最理想的流程」是指該流程中沒有任何「岔路」可供選擇，所有情況都是在最理想、最常發生或是最重要的情況下發生，找出這樣一條路徑將有助於掌握流程分析的主軸，即便在資源或時間不足的情況下，流程的內容也不至於缺漏了重要的元素。
另外這時候，所分析出來的工作項目的層次要具一致性，不能有的工作項目在邏輯上相當複雜且龐大；而有些工作項目卻異常地簡單，工作項目邏輯上大小差異太大的時候，就容易造成有兩個以上的工作項目可能有重疊定義的情形發生。
圖1. 最理想的採購流程

====================================================================
4.由流程前端開始尋找分岔點

當分析出一條最理想的流程後，接著就依據開始事件中去思考有哪些不同的情況發生，並且從流程中尋找適當的分岔點，分析分岔點的時後，一樣要掌握發生頻率較高且重要性較高的分岔點開始思考，往往分析的人容易將一些細微的分岔點一併考慮進來，如此將使得流程圖看起來過於複雜但又沒有什麼意義。
====================================================================
1.5. 自分岔點開始描繪流程，直到結束

圖2. 分析出分岔點與分岔點後續的流程
當分析出一個適當的分岔點後，切勿貪心地繼續尋找流程中其他的分岔點，應先從已找到的分岔點繼續分析，同樣是先找出自分岔點後最理想的流程，然後再去分析分岔點。如此將有助於分析人員用具邏輯性的分析方式逐一將可能的分岔點都找出來，而不會東跳一個西跳一個搞混 了既有的邏輯。
==================================================================== 
6.持續上述4~5兩個步驟直到80%情況均以考量進去
當一條路徑走完之後，再從分岔點繼續走另外一條路，同樣重複第4步與第5步，將每個路徑都走完，如此在理想上便能夠順利地描繪出一個能夠充分回應開始事件的處理流程。
不過在實務上要將所有可能的分岔情況均描繪出來可能會使得流程變得太過於複雜，除了使讀者較難清楚整個流程的邏輯之外，也可能使得流程很難符合實際流程運作的情況，如此所描述出來的流程失真的情況就嚴重了。
所以，在尋找分岔點以及分岔的路徑有哪些的時候，除了切分不同邏輯的分岔路徑之外，若分岔點後所銜接的路徑，其發生的機率已經涵蓋了真實情況中的80% 時，剩下的20%就不一定要再細分其不同的處理方式，只要用一種統一處理原則來處理就可以了。例如：請購時可能所填寫或所附的資料不足時，按理說應該要針對每一種資料不足的組合去衍生出不同的處理流程，而所謂資料不足的種類可能有：規格不正確、建議供應商資料錯誤、請購資訊不足3種。若針對每一資料不足的組合情況去衍生一種處理方式，就可能衍生出2的3次方也就是有8種處理方式，這將使得流程得描繪出這8種處理流程，這就會使得流程變得很複雜。
所以應該儘量簡化流程，而使得流程在正常的情況下已經能夠處理80%以上的變化，剩下20%的變化則運用萬用的流程來處理，例如：通知相關人員開會決定處理原則，用此模式便可以處理較複雜的變化了。
====================================================================
7.尋找下一個開始事件，並重複上述3~6步驟 
當流程已經能夠充分地回應一個開始事件發生後的所有變化之後，流程分析人員則可以開始思考是否存在與該流程相類似的開始事件。例如：接收到一般請購通知、接收到緊急請購通知、...等。若有存在相似地開始事件時，則以原先已經分析出來的流程來回應相似的開始事件，看看能否充分地回應？若無法充分地回應開始事件，則再看應該在原流程中產生新的分岔點以及後續的處理來回應相似地開始事件。
==================================================================== 
8.最後才用子流程或水道分類來切割流程

依據上述7個步驟應可分析出初步的流程出來，分析完後再依據部門、角色或是人員的不同，運用水道來加以區別。
張貼者： 於 沒有留言:
標籤： , ,

2011年2月8日 星期二

Tip: Anatomy of a business process: Inputs, outputs and outcomes

Tip: Anatomy of a business process: Inputs, outputs and outcomes: "- 已使用 Google 工具列寄出"
張貼者： 於 沒有留言:

Tip: Anatomy of a business process: Guides and enablers

Tip: Anatomy of a business process: Guides and enablers: "- 已使用 Google 工具列寄出"
張貼者： 於 沒有留言:

2010年12月17日 星期五

安裝Mediawiki

 一開始想要把BizAgi Process Modeler 描繪好的流程圖與資料直接上傳至MediaWiki上，但是後來發現Process Modeler目前1.5.1.5版本只能上傳流程圖與資料到MediaWiki 1.14的版本。若上傳流程資料至MediaWiki1.15以上的版本，則會因為權限介面的關係而出現錯誤。
所以就嘗試安裝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
...待續


    張貼者： 於 沒有留言:
    標籤：

    2010年12月1日 星期三

    MediaWiki上流程的目錄結構

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

    namespace:pagename/subpagename


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

    在分析資料上我希望能夠過透過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），包括 企業的核心生產與銷售程序:
          2. 支援活動（Support Activities），包括 支援核心營運活動的其他活動，又稱 共同運作環節:
          ◎以上資料轉貼自維基百科

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

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

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

          然而為什麼分析流程要用到價值鏈呢？這樣不是把流程切成一段一段的呢？企業流程分析時先分析價值鏈的原因有下列幾點：
          •  可先區分流程群組的重要性：
          因為價值鏈有分為核心與支援性的活動，一般而言核心活動較支援活動重要，那當然是因為核心活動是引響企業獲利與否最重要的關鍵。
          •  價值鏈具有邏輯切分的效果：
          因為價值鍊已經將企業整個流程以具邏輯性的方式劃分，但因為是以加值邏輯切分，一般來說這一刀多半可以清楚地切割，例如：生產與出貨，從字面上很容易了解其分界點，這將有助於將龐大的流程有系統地切分成幾個大塊的模組。

          •  可促使流程分析時的聚焦：
          除了可以大塊切分企業整個流程之外，日後在分析流程的時候也容易聚焦在單一價值鏈中，例如：生產與出貨，在談生產流程的時候就只談生產；在談出貨的時候就只談出貨，便可以避免流程分析人員想過多的情形發生。
          •  易於分工與整合：
          價值鏈切分後，每個價值鍊都有一定的規模且範圍清楚，所以有助於分工與整合。
          張貼者： 於 沒有留言:
          標籤： ,
          訂閱： 文章 (Atom)